David Faure wrote: > It seems to me that we haven't properly defined yet, what goes where.
Yes I agree, I brought this up a few weeks ago too. > > Looking at kdeui and at the current kwidgets, while filling in > http://community.kde.org/Frameworks/Epics/Reduce_class_duplication > I came up with the following proposal: > > * kguiaddons, for QtGui-related classes (no widgets), such as color utils; > no change there. Yes. > > * kstandalonewidgets or any better name KWidgetsAddons, for consistency with the other similarly named. http://thread.gmane.org/gmane.comp.kde.devel.frameworks/473/focus=478 > , for independent reusable widgets, > such as: > KSeparator, KHBox/KVBox, KLed, KArrowButton, KCapacityBar (if the > dependencies on kcolorscheme and kstyle can be sorted out), KButtonGroup, > KNumInput, KRuler, KXYSelector, KSqueezedTextLabel (until this goes into > Qt itself), KTitleWidget. > > Hmm, I was hoping the list would be longer, but many widgets have a > dependency on KIconLoader, or KColorScheme, or KCalendarSystem (might be > fixed by Qt5, don't know), Yes, I had the same conclusion, which is why I didn't create the kwidgetsaddons framework already. That said, we have the kplotwidget framework which has only one widget (I still think it's silly), so why not? > > * and kwidgets, for the "bigger" stuff, I'm not sure I agree. > KLineEdit [advanced completion > support], KComboBox [ditto], Maybe a completion framework makes sense? Would such a thing be useful outside of 'KDE applications'? Why do we need a separate completion framework? Is the one in Qt fixable/extendable? > icon loading, Maybe, we should see what happens with icon loading in Qt 5.1. The current icon loading stuff depends on KGlobalSettings, depends on KApplication, depends on 'KDE integration', so currently at least, it's not interesting to Qt developers. > gui items, I don't think KGuiItem is good enough API that it should be kept really. If it is good API, then there should be something like it in Qt. > dependencies on > KConfig (directly or via KGlobalSettings), etc. Possibly KMainWindow, > KToolBar and all that, too. Maybe. I think anything that is only interesting to 'KDE applications', and not interesting to Qt applications (anything requiring the use of daemons etc, as happens when using KApplication, the 'KDE integration' stuff) doesn't really need to be in separated frameworks. After we've split out the useful parts of kdeui, whatever remains should simply be renamed kde-ui-integration. No need to split into eg (looking at ls output), a kde-findreplace-framework, a kde-notifications-framework, a kde-fonts-framework, which all depend on KApplication and other KDE- integration. KDE application developers are not interested in frameworks and they don't care what they link to, if it's part of KDE anyway, so I don't really see any benefit in creating many frameworks which all depend on 'KDE integration'. It will only make the buildsystems of KDE applications more difficult and inconsistent. > > The difference is that kstandalonewidgets can be tier1 -- no dependencies > on any other frameworks, while kwidgets is tier2 or 3, with all its > dependencies (kcoreaddons, kguiaddons, kconfig, etc.) Yes, but also runtime 'KDE-integration' dependencies, like KApplication and it's DBus KGlobalSettings things etc. > > Hopefully this also gives a clear answer to earlier questions about > "should we remove dependencies on kguiaddons or not". Yes if the target is > kstandalonewidgets, no if the target is kwidgets. > > Feedback welcome, including better naming. > Thanks, Steve. _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel