I am glad to see this thread and equally glad to see the long list of valuable topics. I'd like to add something popping on top of my head for quite some time (while not working on picking new names for office suites ;))
I propose to go with Qt-only libs a bit more, to make our offerings more independent each-other and drive potential contributions of new kind (Qt only devs, non-KDE devs...). Filters are good candidates for this group, and especially the lower-level libraries like mso Smart Art, Diagrams... KoReports are nearly Qt-only already (as a fork of OpenRPT it has never used kdelibs in fact). The same for KoProperty lib. I am investing into Qt-only Predicate a lot too (http://community.kde.org/Predicate), as you know it'll be dependency of kexi, hopefully 2.4. Moreover I also believe that every app has some nontrivial bit of code that can be provided on the outside with a simple API, say, using the Facade pattern. At a conceptual level the idea may evolve into slightly different model of composing our building blocks: develop core functionality as Qt-only and then extend for KDE, to get the integration level and look&feel we all want. A bit like it is in WebKit/QtWebKit tandem. RFC. -- regards / pozdrawiam, Jaroslaw Staniek http://www.linkedin.com/in/jstaniek Kexi & Calligra (kexi-project.org, identi.ca/kexi, calligra-suite.org) KDE Software Development Platform on MS Windows (windows.kde.org) _______________________________________________ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
