RFC: split platformtheme plugin from frameworkintegration and move to kde/workspace

[Martin Graesslin]

On Thursday, December 10, 2015 2:39:36 PM CET Mark Gaiser wrote:

> > That is why I don't get your point. It just doesn't make sense to me and
> > it
> > sounds being based on wrong assumptions.
> 
> Yes, it will. Here is the proof (taking archlinux as example since it is
> very much like upstream with close to zero patches applied).
> plasma-workspace:

how is plasma-workspace's dependencies a proof? Once again, why would the 
logical moving change dependencies?

> https://www.archlinux.org/packages/extra/x86_64/plasma-workspace/
> Depends (among others) on breeze.

That's wrong. plasma-workspace doesn't define a dependency on Breeze. Looks to 
me like a fix on Arch to get the runtime dependency installed. Proper fix: 
runtime depend from QPT plugin (which would be correct way!). Which we cannot 
do at the moment because breeze is in kde/workspace, but QPT plugin is in 
frameworks.

> That in turn depends on kdecoration:

That's correct. Breeze provides a kdecoration theme. You get this dependency 
when using QPT plugin currently as well, as it requires breeze.

> https://www.archlinux.org/packages/extra/x86_64/breeze/
> plasma-workspace itself depends on kscreenlocker.

That's correct as up until a few weeks ago kscreenlocker was part of plasma-
workspace

> kwin is required by plasma-workspoace, but compile time only. Ok, i give
> you that one.
> And you're right about systemsettings. It is only required by
> plasma-desktop, not workspace.
> 
> > And even if dependencies by distros would be set up that it pulls in let's
> > say
> > KWin. What would it change? A few files get installed, that's it. It would
> > not
> > have any runtime impact. That's what I meant with the barrier in people's
> > head. You cannot install Plasma (just install, not run!) because it will
> > taint
> > the lightweight system. If that is not what you think, then please
> > elaborate
> > why moving the plugin to kde/workspace is bad from your perspective.
> 
> It's not just a barrier in my head. It's a waste of resources if one
> package that doesn't need a dozen dependencies, pulls it in because someone
> decided it doesn't matter for the resources. If you don't use it, don't
> install it.

Sorry, but that's what I consider as nonesense and is not what we should 
optimize for. That is exactly the "you cannot install KDE software, because 
deps!!!" thing we have argued against for years. Right now my install size of 
all KDE applications against Qt 5 in debug build with maybe multiple copies 
takes less than 4 GB on my system. With current storage costs that's 0.12 $

> But that's my opinion. You know i'm all about optimization (more so then
> other people) so i can understand if you don't share this opinion.

Yes optimize, don't minimize install size! Install size just doesn't matter. 
On Android phones it's no problem that each and every app ships and installs 
it's own Qt, but on desktop systems with way less storage constraints and less 
connectivity constraints it's supposed to be a problem?

> > It would not be on purpose, obviously. It's just that it can happen,
> > because
> > we are not aware on how it will be used outside Plasma. And I'm sure we
> > already did break for other environments. Let's consider for example the
> > infinite loop if a system doesn't provide SNI and no xembed. Happened,
> > couldn't happen on Plasma because it provides SNI.
> 
> There is a difference here.
> As it is right now, breaking it would be a bug that has to be fixed.

who says that bugs have to be fixed? Honestly, if it's in code I would have 
added and only affects a minority of users in a weird setup I cannot reproduce 
without investing lots of time: unlikely. Like the interesting crash reports 
of screenlocker when using Compiz - not going to get fixed, not able to 
reproduce.

> 
> When it moves to plasma workspace the breakage may be intentional for
> integration purposes.

No difference to current state. If we break things due to integration with 
Plasma (and we did so, see SNI), it breaks. And again: we wouldn't do on 
purpose. We don't go "oh let's break i3 users today!" And that also means that 
if we get a bug report and it's reasonable (because there are also Plasma+i3 
users) we might fix it, or not, like explained above.

> 
> > Other examples could be integration with services provided by workspace
> > and we
> > just don't consider that it doesn't exist, connection to powerdevil dbus
> > services, dependencies on KWin, etc.
> 
> Could it be that "frameworkintegration" is not named properly?

Please see earlier thread on that topic. The naming is correct, it's the QPT 
plugin which shouldn't be there.

> It sounds
> like it should be "Plasma framework integration" since the examples you
> give are quite specific to the needs of plasma.
> 
> To be clear, my assumption with the name "frameworkintegration" is as
> follows.
> I expect it to integrate framework specific features (like the file open
> dialogs) as replacements of Qt features (like many of the QFileDialog
> static functions that would then open framework versions of those dialogs).

That's the QPT plugin and yes that is Plasma specific and as I showed in this 
thread used to be in kde-workspace in 4.x time. I don't know why it was moved 
outside of workspace, but I consider this to have been a mistake. 

> 
> > > Convince me of the benefit of better integration with a couple of sample
> > > use cases.
> > 
> > All right. What I currently have in mind is making the QPT plugin depend
> > on
> > KWayland (currently in kde/workspace) to tell KWin to use server side
> > decorations instead of Qt's client side decorations.
> 
> Very valid examples!
> Can't that be done in a way that doesn't make it depend on KWin? In some
> abstract way?

It won't depend on KWin. It will depend on an API provided by the KWayland 
library (tier 1). In runtime it depends on a wayland interface which in theory 
anybody can provide. In practice it will just be KWin.

> That way other window managers could benefit from that as well.

Sure they can implement the interface or just use KWayland.

So let's look at it again from a very technical level:
1. The QPT plugin currently has a de-facto not specified dependency on breeze
2. The QPT plugin currently has a de-facto not specified dependency on plasma-
workspace for look-and-feel package
3. Right now the only package (in Debian) to depend on frameworkintegration is 
plasma-workspace
4. Right now users of other desktops have to manually install the package
5. Right now users of other desktops have to manually specify env variables
6. In fact we even have a non specified dependency loop as breeze depends on 
framework integration.

How will this look after the logical move:
1. The incorrect not specified de-facto dependencies can (!) be properly 
defined as runtime dependencies
2. On other desktops users have to install a package which isn't automatically 
installed
3. On other desktops users have to manually specify env variables to use it

What will be the actual change? A not specified dependency can be specified as 
a runtime dependency.

Just by the move no dependency changes. It's a logical grouping, nothing more. 
Dependencies only change if we do specify them. By only logical moving nothing 
changes.

Now yes, the move is to maybe add more dependencies in future. But this will 
happen either way or another. If we cannot depend on stuff from workspace we 
have to push them into frameworks.

Please take a step back and think about the whole thing. Please think about 
whether moving a plugin in a logical structure causes the dependencies to 
increase. If you come to the conclusion that yes it will, please have a look 
at the size of the packages it would in worst case(!) start to install. Please 
compare that to the size of your hard disk. Please also compare it to other 
things like let's say LibreOffice or Chrome. Take a step back and think 
whether the change is as bad as you expect it to be or whether it's actually a 
non-issue.

Cheers
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20151211/6da4dcb0/attachment.sig>