kdeui splitup (widgets)

[Stephen Kelly]

David Faure wrote:

> On Sunday 29 April 2012 13:24:43 Stephen Kelly wrote:
>> > 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.

Yes.

>> > * 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?

2012. That affects whether we try to get the features into Qt, which I agree 
isn't a good idea at this point. 

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. 

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.

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

Yes. I don't suggest putting it into Qt. I was mostly just listing open 
questions before which I think we should ask with all of the decisions we 
make. Not putting that stuff into Qt is the best option.

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

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?

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.


> * 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 ;-)

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.

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

> 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 :-)

Right. Splitting it might also be useful.


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

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

Yes.

Thanks,

Steve.