kdeui splitup (widgets)

Kevin Ottens ervin at kde.org
Thu May 3 16:19:33 UTC 2012


On Sunday 29 April 2012 10:20:01 David Faure wrote:
> It seems to me that we haven't properly defined yet, what goes where.
> 
> 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.
> 
> * kstandalonewidgets or any better name, 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,

I see two solutions there:
1) Either we think KIconLoader is so awesome that most Qt apps would need it 
in which case I see no problem to have it in kwidgetsaddons;
2) Or, it's not *that* awesome to justify having it as public API and then we 
use instead QIcon::fromTheme in kwidgetsaddons (probably also planning to have 
the cross-process cache somehow in Qt directly or via a plugin targetting Qt 
5.1 or 5.2).

I admit I'm leaning toward (2), KIconLoader API is very much pushing 
implementation details out IMO. And of the interesting features only one 
requires API which would be the overlays.

> or KColorScheme,

AFAIK we had kind of a consensus to use that one only in style from now on, 
and to use QPalette in our widgets. Or I'm mistaken?

> or KCalendarSystem (might be fixed by Qt5, don't know),

That one I'm not sure, I never manage to know where we are in that department 
on the Qt side... But AFAIK we're talking about only the 5 date related 
widgets.

> * and kwidgets, for the "bigger" stuff, KLineEdit [advanced completion
> support], KComboBox [ditto], icon loading, gui items, dependencies on
> KConfig (directly or via KGlobalSettings), etc. Possibly KMainWindow,
> KToolBar and all that, too.
> 
> 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.)
> 
> 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.

I like this plan overall. Apart from the fact that kwidgetsaddons population 
could be larger than expected with the couple of dependencies cited above.

> Feedback welcome, including better naming.

Sorry, no better naming yet than kwidgetsaddons vs kwidgets so far. :-)

-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud patron of KDE, http://www.kdab.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20120503/04eff343/attachment.sig>


More information about the Kde-frameworks-devel mailing list