[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Qt5 -> KDE5?
From:       Thiago Macieira <thiago () kde ! org>
Date:       2011-05-10 8:34:32
Message-ID: 1951543.ZsEv9IIg1g () lothlorien
[Download RAW message or body]


On Tuesday, 10 de May de 2011 09:54:01 Aaron J. Seigo wrote:
> > There are many open questions:
> > - Can we migrate QWidget-based code in some way?
> 
> personally, i don't think this should be a focus for a "KDE 5". QWidget will
> remain in Qt, just in maintenance mode. they work and are very reliable. it
> can be a HELL of a lot of work to just up and convert an application from
> QWidget to QML, probably much more than we realistically have across all of
> KDE. some apps are already making the transition, which is good. QML and
> QWidget apps can live side by side just fine.

Full ack and let me add: help find where QWidget and Qt Quick aren't working 
well side by side. Those cases will need to be fixed.

> we need to do this work in libkdeui as well as libkio. we have small libs
> like knewstuff and bigger ones like kparts, and we need to comb over each
> one.

KIO needs some love, but I don't think we should take the BC opportunity to 
open the floodgates again.

> > - Will QML do what we need? Layouts, custom painting and event handling,
> > one language for everything (we probably won't get that one).
[snip]
> custom painting still falls back at times to C++ and QPainter, which isn't
> necessarily a bad thing. being able to use OpenGL directly will give us a
> new set of tools there, however.

Custom painting *should* be done in retained mode, by adding items into the 
graph of the Scene Graph. If you can't do it, then SG provides a surface for 
you to paint on, imperatively.

> layouts are pretty decent, though i think the "configuration dialog" use
> case hsan't been on the QML radar quite enough yet.

I'm very interested in knowing if Qt Quick scales to widely-varying 
resolutions, windows that change sizes; also what about translations changing 
sizes.

Nokia behaviour (which I hate) is to compress the string to fit the available 
space.

> > - Can QML look and act "native" on the desktop? I don't care if it looks
> 
> yes; we're already working on a set of KDE QtComponents. this will be
> presented at Platform 11 in Randa.

There are two things here:

1) integrating with an external widget style, be it a third-party technology 
(Windows, Mac, GTK) or a QStyle widget like Oxygen. This is currently quite 
hackish but shows promise. See the blog on "Qt Components for Desktop".

2) writing a native Qt Components style that matches the native style. That's 
a lot better and I'm sure KDE will take advantage. The performance of KDE will 
be much better than other integrations if we do this.

> > - Can we realistically pull off a minimal migration in time for the
> > planned
> >    release date?
> 
> i think it is possible, but we don't need to roll out KDE Platform 5 when Qt
> 5 is released, either. in fact, it might be wise to lag by a release to
> allow Qt 5 to settle in a bit and so we aren't chasing Qt's tail during the
> Qt5 development cycle.

Suggestion: target release in Jan 2013, which is also 5 years after the 
release of 4.0.

Provided Qt 5.0 does release mid-2012.

> > - What will the users think? -> We should not lose too many user-visible
> >   features.
> 
> this can easily become a guiding principle: we can transition to QML where
> it makes sense, in terms of:

I think this should be an "under the hood" transition, like 2.2 to 3.0 was. 
The big changes in KDE 3 only came later, with Keramik becoming the default 
widget style, the introduction of Crystal icons, then transitioning to Plastik 
style.

Hopefully, that should allow us to be both quick in pulling this off and not 
alienating almost anybody.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Development Frameworks
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]