help

GatoLinux gatolinux at gmail.com
Sat May 5 15:42:56 UTC 2012


On 05/05/2012 06:00 AM, plasma-devel-request at kde.org wrote:
> Send Plasma-devel mailing list submissions to
> 	plasma-devel at 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-request at kde.org
>
> You can reach the person managing the list at
> 	plasma-devel-owner at 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" <aseigo at kde.org>
> To: plasma-devel at kde.org
> Subject: Re: Next Iteration Sprint, confirmed !
> Message-ID: <14384152.xU5P3aL2jI at 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.
>



More information about the Plasma-devel mailing list