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

[Aaron J. Seigo]

On October 5, 2009, Nathanael Schilling wrote:
> > 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?
> 
> "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.

you misunderstand. the design as i am putting it down does not include this 
configuration option. others are free to disagree and change the source code 
to their desire. it has nothing to do with designing something around the 
code.

>  Sure people
>  are free to modify the code, but that doesn't mean they can (permissions
>  wise) or have the technical knowledge to. 

which isn't our problem. it is 100% INSANE to suggest that all things should 
be configurable in all ways. if that is indeed the design requirement on F/OSS 
then let me be the first to congratulate the rest of you on your continued and 
guaranteed failure and leave the arena right now.

if that isn't the case, then some things will not be configurable. and here we 
have one of them.

i have, btw, offered in the comments on this patch, an alternate way to 
explore implementing this exact feature that could mesh much better with the 
existing design and, as an added bonus, let you modify it using the existing 
GUI.

but it's easier to write long emails and hope we'll just apply the existing 
patch.

>  I realize that kde likes to
>  work with itself and that the plasma devs therefore would design plasma
>  around kwin. 

we work with kwin. we don't design around it. we work well with other KDE 
projects, but we also work extensively with others. so i don't agree with this 
characterization.

>  As plasma is a desktop shell but not a window manager, it
>  would be expected that it is possible to use other window

and the window managers are not desktop shells. they can stay out of the 
wallpaper.

>  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.

we've actually given a lot more control to the compmgr in the 4.4. codebase by 
using desktop effects directly for things we were previously doing manually in 
plasma-desktop.

at the same time, the window manager does not get to define unilaterally what 
feature goes where. essentially you are suggesting that the window managers 
drive design and the desktop shell submit to those decisions. not exactly a 
fair or equal partnership, is it?

in this case, while i understand why compiz provides wallpapers, it is a 
mistake to try and combine those with a desktop shell. the window manager has 
no idea, and can not be reasonably expected to have an idea, of where / when 
the wallpaper should be painted.

the days of "the wallpaper is what fills the screen" are behind us.

>  It should be noted that
>  compiz has tried to integrate with kde and plasma. 

and vice versa. it would be awesome, btw, if compiz implemented support for 
some of the window manager effects plasma-desktop is using such as the window 
slide in-out plasma-desktop in KDE 4.4 will be using for all of its panel 
animations, etc.

>  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. 

any particular window manager team's decisions as to what makes for sane 
features may not line up with our design concepts. ensuring plasma-desktop 
works with every feature in every (even just popular) window manager would be 
essentially putting plasma-desktop's design in the hands of other development 
teams who are working on window managers.

we do cooperate (e.g. we accommodate both window managers who use virtual 
desktops as well as those who use viewports; that was done, actually, 
specifically for compiz users), but we aren't beholden.

>  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.

we'll just have to disagree here then.

>  I don't quite understand what
>  you mean with "overhead"

in this case the overhead comes in testing and maintenance. every single 
feature adds to the complexity of the code. one of my duties as maintainer is 
to ensure that doesn't get out of hand.

>  Furthermore, one of the
>  strengths of kde is it's configurability, and it would be a shame if this
>  feature were lost.

plasma is highly configurable, in most ways more so than kicker/kdesktop in 
KDE3. one can not defining it as "not configurable" if one aspect of plasma 
that you would like to configure is not configurable. it's a rhetorical game i 
won't play :)

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20091005/03e5ebed/attachment.sig