Bitcoin Forum

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

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

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.

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"

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.

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.

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.

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.

teknohog couldn't have explained my view better.


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.

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?

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)

No, I'm just saying that the daemon doesn't need WxWidgets.

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


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.