Next Iteration Sprint, confirmed !

Sat May 5 07:37:16 UTC 2012

On Friday 04 May 2012 23:02:16 Aaron J. Seigo wrote:
> On Thursday, April 26, 2012 14:52:55 Martin Gräßlin wrote:
> > If we look around we see that both GNOME Shell and Unity went for an
> 
> i will remind you that you wrote this in a few years and we can see how each
> has done. ;)
Please do so. I'm always interested in seeing what my position was a few years 
back and how it evolved. Currently I recognize that a few years back I opposed 
GNOME Shell's idea of shell in compositor and requiring compositing. Today I 
think with both examples that it was the right thing to do.
> 
> keep in mind that one of Microsoft's great progressions with windows was
> separating the window manager from the rest of the system. ditto for Mac
> with OS X. just because the two worst "full" free software desktop shells
> go in the opposite direction doesn't mean we should lemming along with
> them.
> 
> really, it's a bad, bad, bad idea.
noted
> 
> > I give now some examples of things which are just not possible with Plasma
> > and KWin being two different applications.
> 
> i disagree. see below.
> 
> > * combine present windows with application launching (e.g. SAL, Kickoff or
> > KRunner)
> 
> wrong. we just move this into kwin. no need to touch the shell. after all,
> it isn't evne in the shell right now (it's in krunner, and even there it is
> only in krunner because there was no other place)
Well I'm only talking about moving the functionality into KWin. The question 
is how much remains of the dedicated Plasma Shell after we have moved 
everything that makes sense into the compositor?
> 
> > * include running windows in search and launch
> 
> wrong. we have this now already.
with thumbnails supporting fluid movements?
> 
> > * Tasks Applets showing live thumbnails instead of icons
> 
> can you describe, then, how we do this magically now in the tooltips? ;)
through a huge hack where I described in my mail the problems with the hack.
> 
> > * Include window/desktop thumbnails in QML (showstopper for tooltips)
> 
> easy.
Given that I have written the code to make it work in KWin I have to disagree 
about the "easy" part ;-)

Yes invoking the thumbnail effect is easy but also rather limited and 
performance critical as we know from PA.
> 
> > * Include thumbnails of running windows in an application launcher and
> > still having smooth scrolling
> 
> this is accurate. and we found a solution for this as well -> move that to
> the window manager. not necessary to integrate the shell wholesale into the
> window manager, however.
see my answer to KRunner
> 
> > * Panel tooltips movement not really synchronized/smooth
> 
> that's because the implementation of them is ancient and sub-par.
> 
> > * No crossfading between thumbnail tooltips when going from one item to
> > another
> 
> see above.
> 
> > * Inability to identify windows of the desktop shell to give them special
> > treatment
> 
> we do this with the dashboard.
no we don't, when I wrote that statement I checked with Dashboard. All we 
currently get is an adjusted background. We still are able to use alt+tab, 
present windows or desktop grid while being in Dashboard
> 
> > * Dashboard conflicting with window management
> 
> see above. if this persists, it is a fault with kwin.
no it isn't, sorry, that's the easy turn. We still have no way except some 
hacks to make the fading work based on a window class. If you consider:
    if (w->windowClass() == "dashboard dashboard") {
        return true;
    } else {
        return false;
    }
as a proper solution to identify the dashboard window, I'm sorry that I have 
to disagree. Given that on multi screen a dashboard window is opened per 
screen doesn't help either. Playing the blame game neither ;-)

Using a window class to identify is acceptable in an effect, but not in KWin 
core. It does not perform checks on window classes, but only on window types 
and attributes certain functionality to these window types.

This would require a special window type for dashboard and then the semantics 
would have to be implemented inside KWin.

Obviously the same is needed if Dashboard were in KWin with the difference 
that we can use Q_PROPERTIES.
> 
> > * Conflicting screen edges for auto-hiding panels
> 
> we already discussed this ages ago and we know the answer, which is not "put
> the shell in the window manager"
yes I know and nobody has implemented it as the solution is complex and 
difficult and would again require either on heavy X atom interaction or D-Bus 
calls.
> 
> > * same context menu for KWin and Tasks
> 
> see above.
no in that case there is a technical limitation:
* libtaskmanager connects to signals from KWindowSystems
* when KWin connects to those signals the window manager stops working
-> KWin cannot link libtaskmanager
-> KWin and libtaskmanager cannot share the context menu
> 
> > Many of those issues seem to not exist on competitve (proprietary)
> > platforms and it makes me really sad seeing our competitors having better
> > solutions in that area given that our technology and our features are all
> > there and in fact much better.
> 
> but it is not because the shell is not yet welded to the window manager.
> 
> > This was solved by bringing Plasma technology into KWin: QML, Plasma
> > Components and Plasma Packages.
> 
> which is not "weld the shell into the window manager"
> 
> > Our current solution to KWin/Plasma integration is adding more X atoms.
> > Sorry but I don't want to see any more X atoms passed around. It's an
> > extremely hacky and ugly solution requiring the synchronisation of three
> > processes compared to having the same with QML in just one.
> 
> yet it works. very well.
I agree on the works, but not on the very well.
> and allows process separation. read "kernel level
> context switching for smoothness". if you doubt that this matters, check out
> how Marco made the appearance of the "Add to activity" and "Configure
> Activity" UI's smooth in Plasma Active -> kwin (a separate process)
> animates the show of the window while plasma-device spins on data
> gathering. when it was in one process -> slow. two processes? smooth.
couldn't the same be achieved with two threads?
> 
> and then we need to think about different shells. when the shell is done by
> one process, switching shells at runtime is conceptually simple and should
> be doable without interupting the user experience. if it means re-starting
> the window manager too? nope. moreover, by having the shell external it
> gives nice clean separation.
No I'm not considering that it would need restarting the window manager as all 
that is needed is unloading one plugin and loading another one :-)
> 
> or do you one want one plugin which is plasma-device, and another which is
> plasma-desktop, and another which is . .meh.
I don't want to change any of the existing shells. Plasma-device should stay 
plasma-device, plasma-desktop should stay plasma-desktop.
> 
> i agree that the window manager and the shell should cooperate tightly. that
> does not mean merging them.
I think we need to talk about it in person - latest at Akademy. I am quite 
sure that we have not quite understood each other properly. As in some areas 
we agree that the functionality has to move inside KWin, maybe we are in fact 
talking about the same thing without realizing it.

I want to fix some of the problems we currently see and I see a solution for 
it. If there are other solutions which work quite well, I'm also happy. But 
just at the moment I don't see them. And I consider adding X atoms not a 
solution as it's hacky, I hate writing X code, it needs adjustment for Wayland 
and last but not least we cannot add any atoms as kdelibs is feature frozen. 
So no more WindowEffects till we all use KF 5.

At Akademy I expect to have done my first experiments on what KWin can do in 
future for Plasma which hopefully illustrates that moving at least more than 
what currently is done to KWin.

Oh and just for the record: moving the complete desktop shell inside KWin 
would violate the KWin mission statement I put up myself a few weeks before I 
wrote that mail. In fact I wrote it a day after I realized that we need to 
move Plasma into KWin. So whatever we do I would still see Plasma as an 
independet part just connected closer to KWin so that we can do more for it.

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