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.
