November 23, 2024, 10:50:24 AM

Welcome, Guest

News: Latest Bitcoin Core release: 28.0 [Torrent]

Bitcoin Forum>Bitcoin>Development & Technical Discussion

Pages:

Author

Topic: Preparing for wx --> qt switch - page 2. (Read 6535 times)

piotr_n

legendary

Activity: 2053

Merit: 1356

aka tonikt

Quote from: error on September 21, 2011, 05:19:44 AM

Quote from: piotr_n on September 21, 2011, 05:16:17 AM

Quote

No. It's 2011. You can easily make HTML/JS app that works fine with every modern browser.

Ha! Why didn't I know this before?! What a fool I was spending countless hours, trying to make something look and work the same way in all browsers...

Oh, I'm sorry to hear that. Next time feel welcome to ask me - I will help you to write a webpage that looks the same on every browser.

Only if you consider Internet Explorer "not a modern browser."

And anyway I think you missed the sarcasm.

uTorrent's WebUI works fine with IE as well.

I didn't miss the sarcasm - I just followed it

error

hero member

Activity: 588

Merit: 500

Quote from: piotr_n on September 21, 2011, 05:16:17 AM

Quote

Oh, I'm sorry to hear that. Next time feel welcome to ask me - I will help you to write a webpage that looks the same on every browser.

Only if you consider Internet Explorer "not a modern browser."

And anyway I think you missed the sarcasm.

piotr_n

legendary

Activity: 2053

Merit: 1356

aka tonikt

Quote from: Alex Zee on September 21, 2011, 05:04:19 AM

Quote from: piotr_n on September 21, 2011, 04:50:31 AM

- no need to install any huge packages/libraries/devenv in order to modify elements of the GUI

This is solved by writing a native, not a browser GUI.

And then develop each platform independently?

Quote from: piotr_n on September 21, 2011, 04:50:31 AM

- easy to setup remote access to the GUI

When do you need it and what about security implications?

Oh. Just give me such option and let me worry about my security.
I really don't see it as a problem.

Quote from: piotr_n on September 21, 2011, 04:50:31 AM

- the ultimate platform independence (no wx, no other qt will give you that)

- the ultimate browser type and version dependence.

No. It's 2011. You can easily make HTML/JS app that works fine with every modern browser.

Quote from: piotr_n on September 21, 2011, 04:50:31 AM

You can limit the GUI to accept connections only from localhost.

...making it easier for any malicious, especially browser-based, viruses to interact with the client. I am not sure, but what if the user opens a README for some program that contains an AJAX javascript to interact with the GUI? It will be accepted because it will come from localhost.

Maybe it will, maybe it wont... You can protect HTTP session by different means.
I really don't understand your security concerns. Don't you use internet banking?

Quote from: piotr_n on September 21, 2011, 04:50:31 AM

Debugging of HTTP/JS apps is easy.

Ha! Why didn't I know this before?! What a fool I was spending countless hours, trying to make something look and work the same way in all browsers...

Oh, I'm sorry to hear that. Next time feel welcome to ask me - I will help you to write a webpage that looks the same on every browser.

Alex Zee

member

Activity: 112

Merit: 10

Quote from: piotr_n on September 21, 2011, 04:50:31 AM

- no need to install any huge packages/libraries/devenv in order to modify elements of the GUI

This is solved by writing a native, not a browser GUI.

Quote from: piotr_n on September 21, 2011, 04:50:31 AM

- easy to setup remote access to the GUI

When do you need it and what about security implications?

Quote from: piotr_n on September 21, 2011, 04:50:31 AM

- the ultimate platform independence (no wx, no other qt will give you that)

- the ultimate browser type and version dependence.

Quote from: piotr_n on September 21, 2011, 04:50:31 AM

Slower response times don't matter in this kind of application.

Slower response times matter in any kind of application. They affect subconscious feelings of users - how they feel about the application.

Quote from: piotr_n on September 21, 2011, 04:50:31 AM

You can limit the GUI to accept connections only from localhost.

...making it easier for any malicious, especially browser-based, viruses to interact with the client. I am not sure, but what if the user opens a README for some program that contains an AJAX javascript to interact with the GUI? Will it be accepted because it will come from localhost?

