Preparing for wx --> qt switch

[Luke-Jr]

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.

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.

[Luke-Jr]

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

[wumpus]

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

It also adds an implementation of bitcoin: URIs that is not compatible with the existing established/in-use standard.

It's just a wiki page, not a standard. In my (and Gavin's and many others) opionion URLs should be as simple as possible. The 1243X45 exponent stuff is simply arcane.

I do agree more standardization should happen, an "official" Bitcoin URL format would be an interesting subject for a BEP. When that standard format is determined, it will of course be integrated into the client.

Until then, we chose the most simple format possible, which can be described in one line: bitcoin:<addr>?label=<label>&amount=<BTC>   (label and amount are optional)

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.

+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

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

A network UI/backend split would "only" be a matter of extending the RPC enough to make a full-functional UI (it especially needs async notifications/callbacks).

You can already run bitcoind+Spesmilo

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

[Alex Zee]

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

[AlexWaters]

If anyone is interested in helping to test the UI, please send an email to QA@BitcoinTesting.org - a description of experience is helpful but not needed.

[piotr_n]

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)

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.

[Alex Zee]

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

- easy to setup remote access to the GUI

When do you need it and what about security implications?

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

- the ultimate browser type and version dependence.

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.

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?

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]

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

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

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

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

Sounds like you are a real expert in this domain - I'm not going to argue here.

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?

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.

[error]

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.

[piotr_n]

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

[Alex Zee]

And then develop each platform independently?

The GUI is trivial. If there is a cross-platform backend, writing a GUI will be just a matter of several days.

See no point in arguing about the rest of your points - I've already stated my opinions about them.

[Cryptoman]

I just want to say that I'm very enthusiastic about the switch to Qt.  The fact that my window manager of choice is KDE probably has a lot to do with that.    Anyway, props to the developers for their contributions and for putting up with the criticisms from the community.

[piotr_n]

And then develop each platform independently?

The GUI is trivial. If there is a cross-platform backend, writing a GUI will be just a matter of several days.

For me it's not about writing a GUI for the current client - there is already a GUI for the current client, so why to change it? Just so it would respond a few ms quicker on mouse clicks? Maybe that would be a good reason if it was slow, but it isn't slow. The biggest problem of the current GUI is that it's a hassle to change anything in it and hard to control/review the changes.

I thought wx was being abandoned to make further development of bitcoin's UI easier - that would be a good reason.
Unfortunately IMO you won't make further GUI development easier by switching from wx to Qt.

Maybe the GUI shall be indeed a separate application which talks to bitcoind via some interface - like the JSON-RPC, but with both-way notifications, so the GUI doesn't need to pull for data.
Then you could create your OS-specific GUI, while I'd do my web based one - and everybody would be happy

[Alex Zee]

The most flexible solution would be to create one cross-platform "block-chain server", which only serves as a storage for the block-chain and handles connections.

Any app checks if such server is installed on the system and whether it's running or not. Runs it if it's not started.

This "block-chain server" will have nothing to do with wallets, so no protection is needed.

The client handles all wallet-related stuff and registers a global URI handler.

Any other application, such as a miner, that needs to access block-chain does this easily with no security concerns.

Any application or a browser that wants to send money simply opens the URI, the same way links or magnets are handled. The default "wallet app" pops up a dialog to the user and he either confirms or denies this request.

[piotr_n]

The most flexible solution would be to create one cross-platform "block-chain server", which only serves as a storage for the block-chain and handles connections.

Any app checks if such server is installed on the system and whether it's running or not. Runs it if it's not started.

This "block-chain server" will have nothing to do with wallets, so no protection is needed.

The client handles all wallet-related stuff and registers a global URI handler.

Any other application, such as a miner, that needs to access block-chain does this easily with no security concerns.

Any application or a browser that wants to send money simply opens the URI, the same way links or magnets are handled. The default "wallet app" pops up a dialog to the user and he either confirms or denies this request.

I like it. Sounds like a good split.

[flower1024]

+1

[Luke-Jr]

https://en.bitcoin.it/wiki/Infrastructure

[2112]

I have a semi-constructive proposal. There has been a lot of whining and quarter-baked proposals floating about changes and improvements to the Satoshi client. It is hard to judge whether these proposals are made by incompetent programmers or just programmers that haven't thoroughly reviewed the code and its architecture.

To save the further anguish I propose that anyone who wants to be treated seriously should explain how his proposed improvement will deal with the following pseudo-code (from wallet.cpp & ui.cpp):

CWallet::SendMoney() {
    grab_the_wallet_lock();
    solve_inverted_knapsack_problem_to_select_the_best_coin_subset();
    fee = compute_the_required_transaction_fee();
    yesno = ::ThreadSafeAskFee(fee);
    commit_transaction_and_release_lock(yesno);
}

Basically, show us that you know how to solve the inversion of control problem that is posed by this code. For extra credit, show us that your modification will deal properly with chain reorganization while waiting inside the UI for the user to accept the fee.

If you don't know how to solve those problems please send your proposal to /dev/null or nul:, as the case may be.

I think John Smith did a feat of software engineering comparable to doing a successful face transplant on a Frankenstein.

[flower1024]

I have a semi-constructive proposal. There has been a lot of whining and quarter-baked proposals floating about changes and improvements to the Satoshi client. It is hard to judge whether these proposals are made by incompetent programmers or just programmers that haven't thoroughly reviewed the code and its architecture.

To save the further anguish I propose that anyone who wants to be treated seriously should explain how his proposed improvement will deal with the following pseudo-code (from wallet.cpp & ui.cpp):

CWallet::SendMoney() {
    grab_the_wallet_lock();
    solve_inverted_knapsack_problem_to_select_the_best_coin_subset();
    fee = compute_the_required_transaction_fee();
    yesno = ::ThreadSafeAskFee(fee);
    commit_transaction_and_release_lock(yesno);
}

Basically, show us that you know how to solve the inversion of control problem that is posed by this code. For extra credit, show us that your modification will deal properly with chain reorganization while waiting inside the UI for the user to accept the fee.

If you don't know how to solve those problems please send your proposal to /dev/null or nul:, as the case may be.

I think John Smith did a feat of software engineering comparable to doing a successful face transplant on a Frankenstein.

maybe:
client sets a default fee for every transaction and server just checks if currentfee<defaultfee and sends it?

if its bigger it could return and the client could retry with another defaultfee.

[Alex Zee]

I have a semi-constructive proposal. There has been a lot of whining and quarter-baked proposals floating about changes and improvements to the Satoshi client. It is hard to judge whether these proposals are made by incompetent programmers or just programmers that haven't thoroughly reviewed the code and its architecture.

To save the further anguish I propose that anyone who wants to be treated seriously should explain how his proposed improvement will deal with the following pseudo-code (from wallet.cpp & ui.cpp):

CWallet::SendMoney() {
    grab_the_wallet_lock();
    solve_inverted_knapsack_problem_to_select_the_best_coin_subset();
    fee = compute_the_required_transaction_fee();
    yesno = ::ThreadSafeAskFee(fee);
    commit_transaction_and_release_lock(yesno);
}

Basically, show us that you know how to solve the inversion of control problem that is posed by this code. For extra credit, show us that your modification will deal properly with chain reorganization while waiting inside the UI for the user to accept the fee.

If you don't know how to solve those problems please send your proposal to /dev/null or nul:, as the case may be.

I think John Smith did a feat of software engineering comparable to doing a successful face transplant on a Frankenstein.

Yeah, yeah, yeah... You're smart, we're stupid. We got it.


BTW, Frankenstein is the name of the creator, not the monster, smart ass.