--nextPart1482171.ikCiMLf1ID Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 --nextPart1482171.ikCiMLf1ID Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEABECAAYFAk3I9roACgkQ1rcusafx20OYAwCfSugVdC1FjYTiotw6I9TAV7o5 FfMAn0hevyq2hwFKvMKaPJZMUgprrQ+T =LuVv -----END PGP SIGNATURE----- --nextPart1482171.ikCiMLf1ID--