Quote from: piotr_n on September 21, 2011, 04:50:31 AM

Debugging of HTTP/JS apps is easy.

Ha! Why didn't I know this before?! What a fool I was spending countless hours, trying to make something look and work the same way in all browsers...

piotr_n

legendary

Activity: 2053

Merit: 1356

aka tonikt

Quote from: Alex Zee on September 20, 2011, 05:32:04 PM

Quote from: piotr_n on September 20, 2011, 04:41:06 PM

IMO the best GUI would be browser-based
... Such solution would have a number of advantages.

Such as?

Such as:
- no need to install any huge packages/libraries/devenv in order to modify elements of the GUI
- easy to setup remote access to the GUI
- the ultimate platform independence (no wx, no other qt will ever give you that)

Quote

I can think of a lot of disadvantages, such as slower interface response times, exposing your interface to anyone who connects to a port, debugging it in all the browsers and their different versions, interfering browser plugins and adblocks, phishing, etc. The GUI is very simple, you won't get much advantage by using a browser as your GUI, it will probably be more difficult.

Slower response times don't matter in this kind of application.
You can limit the GUI to accept TCP connections only from localhost.
Developing and debugging of HTTP/JS apps is easy.

To give you an example, an idea, just have a look at the WebUI of uTorrent.
It is much more complex GUI that BitCoin will ever have. And it works really great, nobody has with it any problems you've mentioned. It works with basically every modern browser.

AlexWaters

member

Activity: 77

Merit: 11

Twitter:@watersNYC

If anyone is interested in helping to test the UI, please send an email to [email protected] - a description of experience is helpful but not needed.

Alex Zee

member

Activity: 112

Merit: 10

Wow, the URI topic has surfaced again

I still love the Vladimir's scheme better as more readable:

bitcoin:/0.02/address or bitcoin://address if there is no amount

but I am so glad you guys prefer simplicity. Last time I've argued about the URI's I thought everything was lost and the Luke's "standard" will be eventually implemented

About UI / Backend split: it is important. If there was a backend right now I'd write a native Windows UI in a couple of days, without QT, without boost. It would be small and fast.

I don't believe much in a single codebase for all platforms. It works for "numbers stuff", like encryption or file access or even network. Those thing are relatively easy to port.

The GUI is different. In my opinion, it should be natively written for every platform. GIU concepts are different across platforms.

Also, I've installed QT yesterday and even if I selected only absolutely necessary stuff it took more than 1 GB! Having such a dependency for a simple GUI like this is an overkill. Plus, the less code is better from the security and reliability points of view.

Backend doesn't have to be an extension of the RPC server, that would be cumbersome. It should include (optional at compile time) RPC server, but would itself probably better be implemented as a library (both dynamic and static).

wumpus

hero member

Activity: 812

Merit: 1022

No Maps for These Territories

Quote from: Luke-Jr on September 20, 2011, 07:15:34 PM

I don't know if it's been fixed since I noticed it, but at least some version of it is lacking the ability to enable/disable UPnP support at compile-time.

This has been fixed, you can provide USE_UPNP=XXX to the qmake script (see the qt readme).

Quote from: Alex Zee on September 20, 2011, 05:32:04 PM

+1 It is a security nightmare. Suddenly everyone developing on the UI has to worry about CSRF, XSS, and so on. The browser has such a large attack surface, you'd probably make some "security researchers" very happy. .

Also, most users of any OS still expect an application to have a desktop UI not a "website in a program".

There is a web UI, though I don't know how stable or mature it is: https://github.com/zamgo/bitcoin-webskin

Quote from: Luke-Jr on September 20, 2011, 07:16:12 PM

You can already run bitcoind+Spesmilo

Yes, I recommended Spesmilo to the people that want RPC client support in bitcoin-qt.

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: justusranvier on September 18, 2011, 11:53:59 AM

Quote from: wumpus on September 18, 2011, 06:34:46 AM

For the love of separation of concerns and other sound software engineering principles I'm against combining a command line RPC client and a GUI server/native client in one executable.

Speaking as a non-developer user I would love to see a complete separation between the two.

You can already run bitcoind+Spesmilo

Luke-Jr

legendary

Activity: 2576

Merit: 1186

I don't know if it's been fixed since I noticed it, but at least some version of it is lacking the ability to enable/disable UPnP support at compile-time.
It also adds an implementation of bitcoin: URIs that is not compatible with the existing established/in-use standard.

Quote from: ThiagoCMC on September 17, 2011, 01:38:27 AM

BTW, I don't like QT... It is a ugly toolkit... GTK3 is much nicer... But, I appreciate the effort!!

Qt supports GTK2 right now, at least. I expect it will support GTK3 soon.

2112

legendary

Activity: 2128

Merit: 1073

Reading this thread it occured to me that bitcoin already has one killer application: Satoshi bitcoin client can be an excellent way to judge the competence of the applicants for a C++ programming job.

It is open source and it is fairly short. Yet its architecture is such convoluted that can be an excellent means of judging the advanced programming skills. Example: just ask an applicant what would it take to convert the wxWidgets/QT user interface to a http+ajax one. Or ask what would be required to implement a multiple wallets. Or ask to estimate the time required to replace BerkeleyDB with say Oracle.

Mad props to John Smith for having enough understanding of both UI toolkits to execute this change single-handedly.

Alex Zee

member

Activity: 112

Merit: 10

Quote from: piotr_n on September 20, 2011, 04:41:06 PM

... Such solution would have a number of advantages.

Such as?

I can think of a lot of disadvantages, such as slower interface response times, exposing your interface to anyone who connects to a port, debugging it in all the browsers and their different versions, interfering browser plugins and adblocks, phishing, etc. The GUI is very simple, you won't get much advantage by using a browser as your GUI, it will probably be more difficult.

I am all in favor of UI / backend split, but see no advantage in making main UI browser-based.

piotr_n

legendary

Activity: 2053

Merit: 1356

aka tonikt

Quote from: Gavin Andresen on September 16, 2011, 10:49:34 AM

So the plan is for the next release of bitcoin to switch from the wxWidgets GUI we have now to the vastly nicer QT GUI that John Smith created.

Don't mean to break the fun, but IMO the best GUI would be browser-based, where the client only exposes HTTP server and serves some customizable HTTP/JS app. And the user's browser does the rest. Such solution would have a number of advantages.
I think Qt is a waste of time - we will still need a huge dev env to change a dot in the GUI.

davux

sr. member

Activity: 288

Merit: 263

Firstbits.com/1davux

I'm not sure we need to switch, at least not yet. Sounds very dangerous to me not having any transitional strategy. That never works... Looking at the code and already seeing potential issues is one thing, but trying the client in real life is another one, it will unveil tons of unexpected issues. Let's be very careful, because the client is a major part (nearly 100%) of the Bitcoin network.

I'd say qt-bitcoin is (at last!) released, and people be free to use whichever client(s) they prefer. Moreover, protocols need diversity in implementations, so it's all for the better.

justusranvier

legendary

Activity: 1400

Merit: 1013

Quote from: wumpus on September 18, 2011, 06:34:46 AM

For the love of separation of concerns and other sound software engineering principles I'm against combining a command line RPC client and a GUI server/native client in one executable.

Speaking as a non-developer user I would love to see a complete separation between the two.

It would be awesome to have a server that assumes that it will be managing the wallets of everybody on a LAN and authenticates users via PAM (or whatever they use on Windows to do the same thing) and that the GUI clients were just that and nothing more.

The windows installer could install both the service and the client at the same time so those users wouldn't even know the difference and you could even use zeroconf/avahi to make it easier for the clients to find the local server.

error

hero member

Activity: 588

Merit: 500

MIT code can use LGPL libraries with no legal problem. So can just about anything else. It was the whole point of the L in LGPL.

wumpus

hero member

Activity: 812

Merit: 1022

No Maps for These Territories

I just made the big pull request: https://github.com/bitcoin/bitcoin/pull/521

