[Interest] QtArg

Rui Maciel rui.maciel at gmail.com
Wed Apr 11 11:34:58 CEST 2012


On 04/10/2012 07:46 PM, Thiago Macieira wrote:
> On terça-feira, 10 de abril de 2012 21.15.29, Nikos Chantziaras wrote:

>> Furthermore, Qt application can't use KDE libraries, because then they
>> would be KDE applications, not Qt applications.  Qt 4 application run
>> very nice in KDE.  Qt 5 applications do not (they look very alien).
>
> Which is a pity. There's a lot of functionality in the KDE libs that you
> should use. You should consider transforming your Qt-only app into a KDE one.

Why?


>> I prefer a Qt 4 solution, because it will take years for all Linux
>> distros to come with a KDE that supports Qt 5.  Targeting only Qt 5 is a
>> mistake.  The solution needs to either be developed for Qt 4 and then
>> ported to 5, or for 5 and at the same time backported to 4.
>
> You're again missing the point here (several, actually).
>
> 1) a KDE based on Qt 5 should be out by, hopefully, mid-next year. So I'd say
> 18 months is a reasonable timeframe for distros to have it.

I don't expect every project that was based on Qt to be rewritten with a 
rebase on Qt 5 in mind, let alone in a 18 month time frame.  This is 
simply unreasonable.

Moreover, it appears that Qt5 represents a radical change with the way 
Qt is expected to be used.  Some people, particularly veterans who are 
already familiar with Qt, may not be very keen in being forced to 
rewrite the majority of their code in an entirely different programming 
language.  After all, UI toolkits are there to serve the developer, not 
the other way around.

And lastly, the programming world is packed with technologies which 
simply don't "stick", no matter how good the intentions are.  A 
particular case which jumps to mind is the C programming language; after 
two decades and a couple of international standards, C89 is still the 
main version being targeted by developers.


> 2) I'm not saying that a solution for Qt 4 shouldn't be found. I'm saying that
> looking into the Qt 5 solution *now* is more important because it's what you
> *will* have from 5.1 on. Don't develop competing efforts now, just improve this
> one to make sure everyone is happy at the end of 2012 when it is released.

Honestly, I expect Qt4 to be kept in use for a long time.  And if push 
comes to shove, I suspect that some Qt4 users will be more keen to 
invest in a Qt4 fork or even ditching Qt in favour of some other toolkit 
instead of jumping on the Qt5 bandwagon.


Rui Maciel



More information about the Interest mailing list