Next Iteration Sprint, confirmed !

Aaron J. Seigo aseigo at kde.org
Fri May 4 21:02:16 UTC 2012


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

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.

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

> * include running windows in search and launch

wrong. we have this now already.

> * Tasks Applets showing live thumbnails instead of icons

can you describe, then, how we do this magically now in the tooltips? ;)

> * Include window/desktop thumbnails in QML (showstopper for tooltips)

easy.

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

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

> * Dashboard conflicting with window management

see above. if this persists, it is a fault with kwin.

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

> * same context menu for KWin and Tasks

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

or do you one want one plugin which is plasma-device, and another which is 
plasma-desktop, and another which is . .meh. 

i agree that the window manager and the shell should cooperate tightly. that 
does not mean merging them.

-- 
Aaron 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/20120504/6098698d/attachment.sig>


More information about the Plasma-devel mailing list