kdeui splitup (widgets)

[Stephen Kelly]

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.