On 05/05/2012 06:00 AM, plasma-devel-requ...@kde.org wrote: > Send Plasma-devel mailing list submissions to > plasma-devel@kde.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.kde.org/mailman/listinfo/plasma-devel > or, via email, send a message with subject or body 'help' to > plasma-devel-requ...@kde.org > > You can reach the person managing the list at > plasma-devel-ow...@kde.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Plasma-devel digest..." > > > Today's Topics: > > 1. Re: Next Iteration Sprint, confirmed ! (Aaron J. Seigo) > 2. Re: declarative plasmoids and services (Aaron J. Seigo) > 3. Re: Re: Next Iteration Sprint, confirmed ! (Martin Gr??lin) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 04 May 2012 23:02:16 +0200 > From: "Aaron J. Seigo" <ase...@kde.org> > To: plasma-devel@kde.org > Subject: Re: Next Iteration Sprint, confirmed ! > Message-ID: <14384152.xU5P3aL2jI@freedom> > Content-Type: text/plain; charset="iso-8859-1" > > 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. >
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
