Move to Qt?

[Dirk Hohndel]

"Lubomir I. Ivanov" <neolit123 at gmail.com> writes:

> On 29 March 2013 00:37, Amit Chaudhuri <amit.k.chaudhuri at gmail.com> wrote:
>>
>> ...oops...hit some key combination that sent too soon...
>>
>> ...I personally believe that Qt is far easier to handle and provides better behaviour out of the box and is easier to customise than GTK.  However, if we collectively lack Qt skills a shift from GTK to Qt may not lead to a major step change in this area.
>>
>
> someone should correct me on this, but i think, currently there are
> more people on this mailing list being more familiar with GTK over Qt?
> i admit thought, that if i have a new GUI project to work on i would
> probably choose Qt for it.

When we did an informal poll a while ago we had four people who admitted
that if forced at gun point they'd be able to write Gtk code and also
four people who said they'd love to contribute if this was migrated to
Qt. We also had a few people from the outside show interest in
contributing to a Qt version - I am following up with them to find out
how serious they are.

And I will post on G+ and see if we can find a few more interested
contributors there :-)

>> I am sure that I can contribute more to a Qt-based application than a GTK based one, but that alone is hardly a compelling reason to make the move.  But this question keeps coming up so I'm willing to put up examples widgets etc. to nudge things in that direction over time.  I'll happily stick the treeview example on the web after Easter, for example.
>>
>> Are there others on this list at the moment with Qt experience?

I have some experience with Qt. I actually have MORE Qt experience then
I had Gtk experience when I started working on Subsurface a year and a
half ago. But thanks to Subsurface I think I now know Gtk better. But
I'll be happy to fix that :-)

> i'm more concerned about core functionality like gettext,

https://github.com/laurent22/simple-gettext/blob/master/README.md

> pthreads,

http://stackoverflow.com/questions/4140189/qthreads-vs-pthreads

> Glib,

It is possible to compile Qt with glib but doesn't appear to be common.

> libsoup, libxml,

Qt has native features that should be able to do much of the same
functionality, but I understand that you can mix libsoup and libxml with
Qt.

> libxslt

Happily coexists with Qt

> and can we afford the time to bounce away from those with Qt
> alternatives if necessary. Glib is a big one and if we ignore generic
> signals, lists and such, use of helper function coming out of Glib are
> _all over the place_. 

Yes - that will likely be a somewhat bigger impact. Many of the
convenience functions that we use need to be rethought. I'm trying to
interest one of my co-workers who has done Gtk->Qt migrations in the
past to want to help us here :-)

> i know that Qt provides support for the same as
> some of those libraries (and even it may use Glib internally on *nix),
> but the question is do we have to switch away from some of these
> libraries eventually? gettext is obviously a big concern as well.

See above - gettext appears to work.

> coding style, naming schemes and readability of C++ is the second one,

I think some of us have very strong feelings on that. We will not go
down the C++ obfuscation rat-hole, that's for sure.

> as Qt syntax and C++ can hardly amuse K&R programmers, i think. so the
> question here would be, can we apply the Linux kernel coding style and
> go with the idea that we are going to write Qt code the way we want
> C++ to look like - e.g. as close to C as possible. if someone starts
> porting right now and the coding style isn't correct, the entire
> source has to be again revisited with CS patches.

Yes, that's a rather important point. We REALLY want to keep the current
coding style intact.

> i'm indeed suggesting some politics, investigations and core tests
> instead of GUI POCs at first. but please go ahead, since this can be
> very interesting to everyone. overall GUI is not a big concern i would
> think, as Qt probably does everything that we want without much
> hacking, being a better GUI library by reputation. it's just a lot of
> work to port everything...

Yes it sure is.

/D