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

List:       kde-core-devel
Subject:    Re: Qt5 -> KDE5?
From:       "Aaron J. Seigo" <aseigo () kde ! org>
Date:       2011-05-10 7:54:01
Message-ID: 1334208.K4KqvsDE96 () freedom
[Download RAW message or body]


On Monday, May 9, 2011 18:41:34 Andreas Hartmetz wrote:
> >  - Do we want to focus on QML, or stay with QWidget?
> 
> I think this one is both obvious and difficult: Everything else being equal
> QML because it is, for all we know now, more "future compatible".

which shouldn't be confused with "QWidget is now dead".

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

> - Which QWidget-based code is considered important? I'm thinking of
>   KXmlGuiWindow and such things here.

imho there are two sets of classes here:

* the ones that use QWidget that shouldn't (KConfigSkeleton is one; Will 
Stephenson is working on a QML friendly option for that one already)

* that ones that are using QWidget (or IsA QWidget, even) and which are just 
fine that way

the former need to be split more cleanly between business logic and 
presentation, the latter probably simply need to be agregated into a QWidget 
library (or libraries) for use by applications using QWidget (aka all of them 
right now :)

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.

> - Will QML do what we need? Layouts, custom painting and event handling, one
> language for everything (we probably won't get that one).

this is a big part of the exploration we're doing in Plasma, and one of the 
goals of Plasma Active is to bring other projects doing similar things 
together so we can do so together. it's a great, if open, question. one that 
we're collecting pieces of the answers to as we go.

event handling is mostly there, though there have been some recent additions 
that i'm a little sceptical of (event filter type things) and that shows there 
is definitely room for improvement needed (i hope they end up using an event 
listener model as seen on the web and in Plasma's JavaScript bindings)

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.

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

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

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

the question of when we can release will be driven by what we feel we ought to 
achieve in the KDE Platform (libs + runtime) and how long that will take us. 
we don't need a lot of redesign and new technology development, but there are 
a lot of opportunities for improving how the KDE Platform presents both on the 
desktop (in terms of re-usable Qt based libraries as well as enabling QML and 
similar new technologies) and on devices.

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

* we have the resources to do it (developers, designers, etc)

* where it will not result in a degradation of the user experience by gutting 
the software of its features

as Olivier noted, QWidget will remain (far too much code out there relying on 
it and QML is far too young/immature to seriously think of it as a 100% 
capable replacement at this point), and we can and should take advantage of 
that.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks

["signature.asc" (application/pgp-signature)]

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