Bitcoin Forum
April 25, 2024, 02:25:40 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Convert Bitcoin to GTK: Yes? No? wx is better?  (Read 9445 times)
mizerydearia (OP)
Hero Member
*****
Offline Offline

Activity: 574
Merit: 507



View Profile
August 19, 2010, 07:23:53 AM
Last edit: August 19, 2010, 07:47:17 AM by mizerydearia
 #1

Who is skilled enough to convert official Linux Bitcoin client to use GTK instead of wx?

Is this development worthy or desirable enough to pursue or is wx acceptable?

q: let me get this straight. You're asking if someone will put up a bounty for a conversion that you want? (bounty idea dismissed due to seeming weird/strange to some)
a: I don't want it. Is GTK better than QT or anytihng else?  I'm not familiar.

"I would like it if Bitcoin used GTK instead of wxWidgets but I won't pretend that I have a clue about how hard or easy that change might be"

someone: wx seems to work now as far as I can tell
someone else: wx is an utter nightmare

q: why "convert" Satoshi's front end? Why not just build a new one that uses the rpc calls?

there actually isn't much that needs to be done to make bitcoind's methods useful enough to do the same things the GUI does:
in particular:
 * list sending addresses
 * show unaccepted blocks in listtransactions (maybe)
 * select a range of transactions to show
1714055140
Hero Member
*
Offline Offline

Posts: 1714055140

View Profile Personal Message (Offline)

Ignore
1714055140
Reply with quote  #2

1714055140
Report to moderator
1714055140
Hero Member
*
Offline Offline

Posts: 1714055140

View Profile Personal Message (Offline)

Ignore
1714055140
Reply with quote  #2

1714055140
Report to moderator
BitcoinCleanup.com: Learn why Bitcoin isn't bad for the environment
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1714055140
Hero Member
*
Offline Offline

Posts: 1714055140

View Profile Personal Message (Offline)

Ignore
1714055140
Reply with quote  #2

1714055140
Report to moderator
sirius
Bitcoiner
Sr. Member
****
Offline Offline

Activity: 429
Merit: 974



View Profile
August 19, 2010, 07:30:57 AM
 #2

Hmm... would it run on Maemo with the same code then? Any other advantages?

Iris — for better social networks
I'm not a forum admin - please contact theymos instead.
theymos
Administrator
Legendary
*
Offline Offline

Activity: 5180
Merit: 12884


View Profile
August 19, 2010, 07:34:48 AM
 #3

bitcoind's commands should be expanded and binaries for it should be released so that third-party UI development can be made easier. Like Tor.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
mizerydearia (OP)
Hero Member
*****
Offline Offline

Activity: 574
Merit: 507



View Profile
August 19, 2010, 07:39:06 AM
Last edit: August 19, 2010, 07:49:45 AM by mizerydearia
 #4

It would be interesting for bitcoin to be designed in a way that an ncurses ui could be designed.
 "you certainly can build a ncurses front end to the deamon now. Its not a problem for bitcoin"
Olipro
Member
**
Offline Offline

Activity: 70
Merit: 10


View Profile
August 19, 2010, 07:51:13 AM
 #5

Yeah, my opinion on this is that the GUI should be separated from the underlying code. BUT... there's no need to throw the baby out with the bathwater and I firmly believe that the current wxWidgets interface should be maintained until such a time as something superior comes along.

My personal feeling is that whilst separate daemon/GUI binaries can work, it also tends to be messy, I'd be far more in favour of having the core code and then separate source that you compile with it according to your target OS, that way everything is still a single binary and can be integrated as idealistically as possible.

To put this in practice, imagine 3 SVN trunks; the first is BitCoin core, the other two are LINGUI and WINGUI - the latter two being dependant on code from the first.
BioMike
Legendary
*
Offline Offline

Activity: 1658
Merit: 1001


View Profile
August 19, 2010, 08:05:18 AM
 #6

WxWidgets is not really a problem. My problem is the version that is used (2.9), which is considered unstable by many distro packagers (although the WxWidgets devs say it isn't). On the other side, as far as I know WxWidgets uses gtk under Linux for drawing the whole stuff and makes it for the bitcoins devs easy to make things cross platform.

I think I would go with theymos in that the gui and daemon should be separated (or put the whole protocols and stuff in a library with bindings for different languages for that matter). I've already gotten my own "client" running (see http://bitcointalk.org/index.php?topic=851.0) with the daemon (who doesn't need WxWidgets anymore) and it works very nicely. So, in my case I don't have any dependency on WxWidgets any more.
lfm
Full Member
***
Offline Offline

