Review Request: Add an hidden option to set a translucent background for DesktopView

Lucas Murray lmurray at undefinedfire.com
Tue Oct 6 03:51:12 CEST 2009 


> On 2009-10-01 19:24:19, Aaron Seigo wrote:
> > anything but the desktop shell painting the wallpaper is poor design. the window manager does not have enough knowledge of what is happening in the shell to do so properly. what, exactly, is the benefit of letting compiz draw the wallpaper? if it's simply visual bling, i'm really not interested in encouraging it by adapting plasma-desktop to such a broken idea.
> 
> wearenotalone wrote:
>     Thanks for your feedback!
>     
>     My intention was on the one hand to enhance the user experience for power users and on the other hand to increase (respectively restore) the compatibility with other applications like compiz. The user should have the right and the freedom to decide for themselves. With this patch, the user is able to use the wallpaper plugin of Compiz, if he really wants to. Any other user does not have to deal with this option (because hidden), due to the default setting "false" this may not cause any disadvantages / speed penalties for him.
>     
>     I use Compiz with multiple viewports; using the wallpaper plugin, I can easily distinguish between different viewports. In addition, KDE4 looks really great in cooperation with Compiz. To develop a proper mapping between the viewports of Compiz and the desktop / activities of plasma, I simply lack the experience. I did not want to wait until someone else does this, instead i wanted to tackle the problem by myself. My goal was to fix the regression in 4.3.1 compared to 4.2 with minimal impact on existing code. Primary goal was to change the existing design, behavior and code as little as possible. I also tried to stick as accurately as possible to the naming scheme and the coding style of the original authors.
>     
>     I hope that you can understand my arguments and allow us to use Compiz and KDE 4 together again.
>     
>     Yours sincerely,
>     WANA
>     p.s. The corrected patch will follow later.
> 
> Aaron Seigo wrote:
>     "The user should have the right and the freedom to decide for themselves"
>     
>     they do. they have the code. config options in software does not equate in any direct manner to rights or freedoms.
>     
>     "Any other user does not have to deal with this option"
>     
>     the developers deal with maintaining it, any bug reports that result from it and users pay for that overhead indirectly. there is no such thing as a patch that adds a feature that does no harm; the negative of more feature weight must be offset by benefit. in this case, it also goes against some design fundamentals.
>     
>     it is therefore my decision that this patch which introduces a purpose-specific hidden config option is not desirable to the upstream project.
>     
>     "My goal was to fix the regression in 4.3.1 compared to 4.2 with minimal impact on existing code."
>     
>     it was coincidental that this worked in 4.2; it was not an intentional feature.
>     
>     "Primary goal was to change the existing design, behavior and code as little as possible. I also tried to stick as accurately as possible to the naming scheme and the coding style of the original authors."
>     
>     i do appreciate that.
>     
>     as Sebas noted on the mailing list, this really ought to be a property of the wallpaper that the View can check. this would mean some new property in Plasma::Wallpaper and a way to signal that it has changed so the view can react if it wishes to. how to do that cleanly is the question. i don't think Wallpaper should have something specific to this, but perhaps some sort of properties system that can be set/changed by the Wallpaper (allowing us to add things over time and keep the API straightforward from the start).
> 
> wearenotalone wrote:
>     That sounds reasonable, but it is far too difficult for me. I will continue to manually patch the Debian packages. If someone wants to use 4.3.1 with the wallpaper plugin, he will find all necessary information in the the bug report. I will now discard this review request, ok?
>
> 
> Nathanael Schilling wrote:
>     "they do. they have the code. config options in software does not equate in any direct manner to rights or freedoms."
>     
>     In my opinion, designing something around the code, i.e. setting all configurations in the source code is a design flaw as well. Sure people are free to modify the code, but that doesn't mean they can (permissions wise) or have the technical knowledge to.  I realize that kde likes to work with itself and that the plasma devs therefore would design plasma around kwin. As plasma is a desktop shell but not a window manager, it would be expected that it is possible to use other window managers/compositors together with plasma, and that plasma would give control to this other compositor/window manager to the furthest extent possible to allow for smooth interoperability. It should be noted that compiz has tried to integrate with kde and plasma.  Due to popularity of compiz as a window manager and its relatively large user base and the features that KDE has compared to gnome, it is to be expected that there are users who want to both user compiz *and* kde well together without loosing any of the features of compiz. This could be due to the fact that kwin is much slower on some hardware compared to compiz. Therefore I would think it would make sense to include the patch with as much documentation as possible to make it easy to enable/disable in the actual source code to make maintaing the code as easy as possible. I don't quite understand what you mean with "overhead", but options that are configurable usually have very little overhead, or neglible overhead. Furthermore, one of the strengths of kde is it's configurability, and it would be a shame if this feature were lost. Lastly, http://forum.compiz-fusion.org/showthread.php?t=7519 suggests that this feature was once intentional, though this might have changed.
>     
>     Therefore I propose keeping the configurability as an option, but not to have it as an "official" feature to make it possible for developers to discard it if it causes any problems.
>     
>     Regards, Nathanael Schilling
>     
>     @werenotalone: Does patching the Debian packages affect the ubuntu packages too? i.e. will I be able to use transparent plasma backgrounds in the next ubuntu?
> 
> wearenotalone wrote:
>     There is some misunderstanding; i do not patch the official debian packages, but rather build my own packages from the official ones. Its not likely that the debian maintainers will accept this patch if it was not accepted upstream. Sorry for the ambiguity.
> 
> Martin Gräßlin wrote:
>     > As plasma is a desktop shell but not a window manager, it would be expected that it is possible to use other window managers/compositors together with plasma, and that plasma would give control to this other compositor/window manager to the furthest extent possible to allow for smooth interoperability
>     As a KWin developer I just want to add that painting the desktop is not the task of a window manager. If compiz decides to do that, it's fine, but I think it's a bug in Compiz. The NETWM spec does not state that a window manager should draw the background. All integration between KWin and Plasma is done in a way that Compiz or any other window manager could easily support this feature (and part of the integration is already implemented by Compiz).
>     
>     That cannot be said for this Compiz "feature". It looks like Plasma has no chance to test if the window manager has set a wallpaper. And I think it is wrong to add workarounds for other window managers to Plasma. It just makes the code ugly. The right way to go is to extend the NETWM specification and I doubt this topic would get accepted in the spec ;-)

