[Bitcoin-development] Bitcoin-qt ready for merging

[Bitcoin-development] Bitcoin-qt ready for merging

[John Smith]

[-- Attachment #1: Type: text/plain, Size: 509 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 560 bytes --]

Re: [Bitcoin-development] Bitcoin-qt ready for merging

[Matt Corallo]

[-- Attachment #1: Type: text/plain, Size: 1062 bytes --]

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.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [Bitcoin-development] Bitcoin-qt ready for merging

[John Smith]

[-- Attachment #1: Type: text/plain, Size: 1106 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1733 bytes --]

Re: [Bitcoin-development] Bitcoin-qt ready for merging

[Luke-Jr]

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?

Re: [Bitcoin-development] Bitcoin-qt ready for merging

[John Smith]

[-- Attachment #1: Type: text/plain, Size: 954 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1409 bytes --]

Re: [Bitcoin-development] Bitcoin-qt ready for merging

[Luke-Jr]

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

Re: [Bitcoin-development] Bitcoin-qt ready for merging

[Alex Waters]

[-- Attachment #1: Type: text/plain, Size: 234 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 297 bytes --]

Re: [Bitcoin-development] Bitcoin-qt ready for merging

[John Smith]

[-- Attachment #1: Type: text/plain, Size: 238 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 489 bytes --]

Re: [Bitcoin-development] Bitcoin-qt ready for merging

[John Smith]

[-- Attachment #1: Type: text/plain, Size: 1522 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1894 bytes --]

Re: [Bitcoin-development] Bitcoin-qt ready for merging

[Gavin Andresen]

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.

-- 
--
Gavin Andresen