Activity: 196
Merit: 104



View Profile
August 19, 2010, 10:28:19 AM
 #7

I think I would go with theymos in that the gui and daemon should be separated (or put the whole protocols and stuff in a library with bindings for different languages for that matter). I've already gotten my own "client" running (see http://bitcointalk.org/index.php?topic=851.0) with the daemon ...

So what do you mean the gui and the daemon should be separated? They already are. You can build the separate daemon. Do you need a separate build of only the gui? I can't see why.
teknohog
Sr. Member
****
Offline Offline

Activity: 519
Merit: 252


555


View Profile WWW
August 19, 2010, 02:59:59 PM
 #8

So what do you mean the gui and the daemon should be separated? They already are. You can build the separate daemon. Do you need a separate build of only the gui? I can't see why.

Bitcoin is a P2P network, so the program should be running all the time. However, I don't need to be looking at a GUI all that time, so it makes sense to have a daemon. Currently, you have to stop the daemon when you want to start the GUI version, which breaks the network for a moment.

Some P2P applications like aMule do this properly. The daemon is running all the time, and when you want to interact with it, you start the separate GUI, which connects to the daemon. Most importantly, the GUI can run on a different machine from the daemon.

Such a setup would be great for mobile Bitcoin usage. You run the daemon on your "server" machine, and you connect to it with a GUI on your mobile device. I think this has been already discussed in a different context, but the same mechanism applies.

However, you can already use the JSON-RPC mechanism to build a separate GUI, so there is no immediate need to change the mainline client.

world famous math art | masternodes are bad, mmmkay?
Every sha(sha(sha(sha()))), every ho-o-o-old, still shines
satoshi
Founder
Sr. Member
*
qt
Offline Offline

Activity: 364
Merit: 6723


View Profile
August 19, 2010, 06:44:36 PM
 #9

