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

Lubomir I. Ivanov neolit123 at gmail.com
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 hohndel.org> 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:
>> http://i49.tinypic.com/rsztjn.jpg
>
> 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
>> http://ubuntu.allmyapps.com/data/q/t/qt4-designer-qt-4-designer/UBUNTU-9.04/widget_editor_qt_designer.png
>> - 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. still...it 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:
http://en.wikipedia.org/wiki/Brainfuck

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.

lubomir
--


More information about the subsurface mailing list