Plans [was: Re: Gconf or GSettings? - leading to a wider question]

Lubomir I. Ivanov neolit123 at
Wed Jan 23 15:13:35 PST 2013

i carry the guild for not replying to this thread earlier...

On 20 January 2013 18:21, Dirk Hohndel <dirk at> wrote:
> On Jan 20, 2013, at 7:21 AM, Lubomir I. Ivanov wrote:
>> just gave Qt a try out session for the first time, and i can say i'm a
>> bit impressed.
>> after 5 hours reading docs and forums here is a mockup where i only
>> had to write 200lines of code or so:
> I hope the rendering quality of the oval is not indicative of the quality of anti-aliasing available :-)

this code example has not AA and in general - its all platform specific.
Windows has pretty decent AA features, but really, if someone
complains there are always options to write a local oversampling
algorithm e.g. x16.

>> - it is using a UI designer (/resource editor) which generates code
>> - the executable is 110kb (stripped) with no dependencies on windows!
>> - simple XML parsing is builtin
>> - has divelist tree view mockup
>> - has a drawable frame
>> - tabs, menus with signals
>> things about Qt i didn't like after reading comments and trying things out:
>> - API broken between 4.x, 5.x. also no 5.x mingw build for windows yet.
> 5.x is very new - I'll ask Thiago what the plans are for the Windows side. Native Windows support is of course available (it's actually the primary platform on the commercial side, I hear).

indeed, mingw support for win32 is coming early feb. i've heard.
MSVC support is already there.

>> - everything is UTF-16
> YUCK. You are kidding. That's a total no go if that is true.

internal QString storage is all about UTF-16, and they have no plans
to change it.
this opens a huge UTF-x - vs UTF-y argument, but i can honestly say
the their decision is a bit OS compromising.
Win32 uses UTF-8 and the same applies to OSx (AFAIK).
OS specific calls benefit to that, but there is the RAM and CPU usage
consideration for others.

i will leave debates to Unicode specialists...
i can say the i understand Unicode for my needs and that perhaps UTF-8
is the better choice performance and storage wise, given there are
no-endian dependencies and that Latin characters can be stored
completely in 1 byte blocks if possible.

>> - the project make files (qmake) can be a bit of a trouble in the long
>> run, i think
> Can't be worse than our hacked Makefile
>> - classes have to be subclassed for basic functionality like signals
>> and painting events
>> (alternatives seem hacky)
>> - heavy use C++ syntax, although stream syntax for example is not
>> strictly needed.
>> "something << 123456" usually has an alternative "something.add(123456)";
> That is my biggest concern. How much of the OO / C++ crap would this drag into the project. Much as I hate some of the decisions in Gtk and many of the bugs we ran into - at least it's done in a sane programming language and I know I can debug things and make them work. I actually looked at a few larger open source Qt applications and they make your eyes bleed. Granted, that may be the style preference of those developers, but overall it has me worried.

i've seen so much crap in the most popular ones... :\
C++ is the land of bad low-to-high level programming practices.
people writing said applications, simply do not understand
architecture specific CPU instructions.
when i write for ARM _i know_ how the code may end up looking like.

Qt still provides the means to write clean code, yet things like
static addressing "::" are not avoidable.
subclassing is also there of course and not avoidable. can
look quite clean.

yesterday however, i've watched a lecture by your colleague Thiago and
_that_ got me a bit concerned.
they are in fact embracing C++11 with all its crap syntax like
"lambdas" (or  anonymous function)
they are looking at deprecating C++98, so that they can support syntax like:
[=](float x) {return crap;} for Qt signals.

the [=] part is full of hilarious jokes. c++ may end up looking like
"brainfuck" at some point:

overall Qt seems quite impressive, but only if one uses the new QtQuick and QML.
the C++ part looks a bit difficult of follow, unless one can be a C++ masohist.
i certainly can. :\

> And, of course, Linus is right. At this point we have a TON of Gtk code that would all have to be rewritten. I'm still not convinced whether this can possibly be worth it.
> Just for the record - before we spend too much time on this I want to get Subsurface 3.0 out.
> On my list of things for this to happen are

Qt is tempting, but i agree that subsurface should reside in Gtk for now.
perhaps we can make clean enough proposals to switch eventually...
the UI parts apparently won't be that much of trouble.


More information about the subsurface mailing list