Looks like we KDE people are not used to cross-posting. It would probably make sense to keep discussions on only one list (the one from which something is wanted).
On Monday 09 of February 2009, Richard Moore wrote: > Plasma and KWin Integration > =========================== > > This is the results of the discussion on the areas we (the plasma team) > feel we need help from the kwin team to produce better integration. It's a > mixture of issues from fairly trivial ones, through complex ones, to those > that come down to issues with specifications like NETWM. The aim is to > provide users with the best possible experience running a pure-KDE desktop. First of all, I'd like to point out that the KWin team is rather small and busy (I personally have had only limited amount of time for KWin the last half a year and I don't see it changing soon). Therefore I'm afraid some of the solutions for you will be "this is how it should be done, send a patch or wait". > 1. Ability to obtain pixmaps of windows. > > There are a number of effects that would be possible within plasma and > other applications if it was possible to obtain a full pixmap of a window > (even if it is obscured). This information is available to kwin and used > for compositing, the idea would be to publish it for use by other > applications. What would they use it for and why is the approach used by taskbar thumbnails not good enough? Theoretically this should be simple and Plasma could handle it itself using the XComposite extension. Any window can be redirected to a pixmap using XCompositeRedirectWindow() with CompositeRedirectAutomatic (which means it wouldn't depend on a compositing manager in any way). In practice KWin has a better overview and can provide such functionality as pixmaps for minimized windows, but sharing X pixmaps between processes can be a tricky business. Unless you want obscure or complicated stuff just asking KWin would be IMHO the easiest. See also next item. > 2. Better thumbnail scaling. > > The scaling algorithm used by kwin to create the window thumbnails seems to > produce pretty poor results, comparing the results with Qt's smooth scale > for example. Looking at the code, they appear to be using a codepath that > generically supports all the transformations used in effects. Could we get > better results by having a codepath that is specifically designed for > scaling? We could possibly make the code use a better algorithm for the thumbnails, but only what OpenGL/Xrender give us. The pixmap is never converted to QImage as that could have huge performance impact, so no chance to get Qt's scaling. Which also means that if you wanted to get the thumbnail yourself using XComposite, you'd have the additional problem of possibly slow XRender scaling or other problems that KWin needs to handle when it paints the pixmaps. > 3. Ability to have windows on a specific set of virtual desktops. > > Being able to say a window is on desktop 1 and 3 for example. This one > isn't a big deal, just a 'nice to have'. Would need a spec change, but otherwise not very hard, just probably tedious to check the change doesn't break code somewhere. If somebody wants to give this a try, just ask for details. This BTW has nothing to do with Plasma, right? > 4. Per-desktop struts. > > At the moment struts apply to all desktops, which doesn't make sense if > (for example) you have different panel configurations on different > desktops. It could also be an issue if a particular desktop was a > full-screen media center, though in this latter case it can be worked > around. No, struts apply only to their windows, and therefore only to the desktop where the window is. If I force the panel to be only on desktop 1, the maximize area changes on desktop switches. Maybe you've found a bug somewhere, but in general this works. > 5. Shadows of shaped windows. > > At the moment the shadows of shaped windows don't really work, could we > have something like a separate shadow mask? Nothing more to add to that Lucas has already said. > 6. Marco created a patch that added a shadow to the plasma panel, and > whilst kwin handled the strut correctly in some cases, it did not in > others. For example, the magnetic window borders stuck to the shadow rather > than to the edge of the panel. This is expected. Magnetic borders snap to the window, and since the shadow is faked inside the window, it snaps to it. You should not be faking shadows yourselves unless 5. above proves impossible, and even then the hack should be rather helping KWin to do the shadow properly. And this has nothing to do with struts. A strut is reserving an area at a screen edge so that e.g. maximized windows don't cover it. > 7. Theming of kwin dialogs to match the rest of the desktop furniture. > > Things like the window menu are part of the desktop rather than part of > applications and it would be great if they were coloured like the other > pieces of furniture rather than like the applications they manage. The same > thing applies to a number of other things drawn by kwin such as in the box > switch effect. Just as Lucas, I don't see what you mean with window menu here, but for the rest I don't see a problem with adding that, assuming - it's technically feasible - I don't know technical details, but IIRC it uses threads, the idea of which in KWin makes me a bit uneasy - there's a way to get the old style back - a Plasma theme, let's call it "Classic", that would just make things look like they use normal widgets and not Plasma's special theming should do > 8. Document modal windows. > > Having a way to handle document-modal windows along the lines of the Sheets > in MacOS. These would be positioned over their parent window and move with > the parent. This is not Plasma related again, is it? This has been already discussed somewhen in the past, and there is http://bugs.kde.org/show_bug.cgi?id=152945 as a result. But I currently don't have the time and I don't know how difficult this would be for somebody else to handle it. > 9. Hide the panel when zooming out to show the containments. > > As discussed already by Sebas, and patch provided. Containments? I assume you mean the recent issue with panels and the DesktopGrid effect here? > 10. Alt-Tab to desktop and panel > > The desktop and panel need to be able to get the keyboard focus to allow > users without keyboards to activate and use them. This has also already been discussed, with Aaron and Chani IIRC, and I think I said that it's just adding new shortcuts and adding new mode in kwin/tabbox.cpp that would consider only isDock() and isDesktop() windows. -- Lubos Lunak KDE developer -------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: l.lu...@suse.cz , l.lu...@kde.org Lihovarska 1060/12 tel: +420 284 028 972 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel