"Cornelius's grand plan" - Merging KDElibs into Qt
kde at michael-jansen.biz
Sun Oct 31 13:26:13 GMT 2010
On Sunday 31 October 2010 12:33:22 Mark Kretschmann wrote:
> Hey all,
> after reading the whole thread that started with Chani's mail ("why
> kdelibs?"), I think the noise level has become a bit too much there.
> Cornelius had proposed this rather daring idea:
> It's a very controversial idea. However, I think it is so refreshing
> that it deserves some more thought. Personally, I think the idea is
> great, if we can overcome some of the obvious road blocks. I would
> love to read some honest and direct thoughts from you guys.
> What do you think about it?
If we gonna forward that route i guess some kind of categorization for all of
kde(pim)libs (and all classes anywhere else in kde that should be in
kde(pim)libs - kdesupport/kdebase ...) is necessary.
I could think of four classes. I will present them. Comment welcome.
1. Small improvements to the Qt Libraries
Those are the so called convenient classes. Classes the have been added to the
KDE Libs because of some shortcomings of the Qt Classes or to add some
convenience methods. I guess classes like KUrl and KIcon (at least parts) fall
into that category.
The classes in this category do not add additional functionality, requirements
or anything else to the Qt Classes.
2. Additional Functionality
This are additional functionality that kde provides which we can see separated
from the KDE Environment. KIO is the big candidate here. Those date classes
mentioned are others.
Everything in here should be Qt-Only.
3. KDE Classes that do not require the complete KDE Environment
We probably have convenience classes that do not require a full kde runtime
environment when the app is running but are KDE specific anyway. I think about
classes that enforce the kde configuration file style. I can't really give
examples here but i guess all classes that define the kde layout and look and
feel fall into this category. if you use those classes your applications
starts to look and feel like a kde app.
4. KDE Classes that require the complete KDE Environment
And then there are the classes that make your app depend on the full kde
runtime environment when using it.
Then a decision has to be made which of those categories make sense for qt. 1
is a no brainer. 3 and 4 are no ways. If a class in 3 or 4 is a valid
candidate for qt it's either wrong there or the definition of kde specific
have changes (For example qt started to add some configuration file scheme for
applications modeled after kdes example.
The classes in 2 are a different beast and the most difficult one to decide.
Questions to answer:
1. Do they support all Platforms Qt supports. If not it is not likely they
will ever go to qt.
2. Is it possible to support all platforms outside of nokia because the
development for them happens outside. I once got an error fixing patch
rejected because it didn't fix the patch on the mac. I have no mac and still
no idea whatever was not working on the mac so no chance to amend the patch
(No will either but that's a different question).
3. Are they mature enough so we won't get into trouble with qt's release
cycles and general promises qt make to it's customers? Binary compatibity,
Source compatibility, Feature parity ....
In other word the same problem Modestas Vainus sees.
I think we should work on splitting all our libs according to the categories
above. And only push bugfixes and convenience stuff into Qt as long as the
contribution model is at it currently is.
Qt -> Kdelibs.QtImprovements( Candidates for merge into Qt) -> Kdelibs.QtLibs(
Qt Addons) -> Kdelibs.look and feel -> Kdelibs.Platform Integration
If we really separate 3 and 4 is optional.
Thats my idea. And NOW i will read the wiki.
More information about the kde-core-devel