To be clear, the Qt GUI can function as RPC server. You can mine with it, or interface to it from your favourite remote control script; just provide -server (and all other bitcoin command line arguments except -daemon).

It is not a RPC client. This might be added in the future (see issue #17), but in that case it will work as a graphical RPC client and not a command-line one. For the love of separation of concerns and other sound software engineering principles I'm against combining a command line RPC client and a GUI server/native client in one executable.

"Qt is an ugly toolkit" is BS, you can theme it any way you want with both images and vector graphics. You can even make it show in GTK themes. I chose QT not because of the graphical looks but because it is well-designed and encourages clean, maintainable code.

Also: as the Qt GUI is pretty much isolated from the core (only the models communicate with the core), it can serve as an example for other GUIs, or used as a starting point for moving all non-GUI code (such as lock handling) to the core and offering a nicer interface there. I did not do this because I wanted to minimize core changes.

What license issues? Qt is LGPL, just like GTK. Wx is similar "The wxWindows Licence is essentially the L-GPL (Library General Public Licence), with an exception stating that derived works in binary form may be distributed on the user's own terms" (http://www.wxwidgets.org/about/newlicen.htm)

Quote

I spent some time yesterday compiling Qt and bitcoin-qt, and some time this morning doing a very quick code review (executive summary: looks great!).

Thanks!

ThiagoCMC

legendary

Activity: 1204

Merit: 1000

฿itcoin: Currency of Resistance!

Quote from: zwierzak on September 17, 2011, 06:23:20 AM

Quote from: ThiagoCMC on September 17, 2011, 01:38:27 AM

BTW, I don't like QT... It is a ugly toolkit... GTK3 is much nicer... But, I appreciate the effort!!

Anyway, do you know, more or less, when the Bitcoin core will be decoupled of the GUIs?! I mean, when will be only somekind of oficial LibBitcoin and a lots of GUIs, like QT, WX, GTK3, GTK2... Huh

BTW, I don't like GTK… It is a ugly library that needs more libraries to call it ugly toolkit… Qt is much nicer… Thanks for the effort!

Ok other thing. Do you know that in Qt you have built in GTK style? It import the current GTK system and maps it on Qt application (also with switched order od OK and Cancel in dialog box). It should be automaticly turn on if Qt detects Gnome session, but you can change it running qt-config.

Well, honestly, you have the point... And I agree with you... GTK have its own problems, so as QT (license issues?! Don't know anymore, in the past, yes...)...

But my point is, and I just like to have an idea about it, I'm not demanding this from anybody ok... When the Bitcoin will be detached from the GUI / Daemon? Is there any roadmap for this?!

I like to see tons of GUIs (QT, GTK3/2, ELF, OpenStep, Aqua, Windows, etc...) using the same "LibBitcoin" (from http://bitcoin.org), including the non-gui bitcoind...

BTW, what about Enlightenment Foundation Libraries?! I think it is one of the most amazing open source toolkit out there... Don't you think!? http://www.enlightenment.org/

I'm asking this because I have a draft of my own Bitcoin GUI and I'll hire two developers (friend of mine) to write the GUI... But first, I see that we need a libbitcoin or something like that befora start anything like that...

Thank you!
Thiago

zwierzak

newbie

Activity: 24

Merit: 0

Quote from: ThiagoCMC on September 17, 2011, 01:38:27 AM

nibor

sr. member

Activity: 438

Merit: 291

Quote from: Gavin Andresen on September 16, 2011, 04:56:38 PM

Quote from: nibor on September 16, 2011, 02:58:37 PM

Could you or someone provide a list of future version numbers you are intending to use?

0.4.0 : Out real soon (0.4.0 release candidate 2 binaries are available on sourceforge now)

0.4.1 : I'd give about a 80% chance of happening (major bug or security problem found in 0.4.0)
0.4.2 : I'd give about a 20% chance of happening (major bug or security problem found in 0.4.1)

0.5.0 : Will be the Qt release.

Beyond that... who knows?

So the integers will be:
40000
41000
42000
50000

This follows on from the current ones that are:
32400
32500
etc...

Pages:

Bitcoin Forum>Bitcoin>Development & Technical Discussion

Jump to: