kdeui splitup (widgets)

[David Faure]

On Sunday 29 April 2012 13:24:43 Stephen Kelly wrote:
> KWidgetsAddons, for consistency with the other similarly named.

OK.

> > 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. 

I think we should just go ahead with it.

> That said, we have the kplotwidget
> framework which has only one widget (I still think it's silly), so why not?

4 public classes, not just one. But this is unrelated anyway.

> > * and kwidgets, for the "bigger" stuff,
> > 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?

Depends. Do you want KF5 to go out in 2012, or in 2015?

I think at some point we have to draw a line and just "keep what we have, 
until further notice". There is a LOT of functionality in 
KLineEdit/KComboBox/KCompletionPopup, which would take immense efforts to put 
into Qt, given our current pace of progress.

> > icon loading,
> 
> Maybe, we should see what happens with icon loading in Qt 5.1. The current
> icon loading stuff depends on KGlobalSettings

Yes.

> , depends on KApplication,

No. You're mixing two aspects of KGlobalSettings. In fact it does three 
things:

* reading of user settings (KConfig).

* notifications when the config is changed, via dbus. We could get rid of this 
and force restarting the app (like most Qt code does), but on the other hand, 
it doesn't hurt much to have it. If you think the dependency on libQtDBus is a 
big problem, we can reconsider; I think this is secondary though.

* applying the KDE settings for Qt stuff, at startup. That's 
KGlobalSettings::activate(). That's what is called by kapplication, and which 
should move to a platform plugin or whatever mechanism suits best for this to 
be done automatically from Qt. This was already partly done in Qt4/KDE4, for 
instance with the platform plugin getting the palette from kglobalsettings. 
I'm not sure what the situation is with Qt5, IIRC this plugin doesn't exist 
anymore, and replacements (QPA themes or whatever) are not fully developed 
yet. So this is "wait and see", but IMHO it doesn't change our plans, splitup 
wise and API wise. This bit doesn't need public API ;-)

> > 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.

Again, huge porting effort, for a simple struct that doesn't currently hurt. 
Let's keep it for now, and move on. Otherwise we won't get anywhere.

Maybe the naming is bad, but bundling together all the settings for a button 
(text, tooltip, iconName, whatsthis, enabled) allows standard reuseable gui 
items.

kfile/kfilewidget.cpp: 325: KGuiItem::assign(d->okButton, 
KStandardGuiItem::ok());

Typically Qt apps would just do a setText() and forget about tooltip, icon and 
whatsthis.

> > 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.

No KApplication, no daemons, no.
Just widgets and config.

> 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.

Can you forget about KApplication please? :-) It's not a dependency for any of 
that stuff.

But I agree about "no need for 10 frameworks".
I'm just saying "all that stuff that only depends on kconfig and kcoreaddons can 
go into kwidgets, it will help making it and keeping it modular".
In fact, you call it kde-ui-integration, I call it kwidgets, but we're talking 
about the exact same contents, so we agree, don't we?

> > 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.

No, just libQtDBus, and we could make kglobalsettings silently ignore the dbus 
stuff when the dbus daemon is not available.

And we can definitely split up kglobalsettings - for now I'm mostly deprecating 
its methods step by step, to see what's left in the end :-)

The real discussion behind this is:
* Qt widgets give control to the developer, not to the user. A user cannot 
globally enable things like "smooth scrolling in all scrollareas", or "wheel 
mouse should zoom rather than scroll", or "hide mouse cursor when typing 
text", or the preferred type of completion.
* KDE widgets allow the user to set these things, but this makes KDE widgets 
inconsistent with "pure Qt" widgets.
In my opinion, the perfect solution would be again some sort of hook from Qt, 
either platform plugin / QPA theme, or QStyle hints, which the Qt widgets ask 
about these things, and which we can implement in KDE based on user's choice 
(KConfig).

Actually, QStyle hints is what is currently done about this in Qt, so the 
solution would be to implement these new settings as style hints too.
Yet another TODO for Qt-5.1, but meanwhile it doesn't change the kwidgets idea 
IMHO.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5