"Cornelius's grand plan" - Merging KDElibs into Qt
johnlayt at googlemail.com
Tue Nov 2 21:48:06 GMT 2010
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
More information about the kde-core-devel