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

[John Layt]

On Tuesday 02 November 2010 18:56:49 Aaron J. Seigo wrote:
> On Monday, November 1, 2010, John Layt wrote:
> > So, imagine this.  QLocale becomes the container for the locale settings.
> 
> this just begs for a system where people with domain-specific knowledge and
> hands-on experience with specific parts of the code (e.g. you and KLocale /
> KCalenderSystem) can write up specific proposals for such changes and add
> them to a central repository of them.
> 
> some of these things will end up requiring coordination with Qt or even
> other projects, which wiould make such a system invaluable.
> 
> it would also give us a way to measure the effort we'd be considering
> getting ourselves into, prioritize which parts to tackle and, should we
> undertake it, a way to track our progress.

Aye, it is something I really need to document properly, where Qt falls short, 
where we fall short, etc.  At the moment it's just knocking around my head.  
For big stuff like that, a wiki might work OK.

Documenting what each class adds to the Qt equivalent could also be valuable 
to figure out more concrete proposals too, and I don't just mean in a wiki 
which could quickly get stale, but right in the classes themselves.  For 
instance, KComboBox has good apidox that explains what it has added:

"a completion object that provides both automatic and manual text completion 
as well as text rotation features, configurable key-bindings to activate these 
features, and a popup-menu item that can be used to allow the user to change 
the text completion mode on the fly" 

Sounds cool, and taking a step back adds "Configurable auto-completion system" 
to the list of things we have that could benefit Qt.  But on the other hand 
no-one would be much the wiser from reading the KUrl apidox (Not pointing 
fingers, I'm as guilty of neglecting apidox as anyone, but David's explanation 
why really needs writing down :-).  Perhaps we need a template for class 
apidox that includes a 'Benefits' section to document _why_ a dev would want 
to use a K class in place of a Q class?

I think the most concrete thing we can achieve is the low level stuff of 
having Qt treat KDE as a platform that it integrates into properly, and our 
apps integrating properly into other platforms by falling back to Qt support 
there.

John.