Move to Qt?

Lubomir I. Ivanov neolit123 at gmail.com
Fri Mar 29 06:56:01 PDT 2013


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.

>
> 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?
>
> General thoughts...?
>

i'm more concerned about core functionality like gettext, pthreads,
Glib, libsoup, libxml, libxslt 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_. 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.

coding style, naming schemes and readability of C++ is the second one,
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.

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...

lubomir
--


More information about the subsurface mailing list