WxWidgets is not really a problem. My problem is the version that is used (2.9), which is considered unstable by many distro packagers (although the WxWidgets devs say it isn't). On the other side, as far as I know WxWidgets uses gtk under Linux for drawing the whole stuff and makes it for the bitcoins devs easy to make things cross platform.
wxWidgets 2.9 is their first UTF-8 version.  We are UTF-8 on all platforms including Windows.

The distro packages of 2.8 are UTF-16, so they just trip people up.  People had endless build problems with 2.8 and its wxString UTF-16/ANSI conditional build options until we standardized on 2.9.  Also, to use 2.8, we were using ANSI, which was just a temporary stopgap until wxWidgets supported UTF-8.

This is a problem that will solve itself.  With time, 2.9 will become a more mainline release.
BioMike
Legendary
*
Offline Offline

Activity: 1658
Merit: 1001


View Profile
August 19, 2010, 06:55:38 PM
 #10

teknohog couldn't have explained my view better.

WxWidgets is not really a problem. My problem is the version that is used (2.9), which is considered unstable by many distro packagers (although the WxWidgets devs say it isn't). On the other side, as far as I know WxWidgets uses gtk under Linux for drawing the whole stuff and makes it for the bitcoins devs easy to make things cross platform.
wxWidgets 2.9 is their first UTF-8 version.  We are UTF-8 on all platforms including Windows.

The distro packages of 2.8 are UTF-16, so they just trip people up.  People had endless build problems with 2.8 and its wxString UTF-16/ANSI conditional build options until we standardized on 2.9.  Also, to use 2.8, we were using ANSI, which was just a temporary stopgap until wxWidgets supported UTF-8.

This is a problem that will solve itself.  With time, 2.9 will become a more mainline release.

Yes, I understand why 2.9 was chosen. And I think it is also reasonable, but just unfortunate for people who just want to install the dep from their distro. (Under gentoo it b0rks up building other Wxwidget apps when having 2.9 installed into /usr/local)
lfm
Full Member
***
Offline Offline

Activity: 196
Merit: 104



View Profile
August 20, 2010, 10:02:09 PM
 #11

teknohog couldn't have explained my view better.

WxWidgets is not really a problem. My problem is the version that is used (2.9), which is considered unstable by many distro packagers (although the WxWidgets devs say it isn't). On the other side, as far as I know WxWidgets uses gtk under Linux for drawing the whole stuff and makes it for the bitcoins devs easy to make things cross platform.
wxWidgets 2.9 is their first UTF-8 version.  We are UTF-8 on all platforms including Windows.

The distro packages of 2.8 are UTF-16, so they just trip people up.  People had endless build problems with 2.8 and its wxString UTF-16/ANSI conditional build options until we standardized on 2.9.  Also, to use 2.8, we were using ANSI, which was just a temporary stopgap until wxWidgets supported UTF-8.

This is a problem that will solve itself.  With time, 2.9 will become a more mainline release.

Yes, I understand why 2.9 was chosen. And I think it is also reasonable, but just unfortunate for people who just want to install the dep from their distro. (Under gentoo it b0rks up building other Wxwidget apps when having 2.9 installed into /usr/local)

Seems to me it is a good reason to leave Bitcoin as Beta status until this is resolved. Either wx 2.9 becomes easier to install or Bitcoin converts to something else.
BioMike
Legendary
*
Offline Offline

Activity: 1658
Merit: 1001


View Profile
August 21, 2010, 05:48:42 AM
 #12

Seems to me it is a good reason to leave Bitcoin as Beta status until this is resolved. Either wx 2.9 becomes easier to install or Bitcoin converts to something else.

Or build only the daemon and not the graphical version. Then no WxWidgets are needed.
lfm
Full Member
***
Offline Offline

Activity: 196
Merit: 104



View Profile
August 21, 2010, 08:14:10 AM
 #13

Seems to me it is a good reason to leave Bitcoin as Beta status until this is resolved. Either wx 2.9 becomes easier to install or Bitcoin converts to something else.

Or build only the daemon and not the graphical version. Then no WxWidgets are needed.

Are you saying the daemon should have a different separate version number which maybe is not labled Beta while the GUI full program remains version 0.x.x Beta?
nimnul
Sr. Member
****
Offline Offline

Activity: 252
Merit: 250


View Profile WWW
August 21, 2010, 09:36:21 AM
 #14

I think most clients are Windows, and for Windows wx is not a problem since binaries provided by Satoshi work everywhere.

For Linux servers wx is not a problem either, because bitcoind doesn't require wx.

The only area for which wx is still problematic are Linux workstation, and I suppose only few people use that.

For me, the main showstoppers on Linux are:
1) Boost non-headeronly libraries (I think Bitcoind requires boost.filesystem to be built first using bjam/Boost.Build)
2) Dependency on OpenSSL for ECDSA

Boost distribution is old on CentOS, and OpenSSL is build without ECDSA, so you have to build those yourself.

WX does its job well, and I think theres absolutely no need to 'convert'. But building a GTK gui (GTK works on Windows too) in addition to WX gui is still beneficial if GTK version used is already mainline in most Linux distros.

So:
1) please don't use boost.filesystem or other small and easily replaced functionality from Boost that requires Boost.Build for compilation.
2) please extract ECDSA from OpenSSL just like you did with SHA256/CryptoPP.

These two tasks are much more important for community as a whole than building an alternative GUI frontend, because that will make build much easier on many distros (I'm mostly interested in CentOS though)

BioMike
Legendary
*
Offline Offline

Activity: 1658
Merit: 1001


View Profile
August 21, 2010, 04:37:57 PM
 #15

Seems to me it is a good reason to leave Bitcoin as Beta status until this is resolved. Either wx 2.9 becomes easier to install or Bitcoin converts to something else.

Or build only the daemon and not the graphical version. Then no WxWidgets are needed.

Are you saying the daemon should have a different separate version number which maybe is not labled Beta while the GUI full program remains version 0.x.x Beta?

No, I'm just saying that the daemon doesn't need WxWidgets.
lfm
Full Member
***
Offline Offline

Activity: 196
Merit: 104



View Profile
August 23, 2010, 05:53:29 AM
 #16

The only area for which wx is still problematic are Linux workstation, and I suppose only few people use that.

Yet that is where the complaints are coming from I think.

Quote
For me, the main showstoppers on Linux are:
1) Boost non-headeronly libraries (I think Bitcoind requires boost.filesystem to be built first using bjam/Boost.Build)
2) Dependency on OpenSSL for ECDSA

Boost distribution is old on CentOS, and OpenSSL is build without ECDSA, so you have to build those yourself.

I think your points are Centos/RedHat specific. People working with Debian/Ubuntu have much greater trouble with wx 2.9 than boost or openssl which work fine in their standard packages (for recent enough releases at least).

Not that your points are at all wrong or misleading, just those problems may not be as widespread as you think.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!