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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
