thiago.macieira at intel.com
Tue Apr 10 20:46:47 CEST 2012
On terça-feira, 10 de abril de 2012 21.15.29, Nikos Chantziaras wrote:
> On 10/04/12 17:32, Thiago Macieira wrote:
> > On terça-feira, 10 de abril de 2012 17.17.09, Nikos Chantziaras wrote:
> >> I'd recommend to support Igor Mironchik instead, since it's for Qt 4,
> >> which we will be using for a long time (Qt 5 doesn't work in KDE.)
> > KDE already has KCmdLineArgs, so KDE doesn't need a Qt 4 solution. It
> > needs a Qt 5 solution.
> I don't understand. With that logic, Qt 5 doesn't need a solution
> either because KDE will support Qt 5 in the future, and you'll have
> KCmdLineArgs too then.
Except you're missing the fact that KDE wants to drop some of its old
compatibility classes and move them upstream to Qt 5. Laszlo's work is exactly
that: upstreaming of KCmdLineArgs functionality.
The same thing happened to KStandardDirs (QStandardPaths) and the KDE MIME
type classes (QMimeDatabase). Both are already in 5.0.
> 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.
So be glad that lots of KDE functionality is being upstreamed, so you'll be
able to use in your Qt app without linking to the KDE libs.
> 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.
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.
3) this particular effort is being developed *inside* QtCore. So it's very hard
to make it work outside it, especially with Qt 4. But if someone wants to do
that, go ahead.
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: not available
Size: 190 bytes
Desc: This is a digitally signed message part.
Url : http://lists.qt-project.org/pipermail/interest/attachments/20120410/9bb0f717/attachment.bin
More information about the Interest