Move to Qt?

[Amit Chaudhuri]

Dirk & Lubomir - your replies raise points I hadn't thought of and spark
some other random thoughts.

If Gettext is used for the translations, Qt also has an infrastructure for
handing the same (Qt Linguistic).  I don't know how they compare from a
translators PoV, but note the existence and acknowledge Dirk's link.

Subsurface use of pthreads  is pretty limited, unless I'm missing
something.  Grep pulled out only one or two lines last time I looked. Did I
miss a whole bunch of thread usage somewhere?

Someone in that second link makes a very good point about the dependency on
Qt itself and the impact on distributing the application.

If I set my own bias aside, it looks to me as though things are fairly
finely balanced in terms of resource and experience on the wider team.
 I'll watch Dirk's follow ups with interest.

A



On Fri, Mar 29, 2013 at 4:26 PM, Dirk Hohndel <dirk at hohndel.org> wrote:

> "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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20130329/a6e0c32f/attachment.html>