Bitcoin Forum
December 07, 2016, 10:56:56 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 [2] 3 »  All
  Print  
Author Topic: Preparing for wx --> qt switch  (Read 5767 times)
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2086



View Profile
September 21, 2011, 12:15:34 AM
 #21

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.


1481108216
Hero Member
*
Offline Offline

Posts: 1481108216

View Profile Personal Message (Offline)

Ignore
1481108216
Reply with quote  #2

1481108216
Report to moderator
1481108216
Hero Member
*
Offline Offline

Posts: 1481108216

View Profile Personal Message (Offline)

Ignore
1481108216
Reply with quote  #2

1481108216
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481108216
Hero Member
*
Offline Offline

Posts: 1481108216

View Profile Personal Message (Offline)

Ignore
1481108216
Reply with quote  #2

1481108216
Report to moderator
1481108216
Hero Member
*
Offline Offline

Posts: 1481108216

View Profile Personal Message (Offline)

Ignore
1481108216
Reply with quote  #2

1481108216
Report to moderator
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2086



View Profile
September 21, 2011, 12:16:12 AM
 #22

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
Hero Member
*****
qt
Offline Offline

Activity: 798

No Maps for These Territories


View Profile
September 21, 2011, 06:23:12 AM
 #23

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

Bitcoin Core developer [PGP] Warning: For most, coin loss is a larger risk than coin theft. A disk can die any time. Regularly back up your wallet through FileBackup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts.
Alex Zee
Member
**
Offline Offline

Activity: 112



View Profile WWW
September 21, 2011, 07:24:11 AM
 #24

Wow, the URI topic has surfaced again Smiley

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 Smiley

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

BTC Monitor - systray price ticker
RipTalk.org - new Ripple forum
AlexWaters
Member
**
Offline Offline

Activity: 72


Coin.co | Twitter:@watersNYC


View Profile
September 21, 2011, 09:32:36 AM
 #25

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
Legendary
*
Offline Offline

Activity: 1498


aka tonikt


View Profile WWW
September 21, 2011, 09:50:31 AM
 #26

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.

Check out gocoin - my original project of a bitcoin client written in Go, with some unique features.
PGP fingerprint: AB9E A551 E262 A87A 13BB  9059 1BE7 B545 CDF3 FD0E
Alex Zee
Member
**
Offline Offline

Activity: 112



View Profile WWW
September 21, 2011, 10:04:19 AM
 #27

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


BTC Monitor - systray price ticker
RipTalk.org - new Ripple forum
piotr_n
Legendary
*
Offline Offline

Activity: 1498


aka tonikt


View Profile WWW
September 21, 2011, 10:16:17 AM
 #28

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

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

Check out gocoin - my original project of a bitcoin client written in Go, with some unique features.
PGP fingerprint: AB9E A551 E262 A87A 13BB  9059 1BE7 B545 CDF3 FD0E
error
Hero Member
*****
Offline Offline

Activity: 574



View Profile
September 21, 2011, 10:19:44 AM
 #29

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

15UFyv6kfWgq83Pp3yhXPr8rknv9m6581W
piotr_n
Legendary
*
Offline Offline

Activity: 1498


aka tonikt


View Profile WWW
September 21, 2011, 10:23:42 AM
 #30

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. Smiley
uTorrent's WebUI works fine with IE as well.

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

Check out gocoin - my original project of a bitcoin client written in Go, with some unique features.
PGP fingerprint: AB9E A551 E262 A87A 13BB  9059 1BE7 B545 CDF3 FD0E
Alex Zee
Member
**
Offline Offline

Activity: 112



View Profile WWW
September 21, 2011, 10:29:10 AM
 #31

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.

BTC Monitor - systray price ticker
RipTalk.org - new Ripple forum
Cryptoman
Hero Member
*****
Offline Offline

Activity: 728



View Profile
September 21, 2011, 03:22:40 PM
 #32

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.  Tongue  Anyway, props to the developers for their contributions and for putting up with the criticisms from the community.

"A small body of determined spirits fired by an unquenchable faith in their mission can alter the course of history." --Gandhi
piotr_n
Legendary
*
Offline Offline

Activity: 1498


aka tonikt


View Profile WWW
September 21, 2011, 04:23:53 PM
 #33

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 Smiley

Check out gocoin - my original project of a bitcoin client written in Go, with some unique features.
PGP fingerprint: AB9E A551 E262 A87A 13BB  9059 1BE7 B545 CDF3 FD0E
Alex Zee
Member
**
Offline Offline

Activity: 112



View Profile WWW
September 21, 2011, 05:33:26 PM
 #34


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.

BTC Monitor - systray price ticker
RipTalk.org - new Ripple forum
piotr_n
Legendary
*
Offline Offline

Activity: 1498


aka tonikt


View Profile WWW
September 21, 2011, 05:41:41 PM
 #35


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.

Check out gocoin - my original project of a bitcoin client written in Go, with some unique features.
PGP fingerprint: AB9E A551 E262 A87A 13BB  9059 1BE7 B545 CDF3 FD0E
flower1024
Hero Member
*****
Offline Offline

Activity: 868


luck is just a share away


View Profile
September 21, 2011, 05:42:49 PM
 #36

+1
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2086



View Profile
September 21, 2011, 05:59:25 PM
 #37

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

2112
Legendary
*
Offline Offline

Activity: 1708



View Profile
September 21, 2011, 06:39:00 PM
 #38

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.

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
flower1024
Hero Member
*****
Offline Offline

Activity: 868


luck is just a share away


View Profile
September 21, 2011, 06:46:38 PM
 #39

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
Member
**
Offline Offline

Activity: 112



View Profile WWW
September 21, 2011, 06:48:21 PM
 #40

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.

BTC Monitor - systray price ticker
RipTalk.org - new Ripple forum
Pages: « 1 [2] 3 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!