Qt5 -> KDE5?

[Aaron J. Seigo]

On Monday, May 9, 2011 18:03:18 Olivier Goffart wrote:
> With Qt5 around the corner[1], I think it is time to start thinking about
> KDE5

thanks for kicking this off. :)

>  - Do we want "KDE 5" to be a big change, or just a small increment?

scoping within our resources is certainly part of it, and in that sense "big" 
versus "limited" comes into it. but it's not particularly helpful in figuring 
out what we want KDE Platform 5, Plasma 2, etc. to become.

perhaps a more illuminating question would be:

   What kind of change do we want to achieve?

to me, the QML vs QWidget discussion is almost uninteresting. we have people 
working on QML issues, namely:

* KDE QtComponents

* identifying bits of kdelibs that need to be made QML friendly (e.g. 
KConfigSkeleton)

* libplasma2, which takes a very strongly QML-flavoured approach with QWidget 
things to be broken out into a separate library

there is a LOT of work left to do in each, and not just writing code but also 
in identifying what needs to be done. but those wheels are moving. we just 
need to keep them moving. :)

equally important, i don't think there is necessarily an imperative to move 
all of our apps to a QML presentation in the near term. we do have some that 
are exploring that route already (Marble, Calligra, Kontact, ..) but i don't 
think it makes any sense to make that a goal for a "KDE 5".

which takes me to what i personally think is more interesting for a KDE 
Platform 5 release in which we get to rethink our ABI:

our libs+runtime are not arranged well to be the lego-blocks we need to easily 
create software stacks for today's devices. we need to go beyond just 
desktops/laptops and be able to deliver a stack for mobile, tablet, set top 
boxes. we have all the pieces, they are just not quite in the right 
arrangement to enable that.

we need to think about modularization, data/visualization separations, 
platform support vs. development framework API, runtime flexibility (so 
applications don't blindly assume things they shouldn't be, but are allowed to 
today, about what is provided as part of the runtime). 

we also have some blighted API that remains that needs cleaning up, but we 
also need to exercise restraint. since we don't need to make huge changes to 
many parts of Platform, we should try and show caution in changing things 
"just because we can". we should justify to ourselves why, for instance, we're 
changing KPagedDialog (to pick something random out of the air; i don't 
actually have designed on that one :)

QML vs QWidget is an influencing topic, but hardly central to that set of 
discussions imho.
 
>  - Shall we try drive Qt5 based on KDE5's need?

100% yes, yes and yes again.

we must get involved otherwise things will get missed in Qt. our needs and the 
needs of others who work on Qt are not fully alligned anymore. this is not a 
bad thing, it just means we need to ensure that we know what everyone's needs 
are so we don't screw each other over as we move forward toward our own goals.

furthermore, we have experience and knowledge that some working on Qt, 
particularly today (lots of new people there :), simply lack .. and vice 
versa. we need to build a dialog so our knowledge transfers cleanly over the 
fence, and they can do the same with us.
 
we also need to take advantage of the new Qt openness and get more of our code 
into Qt so we don't have to drag as many libraries around with us just because 
it isn't in Qt. the changes to the Qt undo framework recently is an excellent 
example of this, and there is tons of low hanging fruit here. John Layt named 
a couple in his email: locale, calendars, printing.

>  - Do we have more visions for what KDE5 should or should not be?

i think many of us do, and many of us don't. it's a great moment to sit back 
and reflect, and i hope that everyone who comes to Platform 11 and then to 
Berlin for the desktop summit brings those ideas with them.

> I guess there is as many opinions as people involved :-)

heh.. i'm more optimistic about that. i think there's probably a lot less than 
that

> Many things to think about, and that can be discussed further, and decided
> in Platform11 [3] (I will be there)

yes, and i'm very glad you'll be there to help represent Qt :) see you in 
Randa!

-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20110510/88f917e7/attachment.sig>