fix frameworks-kactions compile error

[Kevin Ottens]

On Wednesday 11 April 2012 23:34:18 Stephen Kelly wrote:
> So here's my proposal:
> 
> * kplotting should be renamed and repurposed as kwidgetsaddons (tier1), a
> framework which depends only on QtWidgets. The widgets in there should be
> self-contained and not rely on any 'KDE stuff' (This is one of the central
> goals of the frameworks effort and the only reason to move stuff around at
> this point). I had to choose the kwidgetsaddons name because kwidgets
> exists,

Not sure if having kplotting grouped with the rest is a good idea, definitely 
looked like something which could stand on its own as a cheap plotting 
solution.

Also AFAIK it's doomed to have at least two competitors, so someone who wants 
to do plotting and use some of our widgets probably don't want to drag two 
plotting engines.

> and because it's equivalent to similarly named kcoreaddons,
> kdbusaddons etc, though I don't think any of them are the right name.

I'm open to alternative names for those ones. Those names appeared during 
Platform11 actually, the constraint being: should be a very thin layer of 
extra features on QtCore, QtDBus, etc. respectively.

> * Classes in kdeui should be moved there if the dependency constraints are
> met.
> * Widgets which depend on 'KDE stuff' or which are 'KDE versions of Qt
> classes' don't really belong in kwidgetsaddons. As they depend on KDE stuff,
> or provide KDE-level integration, they are not relevant to Qt developers
> (tier1 stuff should be exactly that). Instead they could be moved to a
> different framework kde_ui_integration(tier3) or so which provides the KDE-
> level integration that KDE requires, without getting in the way of Qt
> developers. The contents of kde_ui_integration would be hopefully
> everything that's left after moving out everything that can go into
> kwidgetsaddons.

Totally agree.

> If we can agree on that, the next step is to look at the available widgets,
> see if they are already KDE-free enough to belong in kwidgetsaddons, if not
> then why not, and whether they should be modified to fit in the tier1
> framework.
> 
> Taking a few of them:
> 
> * KArrowButton
> ## Standalone : Yes
> ++ Generally useful outside KDE: Yes
> ?? Remaining issues and cleanups: Uses assert.h instead of Q_ASSERT.

Done.

> [...]
> This is only a partial selection of the widgets available already with some
> definite candidates to populate a kwidgetsaddons library like I described,
> so I'm sure creating such a framework would be worth it.

Could you bring those notes to the newly created page, the comment column is 
here for that:
http://community.kde.org/Frameworks/Epics/Reduce_class_duplication

Once a decision is taken it likely means creating corresponding tasks for the 
Qt5 and/or kdelibs cleanups epics.

> [...]
> At the center of the questions of what to do with KUrlLabel and KCapacityBar
> are the question of what to do about their KColorScheme dependency. Their
> use of KColorScheme seems to me like something that should be handled by
> the style instead (otherwise, for example, QProgressBar wouldn't look
> consistent with a KCapacityBar with its backgrounds and fill etc). Oxygen
> may already even handle a KCapacityBar (I'm not certain):
> 
> kde-workspace/kstyles/oxygen{master}$ git grep CapacityBar
> oxygenstyle.cpp:        CE_CapacityBar( newControlElement( "CE_CapacityBar"
> ) )
> oxygenstyle.cpp:        if( element == CE_CapacityBar )
> oxygenstyle.cpp:            fcn = &Style::drawCapacityBarControl;
> oxygenstyle.cpp:    bool Style::drawCapacityBarControl( const QStyleOption*
> option, QPainter* painter, const QWidget* widget ) const
> oxygenstyle.h:        virtual bool drawCapacityBarControl( const
> QStyleOption*, QPainter*, const QWidget* ) const;
> oxygenstyle.h:        QStyle::ControlElement CE_CapacityBar;
> 
> 
> KColorScheme is very different from QPalette. It seems to have 4 dimensions
> that QPalette doesn't have. I'm all for configuration, but I think it should
> have an affect in the style, not in the widgets themselves. Any thoughts?
> 
> Would it be possible to remove the use of KColorScheme from these widgets in
> general?

I'm unfortunately completely ignorant regarding KColorScheme... I agree it 
should probably not leak into our widgets and be used by the styles only 
though.

Regards.
-- 
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/20120412/af611d62/attachment.sig>