"Cornelius's grand plan" - Merging KDElibs into Qt

[Michael Jansen]

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:
> 
> http://lists.kde.org/?l=kde-core-devel&m=128842761708404&w=2
> 
> 
> 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.

Mike