kdeui splitup (widgets)

[David Faure]

On Sunday 29 April 2012 15:41:04 Stephen Kelly wrote:
> If we discard that idea though, there's still the question of how relevant
> to Qt developers outside of KDE applications these things are. If they are
> not relevant outside of KDE applications, there's no point in splitting them
> from kdeui.

Well, that's an option too, keeping libkdeui. I just thought we wanted to make 
things more modular - e.g. by moving xmlgui out of kwidgets, we open the door 
for a replacement later on, while right now the kernel of kdeui (e.g. 
KActionCollection) calls into xmlgui. To me this isn't only about "Qt 
developers outside KDE applications", it's also about untangling the mess, for 
future maintainance.

> If they are, it might make sense to have a better name than kwidgets, like
> kcompletionwidgets or so. It again kind of depends on how much stuff would
> go into the framework and whether all the stuff we have can fit into the
> categories we have nicely.
> 
> If we drown in taxonomy though, then yes, I'm sure kwidgets is a fine name.

kcompletionwidgets would only contain KLineEdit+KComboBox, and the completion 
classes. That's really not much imho.
(BTW KLineEdit has quite a few other features than completion currently, but I 
already listed them on the Qt-5.1-todo list).

There's also all the rest (KMainWindow, KToolBar, KStatusBar). I think it can 
just all go to kwidgets.

> I'm sure this is fine. Apps that use QtDBus and KGlobalSettings will
> internally listen to ("/KGlobalSettings", "org.kde.KGlobalSettings",
> "notifyChange"), and when that service is not found it is not an error, but
> the update will only take effect when the app is restarted?

Exactly.

> Definitely a functionality I would prefer to have in QPA (as there's only
> one 'change' signal needed, at least in our design), but I don't know if
> QtProject would allow that generically, or if we should create a KDE QPA
> plugin which does this.

Yep.

> Right. What I was referring to really was the
> 
> // Set by KApplication
> KWIDGETS_EXPORT QString kde_overrideStyle;
> 
> Maybe just something that needs to be cleaned up or split out.

This is just for the handling of the --style command-line option when 
activate() is called. We can do this differently in QPA, with a plugin that 
asks for the default style, but doesn't ask if --style was passed.

> > 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?
> 
> I'm not certain we're talking about the same contents. I would put KDialog
> in the kde-ui-integration because it's all about consistency, but I think
> your plan for that might be different for example. Mostly we agree though,
> yes.

KDialog is also about convenience. We can port away from it what needs to be 
in low tiers, but we can keep using it elsewhere, and having it in kwidgets 
doesn't hurt.

> > 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).
> 
> Yes. We have some of that stuff in place already. I don't think we have a
> list of what's missing though, do we? That might also 'free up' some more
> widgets.

The list is basically the non-deprecated methods in KGlobalSettings :-)

Changing the icon loading settings is specific to KIconLoader though, unrelated 
to Qt.

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