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

Furthermore, a color pallet for choosing the color of transparency would be really cool! Of course it would be extremely low on the priority list.

Agreed, though I should add I think the option should be to turn it off, i.e. defaulting to on.

Having the transparency effect as an option would be the best solution.

Can be enabled as an option?

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

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

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.

The better progress bar handling patch has been merged.

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

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)

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

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.

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.

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

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

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

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

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.

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

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.

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?

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

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.