Next Iteration Sprint, confirmed !

[Aaron J. Seigo]

On Saturday, May 5, 2012 09:37:16 Martin Gräßlin wrote:
> On Friday 04 May 2012 23:02:16 Aaron J. Seigo wrote:
> > > * 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?

almost everything remains. window management is a rather small part of the 
shell, and it has grown smaller as we've relied more on compositor effects.

> > > * include running windows in search and launch
> > 
> > wrong. we have this now already.
> 
> with thumbnails supporting fluid movements?

in most cases this isn't needed; in the cases where it is, we've already found 
a solution which is to create effects that run in the window manager which are 
triggered and positioned from the shell.

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

well, yes, the implementation in kwin is not as rboust as it could be. this 
has nothing to do with the shell being more or less integrated into the wndow 
manager.

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

the implementation isn't perfect, no. the implementation is improvable, 
however, in ways that don't involve merging shell and window manager.

> I'm sorry that I have
> to disagree. Given that on multi screen a dashboard window is opened per
> screen doesn't help either.

what needs to happen is that the "desktop" window for each screen needs to be 
hooked into this window effect. with QML2 we'll lose the multiple-views-on-one-
scene so our hand will be forced there anyways. this resolves the new windows 
opened and this:

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

correct. "desktop". that sounds like sensible behaviour, no?

> Obviously the same is needed if Dashboard were in KWin with the difference
> that we can use Q_PROPERTIES.

exactly; so no real win.

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

the solution is not very complex, just boring to make. and even if we merge 
the shell and window manager, this would still be needed as long as any other 
application may want to have screen edge detection. krunner belongs in that 
category, but so do applications like the kde (and other) vnc viewers that use 
screen edge detection to show control areas.

for plasma active, if we ever do global gestures that include screen edges 
we'll probably need something similar to this as well.

> > > * same context menu for KWin and Tasks
> > 
> > see above.
> 
> no in that case there is a technical limitation:

then we need something other than libtaskmanager specifically; that doesn't 
equate to "merge the shell and 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.

if the issue is "X atoms" then lets find a solution for that.

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

as marco pointed out, not really, as it would be two GUI threads in some 
places. being able to have one process manage windows and another realize the 
content allows for additional fluidity.

> I think we need to talk about it in person - latest at Akademy. I am quite

sure, sounds great :)

-- 
Aaron J. Seigo
-------------- 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/20120507/f4c61d1d/attachment.sig>