fix frameworks-kactions compile error

[Stephen Kelly]

Giorgos Tsiapaliwkas wrote:

> On 11 April 2012 19:59, Stephen Kelly <steveire at gmail.com> wrote:
>>
>> That depends on what is supposed to go into kwidgets, which I wrote
>> previously is not clear or decided yet.
> 
> what should we do with this one?

We should talk about what should be moved, and why, and what dependencies 
classes have, and why, and what should be done about that if anything. We 
need to be able to answer the question "Is this useful outside of KDE to Qt 
developers?"

So lets do that now.

> I haven't changed anything to my branch and I won't until the frameworks
> team decide what
> kwidgets should have.

Thanks for that. Your moving stuff around was just creating more work for me 
tbh. If we have goals we can move things to the right place instead of just 
moving them a few at a time out of kdeui.

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, and because it's equivalent to similarly named kcoreaddons, 
kdbusaddons etc, though I don't think any of them are the right name.
* 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.


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.
== Worth cleaning up and moving: Yes

* KCapacityBar
## Standalone : No, depends on KColorScheme
++ Generally useful outside KDE: Yes
?? Remaining issues and cleanups: Figure out how to handle KColorScheme in 
KF5 generally.
== Worth cleaning up and moving: Yes

* KComboBox
## Standalone : No, depends KDE completion, actions and lineedit
++ Generally useful outside KDE: Probably not.
?? Remaining issues and cleanups: Some bad API (for example completionBox( 
bool create = true ); )
== Worth cleaning up and moving: Not at this time.

* KDatePicker
## Standalone : No, depends KDE calendars, notifications (for beeps, which 
looks very odd for a widget I have to say. I don't know of another widget 
doing that), KComboBox (despite appearing not to use any more features than 
those provided by QComboBox), KLineEdit (despite storing it as a QLineEdit* 
and using the API of the latter).
++ Generally useful outside KDE: Probably.
?? Remaining issues and cleanups: Use Qt classes instead of KDE ones.
== Worth cleaning up and moving: Depends on whether Qt gets Calendaring 
systems support, which is essential for a date picker that would suit the 
needs of KDE.

* KLed
## Standalone : No, depends KDE colorutils
++ Generally useful outside KDE: Yes.
?? Remaining issues and cleanups: Port away from KColorUtils
== Worth cleaning up and moving: Yes.

* KNumInput
## Standalone: No, depends on KDialog::spacingHint (sounds like it should be 
in QStyle or QApplication or so), and KLocale (plurals, KLocalizedString 
etc)
++ Generally useful outside KDE: Unknown.
== Worth cleaning up and moving: No. The Qt locale system is too different 
to KLocale.

* KRatingWidget
## Standalone: No, depends on KIcon system.
++ Generally useful outside KDE: Yes.
== Worth cleaning up and moving: Yes, but would require KIcon to move to 
kwidgetsaddons too (which I think makes sense).

* KSeparator
## Standalone: Yes.
++ Generally useful outside KDE: Unknown.
== Worth cleaning up and moving: Unknown. Depends on whether it's useful.

* KUrlLabel
## Standalone: No. Depends on KColorScheme.
++ Generally useful outside KDE: In concept, yes.
?? Remaining issues and cleanups: Needs to be re-written. Currently it 
inherits QLabel instead of QWidget, despite all of the QLabel API not being 
useful to the user of KUrlLabel. Additionally, it does not use any Url class 
in its API or implementation. It should use QUrl instead of QString. It also 
has duplicated (no args) signals that are not needed.
== Worth cleaning up and moving: Yes, if someone is motivated to do the 
cleanup.


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.

Anyone else should feel free to do a similar analysis with the other widgets 
once we decide it's what we want to do.

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?

Thanks,

Steve.