[Interest] QtArg

[Thiago Macieira]

On quarta-feira, 11 de abril de 2012 10.34.58, Rui Maciel wrote:
> On 04/10/2012 07:46 PM, Thiago Macieira wrote:
> > 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 thought I had explained why: because there's a lot of functionality in those 
libs that are useful to you, an application writer.

> >> 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.

That's neither here nor there. My argument was a reply to Nikos's statement 
that it would take years to get a KDE based on Qt 5, which he used as an 
argument to support writing more features for Qt 4. I was simply proving his 
argument wrong.

Whether people are going to take time to port to Qt 5, that's another story. 
Maybe they will wait until the next major revision to their software, maybe 
they'll find it easy, which is our intention, and port quickly. But that was 
not Nikos's argument.

> Moreover, it appears that Qt5 represents a radical change with the way
> Qt is expected to be used.

No, it does not. Please try it before you emit that opinion. You're really 
talking nonsense.

> 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.

Complete nonsense.

If you read the Qt 5 mission statement blog by Lars, which is almost one year 
old now, you'll see it's wrong. And even on top of that, we've made some 
changes along the way that make it even easier.

> 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.

I'd like to see your sampling. No, really, because I have no clue on the state 
of C-based projects, outside my little world of kernel, libc and glib.

MSVC does not support C99, but GCC does and I know a lot of projects that use 
that. GCC's default mode is C89 + some C99 features and GCC extensions. 
Whether that makes most code C89 or C99, I have no clue.

> 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.

I understand that. Yes, I expect Qt 4 to be used for a long time too, but I 
really, really hope that there is no push to come to shove. I really expect 
that transitioning from Qt 4.8 to Qt 5.x be a matter of a few, easy search-
and-replaces and then a recompile. So I expect that the transition be 
undertaken by most projects at the first opportunity, like when you'd upgrade 
across minor versions of Qt.

That's the intention because we know that we have a huge risk of people 
jumping ship to something else. The bigger the pain of transition, the larger 
the chance of losing users along the way.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
     Intel Sweden AB - Registration Number: 556189-6027
     Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20120411/1581faff/attachment.sig>