Splitting out a KX11Extras frameworks from KWindowSystems

[David Faure]

On Monday 16 September 2013 15:07:37 Martin Graesslin wrote:
> Hi,
> 
> KWindowSystems is a framework which looks to me like a KX11Extras framework.
> Most of the things inside this framework are X11 specific. Some API even
> has XLib/XCB specific data types as arguments or return values (e.g.
> netwm.h). The only class which has a non-X11 implementation is
> KWindowSystem and KWindowInfo, but also those are highly X11 inspired.
> 
> My suggestion would be to create a new tier1 framework KX11Extras which
> contains:
> * fixx11h.h
> * KManagerSelection
> * KStartupInfo
> * KXMessages
> * NETwm

I'm not convinced about KStartupInfo. It's used pervasively and it's much more
convenient if the class is available on all platforms, even if it does nothing.
Otherwise it leads to such horrors like in krun_p.h:

#if !HAVE_X11
    KProcessRunner(const QString &command, const QString & binName, const QString &workingDirectory);
#else
    KProcessRunner(const QString &command, const QString & binName, const KStartupInfoId& id, const QString &workingDirectory);
#endif

OK, this shows that "it's already only on X11" though, so your suggestion doesn't make
things worse, it just goes in the opposite direction to what I thought would be nicer for app code.
Not a strong veto then, if you think this makes sense, proceed, I just wanted to raise the
question of whether it wouldn't be possible to make the class available on all platforms
for less ifdef-ery.

About splitting out an extra framework: what do we gain from it, actually?
It's not like KWindowSystem brings in any more dependencies, so users of the above classes
wouldn't have been bothered by the other classes in the framework. It seems the proposal
is merely about naming? (making the purpose of the framework clearer).
Ah and about making it clear which classes are only available on X11, and which ones are
available everywhere, I guess. I'm just a bit uneasy about making too many too small
frameworks when we can avoid it, but OK, that's another "not a strong veto".

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5