From kde-panel-devel Thu Apr 26 12:52:55 2012 From: Martin =?ISO-8859-1?Q?Gr=E4=DFlin?= Date: Thu, 26 Apr 2012 12:52:55 +0000 To: kde-panel-devel Subject: Re: Re: Next Iteration Sprint, confirmed ! Message-Id: <4530261.hcTRiySFOe () martin-desktop> X-MARC-Message: https://marc.info/?l=kde-panel-devel&m=133544492321970 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============5916091429682252691==" --===============5916091429682252691== Content-Type: multipart/signed; boundary="nextPart1456479.IDVBlziIRI"; micalg="pgp-sha1"; protocol="application/pgp-signature" Content-Transfer-Encoding: quoted-printable --nextPart1456479.IDVBlziIRI Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Thursday 26 April 2012 12:41:32 Aaron J. Seigo wrote: > On Monday, April 23, 2012 17:42:42 Martin Gr=C3=A4=C3=9Flin wrote: > > My expectation from the sprint is that we will figure out a new > > interaction > > of the shell and windowing system which is not possible at the mome= nt. We > > have pretty much reached what's possible with Plasma tells KWin wha= t to > > do. > > But turning it around (Plasma becomes a plugin to KWin) will give u= s > > complete new possibilities which I will start to explore as soon as= we are > > in feature freeze. >=20 > i am currently very, very sceptical about this approach. this is beca= use it > is a set of statements with no foundation. >=20 > * what would be the potential improvements? > * what are the realistic improvements? > * why can't it be done with the current way it is done? > * why is a whole new shell needed at all? > * do we really want to weld everything together? (this is not zero co= st) > * and most importantly: why will the user care? > =09* what is our end goal / motivation? Your questions are very valid and important. And I will try to provide = some=20 reasoning for it. If we look around we see that both GNOME Shell and Unity went for an ap= proach=20 to integrate the desktop shell into the compositor and did not follow K= DE's=20 working approach. At the time when we introduced Plasma we were the onl= y=20 Desktop Shell being able at all to integrate Compositor and Desktop She= ll, so=20 why did they invent a new wheel instead of following our approach? I evaluated that question and came to the conclusion that if we would s= tart=20 all over today we would do the same. Something like GNOME Shell could n= ot be=20 implemented with our current solution. I give now some examples of things which are just not possible with Pla= sma and=20 KWin being two different applications. Please note that I consider thos= e as=20 examples and not as something I propose to do. * combine present windows with application launching (e.g. SAL, Kickoff= or=20 KRunner) * include running windows in search and launch * Tasks Applets showing live thumbnails instead of icons * Include window/desktop thumbnails in QML (showstopper for tooltips) * Include thumbnails of running windows in an application launcher and = still=20 having smooth scrolling We also see that our current solution has rough edges which we could no= t solve=20 yet: * Panel tooltips movement not really synchronized/smooth * No crossfading between thumbnail tooltips when going from one item to= =20 another * Inability to identify windows of the desktop shell to give them speci= al=20 treatment * Dashboard conflicting with window management * Conflicting screen edges for auto-hiding panels * same context menu for KWin and Tasks Many of those issues seem to not exist on competitve (proprietary) plat= forms=20 and it makes me really sad seeing our competitors having better solutio= ns in=20 that area given that our technology and our features are all there and = in fact=20 much better. At the same time we know from many projects we have worked on that the = current=20 solution is just hackish and does not scale. Just remember the window s= trip in=20 PA 1/2. A complete nasty hack, which was extremely slow. This was solve= d by=20 bringing Plasma technology into KWin: QML, Plasma Components and Plasma= =20 Packages. Our current solution to KWin/Plasma integration is adding more X atoms.= Sorry=20 but I don't want to see any more X atoms passed around. It's an extreme= ly=20 hacky and ugly solution requiring the synchronisation of three processe= s=20 compared to having the same with QML in just one. >=20 > anytime i see "a new shell" i get shivers running up and down all the= wrong > places of my body. >=20 > i've yet to see the above laid out cleanly and until that happens, th= ere's > no way to make a good decision. if we simply state the result before = the > reasons are well understood then we may as well bring out the roulett= e > table, spin it and let it decide what we do next. :) You are of course right with that and that's nothing I want to do. I wa= s just=20 afraid that we are in our thinking of what is possible and what not whi= ch=20 would limit our ideas. If we would not even think about possibilities l= ike=20 what GNOME Shell is doing with the dash just because we think it's not=20= possible, it could end up quite bad. That's why I just mentioned that I see a huge potential if we step asid= e from=20 what we have, open our mind (even if it results in a shivering Aaron ;-= ) and=20 start thinking and dreaming. I am sure that we can find technical solut= ions to=20 quite some of our current problems if we open up our mind. That's why I also think it is important to open up to new contributors = who=20 could bring in a lot of manpower which is currently lacking in Plasma. = If I=20 see correctly there is a large amount of sponsored developers coming to= the=20 sprint. Which makes me quite happy :-) Cheers Martin --nextPart1456479.IDVBlziIRI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEABECAAYFAk+ZRScACgkQqVXwidMiVrrXBQCgmO4/dkP0DI40JQsFfKjDXhrv G/gAniCTPS2Si/GMel8qhnETJs6jWnUI =J567 -----END PGP SIGNATURE----- --nextPart1456479.IDVBlziIRI-- --===============5916091429682252691== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel --===============5916091429682252691==--