Bitcoin-qt ready for merging

Hi,

Bitcoin-qt is now feature complete (including wallet encryption), and has been tested for a while by various people without any major problems.

It is now in status of feature freeze.

The project builds on Windows, MacOSX and Linux using qmake.

Impact to the core bitcoin functions is still minimal, and it can co-exist with Wx in the source tree. The only thing it lacks compared to the Wx GUI is translations, currently we only have English, Dutch and Russian.

So IMO, it is ready to be merged.

JS

On Wed, 2011-08-31 at 14:20 +0000, John Smith wrote:

> Hi,
>
> Bitcoin-qt is now feature complete (including wallet encryption), and
> has been tested for a while by various people without any major
> problems.
>
> It is now in status of feature freeze.
>
> The project builds on Windows, MacOSX and Linux using qmake.
>
> Impact to the core bitcoin functions is still minimal, and it can
> co-exist with Wx in the source tree. The only thing it lacks compared
> to the Wx GUI is translations, currently we only have English, Dutch
> and Russian.

Would it be possible to port some of the existing translations? Something is better than nothing so some text that is close to the wx version can just be copied. Though IMHO its not a huge deal if qt is merged without all the translations as IMHO it should be merged soon and then not the default release GUI until its in tree for a bit (like one release) and some translations can be built up.

>
> So IMO, it is ready to be merged.

IMHO it should be merged right after 0.4 is pushed.

Would it be possible to port some of the existing translations?

>

Well, the strings in the core can be reused one-on-one as the _ function is mapped to the Qt translation function.

And some of the UI texts probably can be reused as well, at least for a rough approximation.

The files will have to be converted, as Qt uses an XML-based format whereas Wx uses a line-based one. Also, Qt translations have a "context" (file/object) defined whereas in Wx the "msgid" is only the English text. Nah, nothing that a bit of Python hacking can't solve.

Though IMHO its not a huge deal if qt is merged without all the

> translations as IMHO it should be merged soon and then not the default
> release GUI until its in tree for a bit (like one release) and some
> translations can be built up.
>

Exactly... if there is some time between Qt being merged and Wx being phased out, translations can be added. The Qt translation tool (Qt Linguist) is user friendly enough to be used by anyone.

>
> > So IMO, it is ready to be merged.
> IMHO it should be merged right after 0.4 is pushed.
>

Sounds fine with me,

JS

On Wednesday, August 31, 2011 10:20:48 AM John Smith wrote:

> The project builds on Windows, MacOSX and Linux using qmake.

How do you set build options with qmake?

On Thu, Sep 1, 2011 at 2:13 AM, Luke-Jr <luke@dashjr•org> wrote:

> On Wednesday, August 31, 2011 10:20:48 AM John Smith wrote:
> > The project builds on Windows, MacOSX and Linux using qmake.
>
> How do you set build options with qmake?
>

You can put assignments on the commandline; for example,

qmake "CONFIG+=test" test.pro

Like in plain make, these variables can be used for conditionally enabling/disabling libraries or other options in the .pro file.

http://doc.qt.nokia.com/latest/qmake-manual.html

(reminds me that I still need to add the USE_UPNP option)

Note that qmake is a pretty simple tool, optimized for conveniently building Qt applications in a cross-platform way; it in no way compares to cmake/autotools or another "full" build system. But it's enough for building bitcoin-qt on the supported target architectures so that's good enough for me... For "bitcoind" and "bitcoin-wx" you probably want to keep around the makefile.

JS

Can you please submit a pull request and testing plan? If these already exist, can you please link them here?

I'm exciting to get this in, as it will close the wx issues. (and hopefully not bring on too many qt issues)

Thanks, Alex

Hello Alex,

On Sun, Sep 11, 2011 at 12:20 AM, Alex Waters <ampedal@gmail•com> wrote:

> Can you please submit a pull request and testing plan? If these already
> exist, can you please link them here?

What testing plan do you need?

JS

Alex,

On Sun, Sep 11, 2011 at 7:45 AM, Alex Waters <ampedal@gmail•com> wrote:

> Hey John,
>
> It could be as simple as listing some things that you think could possibly
> break if qt is implemented. For example, "check the UI for artifacts". I
> don't really know what could potentially need to be tested, so any help
> would get things processed faster.
>
> I can't acknowledge a pull unless there is substantial evidence that it's
> been tested, especially something of this size...
>

It has been under development for a long time, the thread on the bitcointalk forum is "substantial evidence" that many people are using it (also, I receive quite a lot of mail about it, and the number of followers on github steadily fluctuates around ~30). So nothing obvious is broken, at least, I think has worked better than the Wx UI for quite a while.

But as I've said before I'm fine with keeping bitcoin-qt as a parallel, experimental, release for a while. I think that's the only way to get more testing with people that don't want to or can't build from source (could just mark the download as "New GUI, experimental" or so...).

To be honest I think it should be merged at least as experimental ASAP, it would save a lot of GUI complaints on the forum about things I've implemented months ago already. However I will only put up a pull request as soon as it is clear that it will actually be integrated. It is too much work for me to keep the pull request up-to-date if it lingers for months like many others have.

JS

On Sun, Sep 11, 2011 at 5:54 AM, John Smith <witchspace81@gmail•com> wrote:

> However I will only put up a pull request as
> soon as it is clear that it will actually be integrated. It is too much work
> for me to keep the pull request up-to-date if it lingers for months like
> many others have.

I haven't heard any objections to pulling it as soon as 0.4 is officially released, a pull request is ready, and a couple of people have a chance to read over the differences and ACKnowledge that nothing sinister snuck in somewhere.

Various issues with bitcoin-qt's qmake build system still...

Regressions remaining on bitcoin-qt branch: - Building without DBus still tries to use dbus symbols (and fails linking) - No way to disable SSL support for JSON-RPC - UPnP is no longer built/enabled by default

These weren't quite working in the old makefiles either, but it was a lot
easier to workaround with DEBUGFLAGS:
- No way to specify include path or library names for bdb and boost
  (won't build, since bdb C++ includes aren't default on many OS)
- No way to build with out-of-tree/system cryptopp or json