@Aaron and Martin:

You fail to realise that there are times that the "wallpaper" NEEDS to be rendered by the compositor, Compiz has one of these situations therefore it is right in rendering it itself. Notice I said "compositor" and not "window manager" there.

If you want the background of your workspace to be completely integrated into virtual desktops or viewports no matter how hard you try rendering it by anything other than the workspace compositor will end up being ugly--either code-wise or graphically.

Take for example a deep space background that has parallax as you switch virtual desktop or zoom around. There is just no way to do that by an external client as when the compositor does effects like desktop grid the background will be distorted due to lack of parallax (The wallpaper window is simply scaled, not rerendered with the new camera position). The compositor also cannot just render the background on top of all desktop-level windows as then it would prevent the user from interacting with any widgets on the desktop. The only way to do it is to make the background of the desktop window transparent--exactly what this patch provides.

As for being an "ugly hidden setting" or "requires EWMH changes": Guess how the Plasma netbook shell interacts with KWin? Exactly what is happening in this patch just reversed! I don't see it nessecary to add any workspace-agnostic activation triggers to this code (Such as that through EWMH) but adding a D-Bus call to Plasma would allow the compositor to activate it only when required.


- Lucas


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1755/#review2515
-----------------------------------------------------------


On 2009-10-01 18:07:49, wearenotalone wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/1755/
> -----------------------------------------------------------
> 
> (Updated 2009-10-01 18:07:49)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> -------
> 
> Since revision 928340 (http://websvn.kde.org/?view=revision&revision=928340 ) its no longer possible to set a translucent background. Because of this you cannot use the wallpaper plugin of compiz fusion any longer with kde 4. For more information please see this bugreport: https://bugs.kde.org/show_bug.cgi?id=199869
> 
> This patch adds an hidden option named "translucentBackground" (because of Qt::WA_TranslucentBackground) in ~/.kde/share/config/plasma-desktoprc (example):
> 
> ...
> [PlasmaViews][34]
> DashboardContainment=0
> translucentBackground=true
> ...
> 
> The default value of translucentBackground is false, because this is the default behavior at the moment. I also created a patch against the kdebase-workspace-4.3.1 source package of Debian Squeeze, which works fine for me and can be found here: https://bugs.kde.org/show_bug.cgi?id=199869#c10
> 
> Best Regards,
> WANA
> 
> 
> Diffs
> -----
> 
>   /trunk/KDE/kdebase/workspace/plasma/desktop/shell/desktopview.h 1027876 
>   /trunk/KDE/kdebase/workspace/plasma/desktop/shell/desktopview.cpp 1027876 
> 
> Diff: http://reviewboard.kde.org/r/1755/diff
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> wearenotalone
> 
>

More information about the Plasma-devel mailing list