Bitcoin-Qt, the future Bitcoin client GUI [user input needed] - page 4.

ArtForz

sr. member

Activity: 406

Merit: 257

Quote from: Pieter Wuille on September 08, 2011, 03:59:07 AM

Quote from: twobits on September 07, 2011, 04:24:37 PM

Quote from: FatherMcGruder on September 07, 2011, 09:42:30 AM

Quote from: twobits on September 06, 2011, 09:39:33 PM

I would think they should be released a separately as the qt dependency changes the nature of the licenses being depended on, and a more free main branch would be preferable.

Qt is available under a commercial license, the LGPL, and the GPL. Can you elaborate on your concerns?

It is just that. It would be the most restrictive license yet used for anything required. If this was brought in, anyone distributing binaries will also have to make available the source code to the Qt that they used for example or not bundle it. Wxwidgets made sure those conditions did not apply to derived works distributed in binary form. The creators of Qt got dragged a bit towards it even being as unrestricted as the LGPL in the beginning. I had noticed that the licenses picked so far are all much less restrictive and had thought that was a deliberate choice to keep the software free to more uses without the burdens of the GPL

But the license of the bitcoin and bitcoin-qt code is still MIT, even though it links against an LGPL library. IANAL, but I believe this means that if you use the source to build a headless version (which doesn't link against Qt) there is no restriction on the distribution of the resulting binary.

We're statically linking BDB4.7 already. Read that license?

edit: to save some hunting, here it is:

Code:

/*
* Copyright (c) 1990,2008 Oracle. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* 3. Redistributions in any form must be accompanied by information on
* how to obtain complete source code for the DB software and any
* accompanying software that uses the DB software. The source code
* must either be included in the distribution or be available for no
* more than the cost of distribution plus a nominal fee, and must be
* freely redistributable under reasonable conditions. For an
* executable file, complete source code means the source code for all
* modules it contains. It does not include source code for modules or
* files that typically accompany the major components of the operating
* system on which the executable file runs.
*
* THIS SOFTWARE IS PROVIDED BY ORACLE ``AS IS'' AND ANY EXPRESS OR
* IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
* WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR
* NON-INFRINGEMENT, ARE DISCLAIMED. IN NO EVENT SHALL ORACLE BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
* CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
* SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
* BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
* WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
* OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN
* IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/

aq

full member

Activity: 238

Merit: 100

Quote from: zwierzak on September 07, 2011, 05:47:25 PM

One thing which should be change before merge! Progressbar which inform about sync process should be like in Bitcoin Wallet for Android. This mean that 0% is than, when we run client and it is unsynchronized. Now it shows 99% after start and it not changing until full synchronization. This is not functional if not inform about progress.

+1

FatherMcGruder

sr. member

Activity: 322

Merit: 250

Quote from: twobits on September 07, 2011, 04:24:37 PM

It is just that. It would be the most restrictive license yet used for anything required. If this was brought in, anyone distributing binaries will also have to make available the source code to the Qt that they used for example or not bundle it. Wxwidgets made sure those conditions did not apply to derived works distributed in binary form. The creators of Qt got dragged a bit towards it even being as unrestricted as the LGPL in the beginning. I had noticed that the licenses picked so far are all much less restrictive and had thought that was a deliberate choice to keep the software free to more uses without the burdens of the GPL

I can't imagine a better way to keep the software freer than with the likes of the GPL, but I suppose that's beyond the point. If copyleft should work its way into the main branch, as it might with the inclusion of Qt, folks who don't like it can just work with their own non-copyleft branch.

Pieter Wuille

legendary

Activity: 1072

Merit: 1181

Quote from: twobits on September 07, 2011, 04:24:37 PM

Quote from: FatherMcGruder on September 07, 2011, 09:42:30 AM

Quote from: twobits on September 06, 2011, 09:39:33 PM

I would think they should be released a separately as the qt dependency changes the nature of the licenses being depended on, and a more free main branch would be preferable.

Qt is available under a commercial license, the LGPL, and the GPL. Can you elaborate on your concerns?

It is just that. It would be the most restrictive license yet used for anything required. If this was brought in, anyone distributing binaries will also have to make available the source code to the Qt that they used for example or not bundle it. Wxwidgets made sure those conditions did not apply to derived works distributed in binary form. The creators of Qt got dragged a bit towards it even being as unrestricted as the LGPL in the beginning. I had noticed that the licenses picked so far are all much less restrictive and had thought that was a deliberate choice to keep the software free to more uses without the burdens of the GPL

But the license of the bitcoin and bitcoin-qt code is still MIT, even though it links against an LGPL library. IANAL, but I believe this means that if you use the source to build a headless version (which doesn't link against Qt) there is no restriction on the distribution of the resulting binary.

zwierzak

newbie

Activity: 24

Merit: 0

One thing which should be change before merge! Progressbar which inform about sync process should be like in Bitcoin Wallet for Android. This mean that 0% is than, when we run client and it is unsynchronized. Now it shows 99% after start and it not changing until full synchronization. This is not functional if not inform about progress.

twobits

sr. member

Activity: 574

Merit: 250

Quote from: FatherMcGruder on September 07, 2011, 09:42:30 AM

Quote from: twobits on September 06, 2011, 09:39:33 PM

I would think they should be released a separately as the qt dependency changes the nature of the licenses being depended on, and a more free main branch would be preferable.

Qt is available under a commercial license, the LGPL, and the GPL. Can you elaborate on your concerns?

It is just that. It would be the most restrictive license yet used for anything required. If this was brought in, anyone distributing binaries will also have to make available the source code to the Qt that they used for example or not bundle it. Wxwidgets made sure those conditions did not apply to derived works distributed in binary form. The creators of Qt got dragged a bit towards it even being as unrestricted as the LGPL in the beginning. I had noticed that the licenses picked so far are all much less restrictive and had thought that was a deliberate choice to keep the software free to more uses without the burdens of the GPL

FatherMcGruder

sr. member

Activity: 322

Merit: 250

Quote from: twobits on September 06, 2011, 09:39:33 PM

I would think they should be released a separately as the qt dependency changes the nature of the licenses being depended on, and a more free main branch would be preferable.

Qt is available under a commercial license, the LGPL, and the GPL. Can you elaborate on your concerns?

twobits

sr. member

Activity: 574

Merit: 250

Quote from: aq on September 06, 2011, 09:21:11 PM

Quote from: Gavin Andresen on September 05, 2011, 04:55:55 PM

Quote from: wumpus on September 04, 2011, 04:23:30 AM

Thanks; we really ought to do a parallel release of binaries with 0.4.0, and maybe keep it up until the core dev team finally merges it.

I think everybody would like to merge bitcoin-qt as soon as the 0.4 release is shipped (see the bitcoin-dev mailing list for the current known bugs).

Closing the dozens of wxWidgets-related GUI bugs in the issues list will give me great pleasure...

Doesn't bitcoin-qt already contain the 0.4 core? If yes, what is the reason to even release bitcoin 0.4? Why not release 0.4-qt instead?

I would think they should be released a separately as the qt dependency changes the nature of the licenses being depended on, and a more free main branch would be preferable.

aq

full member

Activity: 238

Merit: 100

Quote from: Gavin Andresen on September 05, 2011, 04:55:55 PM

Quote from: wumpus on September 04, 2011, 04:23:30 AM

Thanks; we really ought to do a parallel release of binaries with 0.4.0, and maybe keep it up until the core dev team finally merges it.

I think everybody would like to merge bitcoin-qt as soon as the 0.4 release is shipped (see the bitcoin-dev mailing list for the current known bugs).

Closing the dozens of wxWidgets-related GUI bugs in the issues list will give me great pleasure...

Doesn't bitcoin-qt already contain the 0.4 core? If yes, what is the reason to even release bitcoin 0.4? Why not release 0.4-qt instead?

Gavin Andresen

legendary

Activity: 1652

Merit: 2300

Chief Scientist

Quote from: wumpus on September 04, 2011, 04:23:30 AM

Thanks; we really ought to do a parallel release of binaries with 0.4.0, and maybe keep it up until the core dev team finally merges it.

I think everybody would like to merge bitcoin-qt as soon as the 0.4 release is shipped (see the bitcoin-dev mailing list for the current known bugs).

Closing the dozens of wxWidgets-related GUI bugs in the issues list will give me great pleasure...

aq

full member

Activity: 238

Merit: 100

Quote from: Matoking on September 03, 2011, 08:38:00 AM

I fixed a few things on my fork here :
https://github.com/Matoking/bitcoin-qt

It should fix the "window becoming empty when minimized and then brought up from taskbar again" issue and make the window background plain when it's maximized on Windows (makes it more readable).

Compare this (before)
http://i.imgur.com/crwHo.png
to this (after)
http://i.imgur.com/MShYj.png

Great enhancement!
While you are already at it, would it be possible to make this transparent thing optional. I mean if you have some dark window (ie. command line) behind the bitcoin window, it has the same problem as if it would be maximized. IMO this transparent effect doesn't fit a financial software anyway. So again IMO, this option should be disabled by default, but maybe thats just me.
Yes, I know, should code this myself

wumpus

hero member

Activity: 812

Merit: 1022

No Maps for These Territories

Quote from: Matoking on September 03, 2011, 08:38:00 AM

I compiled the latest version (commit 4785e6df74151f91d0c1) for Windows.

Thanks; we really ought to do a parallel release of binaries with 0.4.0, and maybe keep it up until the core dev team finally merges it.

Maybe even make a little website to download from... I might have a spin at it when I have some time, though I'm not really a web designer.

Matoking

sr. member

Activity: 352

Merit: 250

Firstbits: 1m8xa

I compiled the latest version (commit 4785e6df74151f91d0c1) for Windows.

http://www.mediafire.com/?rfawsiajyfy70kk

I'll probably look at the code and try my hands on the GUI and try fixing things (for instance, minimizing the application makes the application go blank, you have to click the icon on system tray to fix it)

On Windows the window's (pun not intended) background should be made plain white when the window is maximized, since otherwise it's very hard to read (black text on almost black background).

Minimizing the window makes the application window go blank when you try opening it again from the taskbar instead of system tray. Or maybe the application should just go to system tray (in same manner as "closing" the application)

EDIT :
I fixed a few things on my fork here :
https://github.com/Matoking/bitcoin-qt

It should fix the "window becoming empty when minimized and then brought up from taskbar again" issue and make the window background plain when it's maximized on Windows (makes it more readable).

Compare this (before)
http://i.imgur.com/crwHo.png
to this (after)
http://i.imgur.com/MShYj.png

Feel free to add to the main repository if I didn't break anything. Tongue

wumpus

hero member

Activity: 812

Merit: 1022

No Maps for These Territories

Quote from: aq on September 01, 2011, 01:35:32 PM

It depends on what the progress bar displays. Does it display the amount of work (download) that has to be done, or does it display the current state (now at block n of m). If it always if the former, it would be OK for the user, because it displays what the progress of the *current* work

It displays the part of the total block chain that has been downloaded. It's comparable to re-starting a torrent client, or other download client. If it would start from 0% every time a user might indeed assume it has restarted.

Then again, as bitcoin is not regarded as a download client, probably this discussion is completely theoretic and users would not complain if it showed only the (relative) part of what still has to be downloaded... also, you get the "m out of n blocks downloaded" in a tooltip which shows absolute numbers...

aq

full member

Activity: 238

Merit: 100

Quote from: Maged on August 31, 2011, 02:53:00 PM

Quote from: aq on August 31, 2011, 09:28:54 AM

Tiny cosmetic "feature" request:
If the user starts the app once a day, the syncing progress bar hoovers around 99% without any movement for a few minutes.
I think it would be better if the progress bar would always start at 0% and can therefor show some movement.
What I mean: the old (already downloaded) block count is represented by 0% and the up-to-date block count is 100%.
Now the casual user can see some progress bar movement, and all is well Wink

To prevent a massive amount of support requests if you add this, be sure not to use this behavior until the client thinks that they've completed the initial download of blocks. Otherwise, if someone turns off their client in the middle of the initial download, they might think that the client restarted the download instead of continuing it. However, you'd also then need to visually differentiate progress between the initial download and updates. (different progress bar color?)

BTW, a simple "resuming" in the syn text would prevent all your massive support requests.
It depends on what the progress bar displays. Does it display the amount of work (download) that has to be done, or does it display the current state (now at block n of m). If it always if the former, it would be OK for the user, because it displays what the progress of the *current* work, in contrast to displaying the combined work over all program starts.
For example, when I copy some files, the progress bar goes from 0 to 100% - it does not include all files I ever copied Wink

Different colors? Now *that* would trigger some massive amount of support requests, maybe even I would ask what this is all about.

wumpus

hero member

Activity: 812

Merit: 1022

No Maps for These Territories

Sounds like a lot of hassle. Different progress bar colors complicate stuff for both the user and developer :-) The progress bar was meant to show initial block chain download progress, so you're right that it might be better to keep it at that.

Probably, we should simply not show the progress bar if progress is so close to 100% at startup... The spinner shows that it is catching up to the block chain, anyway.

Pieter Wuille

legendary

Activity: 1072

Merit: 1181

What about persistently storing the last block number at which the client was in sync with the network? Initially this is zero, and it remains zero until the client is entirely up-to-date. If at that point it goes offline, and comes back after having missed a few blocks, a new progress bar appears that represents the catching up from that previous point to the current blockchain tip.

Maged

legendary

Activity: 1204

Merit: 1015

Quote from: aq on August 31, 2011, 09:28:54 AM

Tiny cosmetic "feature" request:
If the user starts the app once a day, the syncing progress bar hoovers around 99% without any movement for a few minutes.
I think it would be better if the progress bar would always start at 0% and can therefor show some movement.
What I mean: the old (already downloaded) block count is represented by 0% and the up-to-date block count is 100%.
Now the casual user can see some progress bar movement, and all is well Wink

To prevent a massive amount of support requests if you add this, be sure not to use this behavior until the client thinks that they've completed the initial download of blocks. Otherwise, if someone turns off their client in the middle of the initial download, they might think that the client restarted the download instead of continuing it. However, you'd also then need to visually differentiate progress between the initial download and updates. (different progress bar color?)

aq

full member

Activity: 238

Merit: 100

Quote from: kjj on August 31, 2011, 11:02:53 AM

Quote from: aq on August 31, 2011, 09:28:54 AM

Tiny cosmetic "feature" request:
If the user starts the app once a day, the syncing progress bar hoovers around 99% without any movement for a few minutes.
I think it would be better if the progress bar would always start at 0% and can therefor show some movement.
What I mean: the old (already downloaded) block count is represented by 0% and the up-to-date block count is 100%.
Now the casual user can see some progress bar movement, and all is well Wink

The problem with this is that the chain doesn't have an end. It doesn't even have a current endpoint. All it has is the dividing line between blocks that your node knows about, and blocks that it doesn't know about yet. It seems like a trivial thing, but the misunderstanding can have serious consequences.

But yeah, the progress bar could be better. But you can't make it too good, or it will confuse users. There is even a trope about it.

Using the last known block height like you suggest seems like a good way to do it.

All academical discussions beside, the progress bar is shown right now, but stays at 99% for almost all users once a day for about a minute. It is only shown while downloading blocks and it is hidden when the current block count is reached. So it is effectively a static image. My "proposal" would make it usable. And the progress bar is not a scientific measurement device, it is only a visual feedback, so that the user can see that something is being download. In fact stating 99% all the time, the is indistinguishable between some download is happening and nothing is being downloaded.

kjj

legendary

Activity: 1302

Merit: 1026

Quote from: aq on August 31, 2011, 09:28:54 AM

Tiny cosmetic "feature" request:
If the user starts the app once a day, the syncing progress bar hoovers around 99% without any movement for a few minutes.
I think it would be better if the progress bar would always start at 0% and can therefor show some movement.
What I mean: the old (already downloaded) block count is represented by 0% and the up-to-date block count is 100%.
Now the casual user can see some progress bar movement, and all is well Wink

The problem with this is that the chain doesn't have an end. It doesn't even have a current endpoint. All it has is the dividing line between blocks that your node knows about, and blocks that it doesn't know about yet. It seems like a trivial thing, but the misunderstanding can have serious consequences.

But yeah, the progress bar could be better. But you can't make it too good, or it will confuse users. There is even a trope about it.

Using the last known block height like you suggest seems like a good way to do it.

Topic: Bitcoin-Qt, the future Bitcoin client GUI [user input needed] - page 4. (Read 57134 times)