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

[FatherMcGruder]

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.

[aq]

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

[ArtForz]

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.
 */

[twobits]

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:

Thanks.   You did not save me any hunting however.  I have of course  read the Sleepycat license, in fact  years ago and was quoting form it recently in another thread here, and reread it before posting in that thread.
 I do agree it is the current most restrictive license  being used by a dependency. In fact that is why I have said on irc to some that I had been thinking  of removing that dependency.   That really would not be that big of a project.    That would be a silly project now though if another more restrictive one would go in.   In fact the current distributions of the binaries for bitcoin are in violation of the Sleepycat license. It however would be very simple to remedy  unlike the gpl licenses that require you to keep available the exact code you used for a number of years and not just point to another mirror of it.

I stand by what I said above, and I said it being fully aware of of the BDB dependance and it's license, and am not sure why you thought I was not.

[twobits]

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.

Yes,  someone could always fork that last branch before that and probably will.

[ArtForz]

I just don't see the massive problem here. SleepyCat (in my book a way "stronger" copyleft license than LGPL) is ok because you can rewrite the database interface, but simply removing the GUI or forking the old wx GUI is ... what? impossible?

[twobits]

I just don't see the massive problem here. SleepyCat (in my book a way "stronger" copyleft license than LGPL) is ok because you can rewrite the database interface, but simply removing the GUI or forking the old wx GUI is ... what? impossible?

Again you put things that I am not writing.  Where did I write that the SleepyCat is ok?   I simple wrote that is is less restrictive then the  LGPL.  If I thought it was ok, I doubt I would have started the project to remove it.
 Is that the point of debate?     What to me was not ok, is going the direction of more restrictive licenses.   I simple said that it would not be too hard to remove.   I did not say it was ok to me.  However it already is present. Too late to avoid adding it unlike lgpled dependent code.

Also never said that forking it was impossible, in fact in the post right above your reply I say the opposite.  I probably will do just that, if I continue.  Just thought I would try and avoid the need for yet another fork.

[ArtForz]

*shrug* I still don't see how LGPL is more restrictive than SleepyCat, but... guess we'll have to disagree on that.

[aq]

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.

Actually I can't imaging someone wants a closed source bitcoin client - the only advantage of not using GPL. As a side effect of using GPL all bitcoin forks would stay open source too, which is not necessary with MIT/BSD. Looking at Linux, GPL did not prevent it from being used commercially, in contrast, it enabled it reaching from smartphones to supercomputers.

[kjj]

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.

Actually I can't imaging someone wants a closed source bitcoin client - the only advantage of not using GPL. As a side effect of using GPL all bitcoin forks would stay open source too, which is not necessary with MIT/BSD. Looking at Linux, GPL did not prevent it from being used commercially, in contrast, it enabled it reaching from smartphones to supercomputers.

GPL software is never open source.  It is always free, which is the whole point of the license.

[aq]

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.

Actually I can't imaging someone wants a closed source bitcoin client - the only advantage of not using GPL. As a side effect of using GPL all bitcoin forks would stay open source too, which is not necessary with MIT/BSD. Looking at Linux, GPL did not prevent it from being used commercially, in contrast, it enabled it reaching from smartphones to supercomputers.

GPL software is never open source.  It is always free, which is the whole point of the license.

Well, it depends on your definition of the term "open source". These days this usually means an OSI http://www.opensource.org/ approved license.

[wumpus]

No license discussion here please, get your own room The core library is still independent of Qt, so you choose to link against LGPL (Qt is not GPL!) code only when you want to build the UI not when you want to link it into your own evilly licensed statically linked program

Matoking's fixes have been merged

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.

Yeah, I too think that'd be better...

[Matoking]

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.

Yeah, I too think that'd be better...

https://github.com/Matoking/bitcoin-qt ( https://github.com/Matoking/bitcoin-qt/commit/b97357889fd71549373b7d2a826a863402a586ff )
I implemented it on my fork. May not be the best way of doing it but it works. Let me know if it's ok.

Also, the launch parameter reference has been removed in the latest commit, gotta figure out how I'll implement it.

[wumpus]

I implemented it on my fork. May not be the best way of doing it but it works. Let me know if it's ok.

Thanks. I think your implementation of storing the number in the model (instead of the core) is a good idea.

Also, the launch parameter reference has been removed in the latest commit, gotta figure out how I'll implement it.

Please don't add commandline parameters for GUI options, it's not the right place. If it would be an option, it should be in Options in the GUI, add an "Appearance" tab for example

Though I don't think this is a big issue. If people think that the transparency effect is annoying we should simply remove it. I personally thought it looked nice and accepted the contribution from nico_w making the application look more "windows 7 native", but we could get rid of a lot of windows-specific code if we simply removed it.

[Matoking]

The problem with the transparency effect is you sometimes to have to move stuff around or maximize the window to make it readable. If your application window is over a black background it's hard to read it. I'll see if there's something that can be done to make it better.

And that commandline parameter was just a test that never took off, no intention of adding it like that.

Maybe add a glow over the menu buttons (native Windows programs do this)

[wumpus]

The better progress bar handling patch has been merged.

Maybe add a glow over the menu buttons (native Windows programs do this)

Yeah I wonder if Qt can do this. If not, I don't think it's worth spending too much work in. But this indeed would be a far better solution  

Edit: BTW, thanks to whoever sent me a anonymous donation

[Matoking]

Hmm, I noticed after I played Portal 2 that the background of the main window became entirely black.

I wonder if the transparency effect is really needed after all.

[wumpus]

I'm going to remove it for now...

[Furyan]

I'm going to remove it for now...

Would it matter if I object?

FWIW the transparency effect is working exactly as intended.  The black background after playing Portal 2 is likely due to a crashed video driver.  Simply restarting the DWM service will fix that.

With regard to having to move the window around if you've got it on top of something with a black background - like a console window? - Microsoft took that kind of issue into account when creating the UI.  For the vast majority of "dumb" users, it isn't an issue and your average user will expect to see transparency in a supposedly professional app. Removing it will make them think you haven't really updated it in a long time, reducing their confidence in it.  The research confirms this.

We technical types have a way of designing software the way we think people would use it.  We're almost never right in that regard - we use software very, very differently than an average user.  If your purpose with Bitcoin-Qt is only to appeal to a technical audience, your intuition will guide you very well.  If your purpose is to appeal to less technical users and encourage wide adoption of Bitcoin, you should ignore your intuition as often as possible and look to other well-documented approaches for guidance.

I think the transparency makes the app look alot more beautiful and I rather liked it..

[HostFat]

Can be enabled as an option?