[Interest] QtArg

[Nikos Chantziaras]

On 11/04/12 18:02, Thiago Macieira wrote:
> On quarta-feira, 11 de abril de 2012 17.46.55, Nikos Chantziaras wrote:
>>> [...]
>> Lots of people seem to think that porting from Qt 4 to 5 would require
>> the same amount of refactoring work as the change from Qt 3 to 4.  All I
>> can say is "don't panic!"  That is not true.  The only "downside" with
>> Qt 5 is that we can't switch to it, but rather will need to support it
>> in parallel with Qt 4.
>
> Why is that? Is this below the reason?

Yep.  The bleeding-edge distros will probably offer both version very 
soon after Qt 5 is released (or even while it's still in beta), and 
deprecate Qt 4 sooner rather than later, while the "stable" and 
enterprise distros with very slow release cycles will stick with Qt 4 
for a longer time.

This is of course only an issue if you want to offer good Linux support. 
  People who don't care about solid Linux support and are happy with "it 
runs so shut up" might just switch to Qt 5 and bundle it with their 
applications.


>> [...]
>> I don't think we will see this with Qt 5.  Supporting both 4 and 5 with
>> a few #ifdefs seems quite feasible.
>
> If you have started to look into this, let us know quickly which modifications
> you have to make. Some of the transition needs might be unintentional and we
> still have time to fix them.

Mostly differences with identifiers, changes in enums and the like and 
the trivial #include changes.  I haven't ported one of my apps yet that 
makes heavy use of QPainter and QPixmap and implements custom widgets. 
Have yet to start on that.


>> Anyway, I'm ranting too much since Qt 5 has not really deprecated C++.
>> I just don't like the fact that I might need to put a "yet?" in the
>> previous sentence.
>
> We just believe that the future of complex, animated and fancy UIs will be
> better served by having a simple language which bother engineers and designers
> can use. That's QML. The fact that you can do a lot of logic in JavaScript is
> a bonus, not a requirement.

Heh, tell that to people who grew up here:

   http://www.pouet.net

and you'll get slapped for saying that ;-)


> And notwithstanding the language choice, we are completely convinced that the
> current QPainter drawing model is obsolete. It was correct in the 1990s and
> early 2000s, but it's no longer how graphics hardware works.

I tend to agree on that one.  But I still think this can be considered 
systems programming and therefore the domain of C-based languages and 
that JS should sit on top of that instead of being at the core.