Re: Qt5 - KDE5?
On Tuesday, May 10, 2011 17:18:58 Alex Merry wrote: On 10/05/11 09:26, Aaron J. Seigo wrote: 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 :) On this front, I think it would be a good idea to try to introduce the new api and deprecate the old in a 4.x release where possible, before clearing out the deprecated stuff in Platform 5. This would allow a smoother transition, especially for apps that aren't included in SC. this is what we are planning on doing with libplasma, for instance. only a slightly more drastic level. i expect libplasma2 to debut on top of Qt4 and i think we will end up shipping, or at least making available, both libplasma1 and libplasma2, between then and KDE Platform 5. -- 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 Description: This is a digitally signed message part.
iceScrum (was Re: Qt5 - KDE5?)
On Tuesday 10 May 2011 10.04.34 Aaron J. Seigo wrote: we have already been putting together plans, including documenting them feature by feature in iceScrum For those of us who this is the first time we hear about icsscrum where is it, who can use it and for what? /Regards Torgny
Re: iceScrum (was Re: Qt5 - KDE5?)
On Thu, May 12, 2011 at 8:38 AM, Torgny Nyblom nyb...@kde.org wrote: On Tuesday 10 May 2011 10.04.34 Aaron J. Seigo wrote: we have already been putting together plans, including documenting them feature by feature in iceScrum For those of us who this is the first time we hear about icsscrum where is it, who can use it and for what? http://contour-scrum.basyskom.org/icescrum/ -- Shaun Reich, KDE Software Developer (kde.org)
Re: iceScrum (was Re: Qt5 - KDE5?)
On Thursday, May 12, 2011 14:38:57 Torgny Nyblom wrote: On Tuesday 10 May 2011 10.04.34 Aaron J. Seigo wrote: we have already been putting together plans, including documenting them feature by feature in iceScrum For those of us who this is the first time we hear about icsscrum where is it, who can use it and for what? Shaun gave the location; it's still experimental for us, though. We're using it for the next three months of plasma development, with a focus on Plasma Active issues, as a trial. If this works out well, we will find a more permanent home somewhere under the KDE infrastructure umbrella and open the invitation to use it to more people. If there is interest sooner, then perhaps someone can look into speeding up that timeline. -- 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 Description: This is a digitally signed message part.
Re: iceScrum (was Re: Qt5 - KDE5?)
On Thursday, May 12, 2011 14:38:57 Torgny Nyblom wrote: On Tuesday 10 May 2011 10.04.34 Aaron J. Seigo wrote: [...] Shaun gave the location; it's still experimental for us, though. We're using it for the next three months of plasma development, with a focus on Plasma Active issues, as a trial. If this works out well, we will find a more permanent home somewhere under the KDE infrastructure umbrella and open the invitation to use it to more people. If there is interest sooner, then perhaps someone can look into speeding up that timeline. Thanks (Aaron and Shaun) for that, I think that it look interesting and am looking forward to hear what your impressions are after this first sprint. If you think that it is good I would love to have an official KDE version running for us all to use. /Regards Torgny
Re: Qt5 - KDE5?
On Monday 09 May 2011 May, Olivier Goffart wrote: - Do we want KDE 5 to be a big change, or just a small increment? Given that an app like krita has only just now reached enough maturity to reach an audience, any hint of big changes to the KDE platform make me really afraid. We (the krita guys) need at least another five or ten years without churn! (And for us QML is churn, QGraphicsWidget is churn -- there's nothing that we need to do which cannot be done with a QWidget or directly in OpenGL.) -- Boudewijn Rempt | http://www.valdyas.org, http://www.krita.org
Re: Qt5 - KDE5?
On Wednesday, 11 de May de 2011 08:03:25 Boudewijn Rempt wrote: On Monday 09 May 2011 May, Olivier Goffart wrote: - Do we want KDE 5 to be a big change, or just a small increment? Given that an app like krita has only just now reached enough maturity to reach an audience, any hint of big changes to the KDE platform make me really afraid. We (the krita guys) need at least another five or ten years without churn! (And for us QML is churn, QGraphicsWidget is churn -- there's nothing that we need to do which cannot be done with a QWidget or directly in OpenGL.) GL it is then :-) -- 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 Description: This is a digitally signed message part.
Re: Qt5 - KDE5?
On Tuesday 10 May 2011, Alex Merry wrote: On 10/05/11 09:26, Aaron J. Seigo wrote: 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 :) On this front, I think it would be a good idea to try to introduce the new api and deprecate the old in a 4.x release where possible, before clearing out the deprecated stuff in Platform 5. This would allow a smoother transition, especially for apps that aren't included in SC. may i also add, to make the transition smoother make sure as much apps as possible builds correctly against the mobile profile, that already excludes most of deprecated api, so the day deprecated app will go away from the code it will be less painful ;) (several main kde modules are already covered, some of them still have some issues) -- Marco Martin
Re: Qt5 - KDE5?
On Wednesday 11 May 2011, Thiago Macieira wrote: On Wednesday, 11 de May de 2011 08:03:25 Boudewijn Rempt wrote: On Monday 09 May 2011 May, Olivier Goffart wrote: - Do we want KDE 5 to be a big change, or just a small increment? Given that an app like krita has only just now reached enough maturity to reach an audience, any hint of big changes to the KDE platform make me really afraid. We (the krita guys) need at least another five or ten years without churn! (And for us QML is churn, QGraphicsWidget is churn -- there's nothing that we need to do which cannot be done with a QWidget or directly in OpenGL.) GL it is then :-) but i gather that won't be possible to mix arbitrary opengl scenes with scenegraph items? or will it be? -- Marco Martin
Re: Qt5 - KDE5?
On Tuesday, May 10, 2011 00:35:17 Markus Slopianka wrote: Qt 5 results in no need to think about KDE5 because there will be no such thing as KDE4. The only thing Qt 5 does is to enforce KDE Platform 5 because of the broken binary compatibility. KDE Plasma Workspaces can stay at 4.x and build on Platform 5 unless KPW magically becomes something totally different that justifies a major version jump. Change of the back-end alone does IMO not justify a big version jump for KPW just as Phonon did not jump to 5.0 just because xine was deprecated in favor of VLC and GStreamer. Nothing from KPW guaranties binary compatibility which IMO means that the user workflow has to change dramatically for a big version jump. If classic QWidgets stay, I also don't see why KDE Applications need to jump from 4.x to 5.0. Most will just be recompiled to use the new Platform 5 without any huge GUI facelifts. This reflects exactly my opinion. The only thing required is the Plaform version increase. Then we could/should add KDE-QML-Components to make it possible to start new applications using QML in a KDE-like fashion. On the other hand, I don't really care if we have the version number 4, 5 or 2012.42. The important thing here is to make the transition to Qt5 smooth for both, developers and users.
Re: Qt5 - KDE5?
On 05/09/11 19:53, John Layt wrote: I'll leave the graphics stack to those who know better, but I suspect the leap to QML will be too disruptive and dely things too much. Perhaps continue calling the QWidget KDE v4 and save the v5 for QML after another 6-12 months? No one is forcing us to move everything from QWidgets to QML. I think that the transition to QML will be slow and smooth: we should continue to use QWidgets on existing applications/UIs while new applications should use QML. Anyway we have a chance to break binary compatibility so we have to increase our version number. Personally I see some needed tasks for kdelibs: * Splitting logic and UI (ex: removing QWidgets dependencies from kio) * Splitting kdeui in 3 different libraries: kdecoreui (will contain KIcon, etc...), kdewidgetsui (QWidget based code) and kdeclarativeui (new QML based code). * libplasma2 * Moving away KHTML from kdelibs I think we should create some pages on the wiki as we already did for libplasma2. Bye, Davide Bettio. signature.asc Description: OpenPGP digital signature
Re: Qt5 - KDE5?
Hi, During the last tokamak I've created this wiki page for issues and required features that we want to see fixed in QML2: http://community.kde.org/QML_issues Please, fill this page with issues and required features, an improved QML is a required feature for Qt/KDE 5 :) Bye, Davide Bettio. signature.asc Description: OpenPGP digital signature
Re: Qt5 - KDE5?
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 Description: This is a digitally signed message part.
Re: Qt5 - KDE5?
On Monday, May 9, 2011 20:17:37 Alberto Mattea wrote: 3) Core apps, or shall we change again everything?. It took at least 3 minor releases (or 2 years since KDE 4.0) to have a fully crash-free experience with the plasma shell. Now it looks fantastic, it is modular (desktop, netbook, media centre) and light (it is usable on an 800 Mhz pentium III). I would hope for a stable 5.0 release, also in connection with point 1). So I'd say don't start again from scratch: the current base is solid, extendable, users recognize it. Changement is not necessarily for good. because people seem to love hearing me repeat it, let me say it again: when starting plasma, i kept saying that in starting from scratch on those pieces i wanted to make something that enabled us to not have to do such a thing again. i think we (the greatly dedicated Plasma team) have achieved that as much as is reasonably possible. and so we have zero intention of starting from scratch. none. zilch. nadda. not a bit. it's a dead parrot. forget about it. i've blogged about our plans for libplasma2 and how we want to handle the switch from QGraphicsScene to QML without rewriting, e.g., plasma-desktop. that means it will continue to have QWidget legacy for the forseeable future as we focus on new development that needs attention, which will be done in QML. we have already been putting together plans, including documenting them feature by feature in iceScrum, so everyone can see them. these range from a whole host of libplasma to changes to things like move the screen locker into the window manager where it belongs. libplasma2 will be binary incompatible with libplasma1, will focus on QML and we will have a second library for Plasma apps that continue to use the QWidget centric bits. we are not starting from scratch. oh, and have i mentioned, we're not starting from scratch? ;) -- 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 Description: This is a digitally signed message part.
Re: Qt5 - KDE5?
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 signature.asc Description: This is a digitally signed message part.
Re: Qt5 - KDE5?
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 Description: This is a digitally signed message part.
Re: Qt5 - KDE5?
On Tuesday, May 10, 2011 10:34:32 Thiago Macieira wrote: KIO needs some love, but I don't think we should take the BC opportunity to open the floodgates again. agreed, but i do think there is an opportunity here to try and separate the platform integration bits out of KIO. otherwise KIO almost becomes a non- starter for anything that isn't a desktop. we don't necessarily need to rework the API very much, just modularize the library so it is more reusable. my concern is that if we don't do this, we'll end up with a lot of applications marooned on the desktop or off the desktop due to have KIO (or not) or a lot of applications with multiple code paths for this functionality. (libplasma already has one such code path!) it might be tempting to say, let's just find something else for non-desktop stuff but we have so much code using KIO and it is a rather good API and library otherwise that it would be a damn shame to go that route. -- 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 Description: This is a digitally signed message part.
Re: Qt5 - KDE5?
On 10/05/11 09:26, Aaron J. Seigo wrote: 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 :) On this front, I think it would be a good idea to try to introduce the new api and deprecate the old in a 4.x release where possible, before clearing out the deprecated stuff in Platform 5. This would allow a smoother transition, especially for apps that aren't included in SC. 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. If Qt is moving away from QWidgets to QML, this could potentially be an opportunity to push some of our kdeui stuff up into the QWidgets library, especially if someone associated with KDE is willing to take on maintainership of that. Admittedly, this is a big ask, but if we have someone willing to take that on, it's something we should probably consider. Alex
Re: Qt5 - KDE5?
- It should be mostly source compatible with Qt4, and is just an opportunity to break binary compatibility. Well, even if we do nothing, we are breaking ABI. So, from my point of view, this is a perfect time to do some API cleanup (all those deprecated methods, faking virtuals with slots etc.) - QWidget just stay for compatibility. All focus is put on QML. Do not expect new development on QWidgets from Nokia. Which doesn't mean there will be no development at all. I guess others (and us) will continue developing those classes since (1) they are way more mature than qml (2) a lot of code is written above them. - Do we want KDE 5 to be a big change, or just a small increment? Do we need a big change? I don't think so - we are already fantastic :) -- Cheerio, Ivan -- While you were hanging yourself on someone else's words Dying to believe in what you heard I was staring straight into the shining sun
Re: Qt5 - KDE5?
I am probably being a bit selfish here, but I don't see how we can ever build on a toolkit that requires OpenGL ES2.0 level hardware. That would leave many machines that currently run KDE4 solidly (e.g. my laptop) unable to run KDE5 for no good reason. I doubt it's the only one out there with a laptop with decent CPU and memory specs and lousy graphics card. On 5/9/11, Ivan Čukić ivan.cu...@kde.org wrote: - It should be mostly source compatible with Qt4, and is just an opportunity to break binary compatibility. Well, even if we do nothing, we are breaking ABI. So, from my point of view, this is a perfect time to do some API cleanup (all those deprecated methods, faking virtuals with slots etc.) - QWidget just stay for compatibility. All focus is put on QML. Do not expect new development on QWidgets from Nokia. Which doesn't mean there will be no development at all. I guess others (and us) will continue developing those classes since (1) they are way more mature than qml (2) a lot of code is written above them. - Do we want KDE 5 to be a big change, or just a small increment? Do we need a big change? I don't think so - we are already fantastic :) -- Cheerio, Ivan -- While you were hanging yourself on someone else's words Dying to believe in what you heard I was staring straight into the shining sun
Re: Qt5 - KDE5?
On Monday 09 May 2011 18:03:18 Olivier Goffart wrote: Hi, With Qt5 around the corner[1], I think it is time to start thinking about KDE5 Raw summary: - Qt5 is planed to be released in about one year from now if everything goes well. - It should be mostly source compatible with Qt4, and is just an opportunity to break binary compatibility. - QWidget just stay for compatibility. All focus is put on QML. Do not expect new development on QWidgets from Nokia. - The OpenGouvernance should finaly come into light, meaning we (as KDE), can contribute easier to Qt. I guess it make sens, as Qt breaks binary compatibility, to do the same in kdelibs. Does that mean KDE 5? or KDE SC 5? Not necessarily. We can break binary compatibility, and change the .so version of our library without changing the major version of KDE itself. But I think it would anyway still be a smart move to do it. And I think this is a perfect opportunity to get some KDE class in Qt as we planed. [2] Some item we might want to think about: - Do we want KDE 5 to be a big change, or just a small increment? - 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. There are many open questions: - Can we migrate QWidget-based code in some way? - Which QWidget-based code is considered important? I'm thinking of KXmlGuiWindow and such things here. - Will QML do what we need? Layouts, custom painting and event handling, one language for everything (we probably won't get that one). - Can QML work on older hardware? (see Maksim's message) - Can QML look and act native on the desktop? I don't care if it looks different, but it should be suitable for the given screen dimensions and input devices. - Can we realistically pull off a minimal migration in time for the planned release date? - What will the users think? - We should not lose too many user-visible features. I think it's not looking good for mostly switching to QML and releasing KDE5 shortly after Qt5. Even when QML's own issues have been fixed there will be a huge amount of work for KDE, part of which can only happen once QML is there. Maybe we should simply stay at KDE4/Qt4 for a while and release KDE5 for Qt5 when it's done, but no later than in ~2 years if possible. For developers releasing KDE5 with QT5 and later KDE6 with Qt5 and more QML seems tempting, but users won't like it. - Shall we try drive Qt5 based on KDE5's need? - Do we have more visions for what KDE5 should or should not be? I guess there is as many opinions as people involved :-) Many things to think about, and that can be discussed further, and decided in Platform11 [3] (I will be there) But in my opinion, if there is something we should learn from the KDE4 transition, it is not to be too ambitious.
Re: Re: Qt5 - KDE5?
On Monday 09 May 2011 12:27:14 Maksim Orlovich wrote: I am probably being a bit selfish here, but I don't see how we can ever build on a toolkit that requires OpenGL ES2.0 level hardware. I think it would make sense to have at least optionally the legacy code (QWidget + X11) without an OpenGL ES requirement. For QML2 and QWidget on Wayland the GLES requirement makes sense. That would leave many machines that currently run KDE4 solidly (e.g. my laptop) unable to run KDE5 for no good reason. I doubt it's the only one out there with a laptop with decent CPU and memory specs and lousy graphics card. It's not only leaving quite some hardware behind, it's also that I doubt that the free driver stack will be anywhere close to the maturity required for all applications using OpenGL. If I consider the trouble we have with just one application defaulting to OpenGL... Cheers Martin On 5/9/11, Ivan Čukić ivan.cu...@kde.org wrote: - It should be mostly source compatible with Qt4, and is just an opportunity to break binary compatibility. Well, even if we do nothing, we are breaking ABI. So, from my point of view, this is a perfect time to do some API cleanup (all those deprecated methods, faking virtuals with slots etc.) - QWidget just stay for compatibility. All focus is put on QML. Do not expect new development on QWidgets from Nokia. Which doesn't mean there will be no development at all. I guess others (and us) will continue developing those classes since (1) they are way more mature than qml (2) a lot of code is written above them. - Do we want KDE 5 to be a big change, or just a small increment? Do we need a big change? I don't think so - we are already fantastic :) -- Cheerio, Ivan -- While you were hanging yourself on someone else's words Dying to believe in what you heard I was staring straight into the shining sun signature.asc Description: This is a digitally signed message part.
Re: Qt5 - KDE5?
On Monday 09 May 2011 18:03:18 Olivier Goffart wrote: Hi, With Qt5 around the corner[1], I think it is time to start thinking about KDE5 Raw summary: - Qt5 is planed to be released in about one year from now if everything goes well. - It should be mostly source compatible with Qt4, and is just an opportunity to break binary compatibility. - QWidget just stay for compatibility. All focus is put on QML. Do not expect new development on QWidgets from Nokia. - The OpenGouvernance should finaly come into light, meaning we (as KDE), can contribute easier to Qt. I guess it make sens, as Qt breaks binary compatibility, to do the same in kdelibs. Does that mean KDE 5? or KDE SC 5? Not necessarily. We can break binary compatibility, and change the .so version of our library without changing the major version of KDE itself. But I think it would anyway still be a smart move to do it. While I agree we should call it 5, I think that some users would prefer to have no .0 again. And I doubt it will matter how much we tell that it's not like the last time. And I think this is a perfect opportunity to get some KDE class in Qt as we planed. [2] Some item we might want to think about: - Do we want KDE 5 to be a big change, or just a small increment? - Do we want to focus on QML, or stay with QWidget? I think you answered that question with the lessions to be learned from KDE4 quite nicely. - Shall we try drive Qt5 based on KDE5's need? - Do we have more visions for what KDE5 should or should not be? I guess there is as many opinions as people involved :-) Many things to think about, and that can be discussed further, and decided in Platform11 [3] (I will be there) But in my opinion, if there is something we should learn from the KDE4 transition, it is not to be too ambitious. -- Olivier [1] http://labs.qt.nokia.com/2011/05/09/thoughts-about-qt-5/ [2] http://community.kde.org/KDE_Core/QtMerge [3] http://community.kde.org/KDE_Core/Platform_11 signature.asc Description: This is a digitally signed message part.
Re: Qt5 - KDE5?
Le Monday 09 May 2011, Andreas Hartmetz a écrit : - 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. There are many open questions: Thanks for the interresting questions. - Can we migrate QWidget-based code in some way? Hardly One can imagine some kinf of tool that port the .ui file to qml file, but the C++ logic need to be rewriten as well. - Which QWidget-based code is considered important? I'm thinking of KXmlGuiWindow and such things here. I think kdelibs is not the problem here. But all the existing applications out there, with all their configuration dialogs. Moving to QML is a total rewrite of the UI. We are lucky if the application have a separate UI and Logic, but this is not always the case. - Will QML do what we need? Layouts, custom painting and event handling, one language for everything (we probably won't get that one). QML is still very young. Nokia focus is obviously embedded, and KDE has slightly different needs sometimes. But that is where KDE come: We need to identify the needs, and push for them to be solved, or do it ourself. - Can QML work on older hardware? (see Maksim's message) QML has been designed to work fast with low resources. Depends how old you want to go. - Can QML look and act native on the desktop? I don't care if it looks different, but it should be suitable for the given screen dimensions and input devices. http://labs.qt.nokia.com/2011/03/10/qml-components-for-desktop/ - Can we realistically pull off a minimal migration in time for the planned release date? We do not have a planed release date. KDE 5 do not need to be release the same day of Qt 5 - What will the users think? - We should not lose too many user-visible features. Indeed, there is inside small QWidgets such as QLineEdit, 15 years of experience of behaviour. Support for many imput method, accessibility, cross platform, languages, QML starts almost from scratch. I think it's not looking good for mostly switching to QML and releasing KDE5 shortly after Qt5. Even when QML's own issues have been fixed there will be a huge amount of work for KDE, part of which can only happen once QML is there. Maybe we should simply stay at KDE4/Qt4 for a while and release KDE5 for Qt5 when it's done, but no later than in ~2 years if possible. For developers releasing KDE5 with QT5 and later KDE6 with Qt5 and more QML seems tempting, but users won't like it. We can do KDE5 with Qt5 and QWidget. QWidget will stay, but only as a second class citizen. And as open gouvernence comes, KDE can be active in maintaining QWidgets (But do we have the ressources?)
Re: Qt5 - KDE5?
On Monday 09 May 2011 17:03:18 Olivier Goffart wrote: With Qt5 around the corner[1], I think it is time to start thinking about KDE5 TBH, we'd be fools to release a KDE 5.0 based on Qt 5.0 shortly after it's release. The sensible approach is to wait for Qt 5.1 and release KDE 5.0 after that. This realistically gives us at least 18 months before a KDE 5.0 release. Our primary focus should first be getting what we want into Qt 5. Once we see what actually makes it into Qt 5 then we can make plans on what KDE 5 will look like. Between Platform 11 and the QCS and a beta release in 6 months there's a lot of decisions and a lot of code in a fairly short time. If there are topics anyone wants discussed at Platform 11 please add them to http://community.kde.org/KDE_Core/Platform_11#Topics and if needed do a detailed write-up on a linked wiki page. One thing to consider is how long the Qt5 code migration will take. The Qt4 - Qt5 code might be fairly simple, but we still have a lot of Qt3Support code left in KDE4 that will have to be gone before KDE5, and if anything happens around QLocale/QDateTime/QSettings then thats some core code to adapt everything to. I suspect we will have to skip a release cycle and take 9-12 months to do it properly, probably starting around teh Qt 5.0 release. Personally here's my Qt5/KDE5 wish/todo list: * QDateTime to gain proper timezone and calendar system support so we can drop ours, otherwise fix my mistakes in KCalendarSystem * KLocale and QLocale to merge as much as possible, otherwise split KLocale into a settings container and formatting functions to get rid of circular references. * Geolocation api * Printing nirvana I'll leave the graphics stack to those who know better, but I suspect the leap to QML will be too disruptive and dely things too much. Perhaps continue calling the QWidget KDE v4 and save the v5 for QML after another 6-12 months? With regards to printing, the CPD, and the Qt patch-set I'm sitting on waiting for OpenGov, if it is now going to take 18-24 months to get those features into our coders and users hands then that's too long. I'm seriously considering a short-term fork of QPrinter with a cleaned up api and new features we can ship with KDE 4.8. What I learn from that can then go into Qt5, or give us a fallback if Qt5 doesn't deliver. Cheers! John.
Re: Qt5 - KDE5?
On Monday 09 May 2011, Olivier Goffart wrote: Hi, With Qt5 around the corner[1], I think it is time to start thinking about KDE5 agreeing with many of the things saind in this thread a) yes should be called 5, and b) yes we should wait a bit, but is too early to see how big that bit should be reading the announcement i only hope that Qt will require OpenGL (ES) 2.0 to work. QWidgets will be layered on top of the scene graph (not the scene graph on top of QWidgets as is currently done with Qt 4). won't be technically correct for the qwidgets-on-top-scenegraph part that would just mean qgraphicsproxywidgets screw up all over again, just worse since would become the *only* way. Cheers, Marco Martin
Re: Qt5 - KDE5?
Hi there, on this occasion where future direction of KDE is being defined, here's just a note from a linux 'power user' who turned from full KDE (3.5) fanboyness to using xfce, coping with some kde apps (yakuake, konqueror, okular, the games)... - Do we want KDE 5 to be a big change, or just a small increment? Do we need a big change? I don't think so - we are already fantastic :) although you put a smiley there, _this_ attitude is what i perceive as a huge problem regarding current KDE. The continuing 'pareto UI design frenzy', i.e. designing for the fictitious 80% collective of Joe-users(*) has been a real turn off to me. But the real problem behind that is that often, even elaborate users have no choice of changing stuff they'd like to behave differently (besides locally applying hacky patches). Fortunately, QML offers a great way out: separating GUI definition from the code providing features. This could result in what i'd dream of as great solution - UI style sheets, for joes, advanced users or kids. That's a long way off though. Another thing, the handling of bug reports could be a bit more mature in some cases. Flagging users UI improvement proposals as RESOLVED/WONTFIX (**) or pretending loss of user data under special conditions is not a problem that could be dealt with (***) is not what i'd consider super responsible maintainership... but then again i stopped reporting bugs anyways out of demotivation... Not to play the blame game here, i still have hopes KDE can be the fun 'kool' power experience KDE 3.5 was, but my euphoric 4.x expectations have largely been smashed by instability, imho poor UI decisions and a plasma dream that never materialized. That said, will continue compiling QT/KDE trunk regularly and see what innovative new solutions you guys (hopefully) come up with! (: #regards/marcel. (*) why at all is there a debate wether users should be able to rename files from file open/save dialogs? dialog text made non-selectable for no good reasons, forcing manual transfer of alert messages to search engine boxes.. non-resizable modal dialogs with scroll bars or ellipses? a silly more button in download dialogues taking just as much space as the information it hides.. list goes on. (**) https://bugs.kde.org/show_bug.cgi?id=183774 (***) https://bugs.kde.org/show_bug.cgi?id=265567
Re: Qt5 - KDE5?
On 09.05.2011 21:17, Alberto Mattea wrote: 2) Binary compatibility. It has taken four years to port most KDE3 apps to the new infrastructure, and some (like Kooka) never did it. Many projects just ended the transition from KDE3. Experience shows that even a well alive project may not have the necessary manpower to do a drastic rewrite of the code. So I would take Qt5 as an opportunity to fix legacy interfaces without caring about binary compatibility, but (following Qt direction) the effort to port existing code should be nowhere near the one needed from KDE3 to KDE4. This would allow to maintain the good condition there is a KDE app for everything, which has been just recently achieved again. So, from a technical point of view, don't rush to drop QWidget and switch to QML; let them live together for all the necessary time, and ensure a smooth step-by-step migration is possible. 3) Core apps, or shall we change again everything?. It took at least 3 minor releases (or 2 years since KDE 4.0) to have a fully crash-free experience with the plasma shell. Now it looks fantastic, it is modular (desktop, netbook, media centre) and light (it is usable on an 800 Mhz pentium III). I would hope for a stable 5.0 release, also in connection with point 1). So I'd say don't start again from scratch: the current base is solid, extendable, users recognize it. Changement is not necessarily for good. Absolutely. A lot of projects died during KDE3 - KDE4. A few of them decided to continue *only* for KDE3 without supporting KDE4 at all. That was reasonable to completely break the compatibility with KDE3 as it was too old but KDE4 is still young and even pre-mature in some fields compared to KDE3. Let's please not break all the KDE4 applications around once again. Regards, -- Ozan Caglayan Pardus Linux http://www.pardus.org.tr/eng
Re: Qt5 - KDE5?
On Monday 09 May 2011, marcel partap wrote: Hi there, on this occasion where future direction of KDE is being defined, here's just a note from a linux 'power user' who turned from full KDE (3.5) fanboyness to using xfce, coping with some kde apps (yakuake, konqueror, okular, the games)... - Do we want KDE 5 to be a big change, or just a small increment? Do we need a big change? I don't think so - we are already fantastic :) although you put a smiley there, _this_ attitude is what i perceive as a huge problem regarding current KDE. The continuing 'pareto UI design frenzy', i.e. designing for the fictitious 80% collective of Joe-users(*) has been a real turn off to me. But the real problem behind that is that often, even elaborate users have no choice of changing stuff they'd like to behave differently (besides locally applying hacky patches). Fortunately, QML offers a great way out: separating GUI definition from the code providing features. This could result in what i'd dream of as great solution - UI style sheets, for joes, advanced users or kids. That's a long way off though. Another thing, the handling of bug reports could be a bit more mature in some cases. Flagging users UI improvement proposals as RESOLVED/WONTFIX (**) or pretending loss of user data under special conditions is not a problem that could be dealt with (***) is not what i'd consider super responsible maintainership... but then again i stopped reporting bugs anyways out of demotivation... Not to play the blame game here, i still have hopes KDE can be the fun 'kool' power experience KDE 3.5 was, but my euphoric 4.x expectations have largely been smashed by instability, imho poor UI decisions and a plasma dream that never materialized. Seriously, you said you switched to xfce... Which KDE 4.x version was the last one you tested ? At least since 4.5 plasma is rock solid and fast. I haven't found anything which I could configure with KDE 3 but can't with KDE = 4.5. Give it a try again :-) Alex
Re: Qt5 - KDE5?
Alberto Mattea albe...@mattea.info writes: 2) Binary compatibility. It has taken four years to port most KDE3 apps to the new infrastructure, and some (like Kooka) never did it. Many projects just Er, just for info Kooka did finally make it to a KDE4 port (although not as an official part of KDE SC): http://techbase.kde.org/Projects/Kooka 3) Core apps, or shall we change again everything?. It took at least 3 minor releases (or 2 years since KDE 4.0) to have a fully crash-free experience with the plasma shell. Now it looks fantastic, it is modular (desktop, netbook, Let's not do this again, please. When I first started using KDE as my primary Linux desktop it was a few months before the release of KDE2. KDE1 was usable but limited, but KDE2 was a huge improvement and it was usable immediately. Same with KDE3, again a huge improvement over KDE2 and usable immediately. But KDE4 was nothing like that; I'd been watching the state of trunk fairly closely and waiting, and it was 2.5 years from the first release of 4.0 until the desktop was stable enough for me to use in day-to-day work. I'm still not using KMail (the one application that *really* has to be reliable) from KDE4 yet. Yes, I know the official line at the time was that KDE 4.0 was a technology preview release and not yet finished. But, despite that advice, all of the distros started shipping it and every magazine and blogger started reviewing it, with much negative publicity (some of it justified). KDE 5.0 has to be ready, reliable and usable if that is to be avoided. -- Jonathan Marten http://www.keelhaul.demon.co.uk Twickenham, UK j...@keelhaul.demon.co.uk
Re: Qt5 - KDE5?
Folks please. Let's not make this an endless bikeshedding exercise. Let's keep this focused. This is not the right place for users to complain about KDE 4.0. Thanks! Cheers Lydia, k-c-d moderator -- Lydia Pintscher Amarok community manager kde.org - amarok.kde.org - kubuntu.org claimid.com/nightrose
Re: Qt5 - KDE5?
On Monday 09 May 2011, Lydia Pintscher wrote: Folks please. Let's not make this an endless bikeshedding exercise. Let's keep this focused. This is not the right place for users to complain about KDE 4.0. I have seen only one email with a complaint in this still short and young thread. Not sure this makes it necessary to step in as moderator ? Alex
Re: Qt5 - KDE5?
On Monday, 9 de May de 2011 22:02:28 Alexander Neundorf wrote: With Qt5 around the corner[1], I think it is time to start thinking about KDE5 That's quite surprising for me. The last statements I heard about a Qt5 were not planned for the forseeable future. And now next year is quite soon. It wasn't planned for the foreseeable future. This is quite recent. The plan was to make Qt 4.8 the modularised release, then do a 4.9, 4.10, then start thinking of Qt 5. At some point in late March, we were looking at the difficulty of modularising Qt 4.8 and the Qt 5 manifesto (Wayland + Lighthouse + Scene Graph + QML 2). Then we decided that modularised Qt = Qt 5. Then Easter came, we drafted the blog and here we are. No secrecy, no secret agenda being worked on behind anyone's back. The blog was published at the earliest possible opportunity. Lars started making BIC changes last week on a private branch of Qt 5 and it took some time to get the text of Qt 5 reviewed by everyone who wanted to review it. This was so early that the Qt 4.8 blog isn't finished yet... [big snip] I agree 100%. We should see this only as a chance to break ABI. Agreed too. Break ABI and clean up the API, but nothing more. So from my POV, we could use this as a chance to reorganize our libraries to make them fit for mobile, and more fit for OSX and Windows and 3rd party developers, but try to keep the APIs really as much as possible as they are. IMO we can't afford another big porting effort already again for all the KDE applications which have just been ported to KDE4. I'd also add the goal of upstreaming into Qt -- and maintaining stuff there. Let QML exist and grow and flourish, but let's not try to introduce it big way in KDE in the next 12 months or so. Yup. Qt Quick for Desktop is a worthy goal and I believe it can and will revolutionise the way we do UX. But it's not there yet. Heck, even QML is not a year old and hasn't had a full cycle of development to iron out all the kinks. The OpenGL requirement is also the right way to go, but reality will need to adapt first. We have too many crappy drivers to deal with and a raster engine (like Mesa's LLVM-Pipe) to mature first. Wayland will also be an unproven technology in early 2012. I'm hoping that if KDE 5.0 is released in Jan 2013, Wayland will have had one year to mature and be rock solid. -- 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 Description: This is a digitally signed message part.
Re: Qt5 - KDE5?
On Monday 09 May 2011 19:31:18 Olivier Goffart wrote: QML starts almost from scratch. Don't tell anyone QML is the successor to QWidgets. If you do, they are asking for _every single feature_ in QML that QWidgets had. Programmers like the challenge to start from scratch. Users don't unless you advertise it as a new thing. Problem solved. Christoph Feck (kdepepo)
Re: Qt5 - KDE5?
Am Montag 09 Mai 2011, 18:03:18 schrieb Olivier Goffart: Hi, With Qt5 around the corner[1], I think it is time to start thinking about KDE5 Sad to see that even our own guys still don't get the rebranding even after almost two years. Qt 5 results in no need to think about KDE5 because there will be no such thing as KDE4. The only thing Qt 5 does is to enforce KDE Platform 5 because of the broken binary compatibility. KDE Plasma Workspaces can stay at 4.x and build on Platform 5 unless KPW magically becomes something totally different that justifies a major version jump. Change of the back-end alone does IMO not justify a big version jump for KPW just as Phonon did not jump to 5.0 just because xine was deprecated in favor of VLC and GStreamer. Nothing from KPW guaranties binary compatibility which IMO means that the user workflow has to change dramatically for a big version jump. If classic QWidgets stay, I also don't see why KDE Applications need to jump from 4.x to 5.0. Most will just be recompiled to use the new Platform 5 without any huge GUI facelifts. Markus Raw summary: - Qt5 is planed to be released in about one year from now if everything goes well. - It should be mostly source compatible with Qt4, and is just an opportunity to break binary compatibility. - QWidget just stay for compatibility. All focus is put on QML. Do not expect new development on QWidgets from Nokia. - The OpenGouvernance should finaly come into light, meaning we (as KDE), can contribute easier to Qt. I guess it make sens, as Qt breaks binary compatibility, to do the same in kdelibs. Does that mean KDE 5? or KDE SC 5? Not necessarily. We can break binary compatibility, and change the .so version of our library without changing the major version of KDE itself. But I think it would anyway still be a smart move to do it. And I think this is a perfect opportunity to get some KDE class in Qt as we planed. [2] Some item we might want to think about: - Do we want KDE 5 to be a big change, or just a small increment? - Do we want to focus on QML, or stay with QWidget? - Shall we try drive Qt5 based on KDE5's need? - Do we have more visions for what KDE5 should or should not be? I guess there is as many opinions as people involved :-) Many things to think about, and that can be discussed further, and decided in Platform11 [3] (I will be there) But in my opinion, if there is something we should learn from the KDE4 transition, it is not to be too ambitious.
