On Tuesday, November 2, 2010, John Layt wrote: > 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.
a wiki could work, with some discipline, though there are F/OSS web apps out there that provide a built in work flow. Suse's openFate for one and whatever it is that Canonical uses for their task proposals (part of launchpad?) for another. > 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. per-class notes is a bit more fine-grained than what i was thinking. for something like the KComboBox example you provided, that might be part of a larger "identify widget class in libkdeui that are candidates for merging with Qt" and it could contain a list of those widgets, brief summary of target funcdtionality and the rest could, as you note, go into the apidox. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks
signature.asc
Description: This is a digitally signed message part.
