Fwd: Re: [PATCH] fade out panel in desktopgrid

[Jud Craft]

To summarize as a lay person, nearly everyone believes that the
panel-desktopGrid interaction is inconsistent (and ineffective) under
a certain setting.

But one particular developer/user (and possibly others) still find one
of the cases (panel sticking around) useful when used under another
particular setting.

Personally, I'll be honest:  I like the idea of the panel disappearing
between effects.  The panel, like other plasma widgets, is part of
desktop, even if I link it to all desktops:  it's still a
desktop-phenomenon and not a construct that lives above the idea of a
"desktop".  Plus I think of virtual desktops as separate "screens",
and therefore to have a panel on the screen which is somehow
independent of the virtual screen is a little peculiar.  But some
people obviously think differently than myself.

The tasklist's setting for "show for all virtual desktops" is
inherently linked with the idea of "is a panel linked to a virtual
desktop or not?", right?  Aside from my personal preference just
stated, that is the real source of inconsistency.

It comes with the disconnect between "a panel" and a "a per-desktop
tasklist in a panel".  Having one disappear is good and consistent,
having the other disappear is probably good for the sake of
consistency, but for some reason some people do find it useful (not
myself, personally, but some here) to have a global-tasklist-panel
stick around during desktop effect sequences.

But rather than have a second option to "fade out panel during desktop
effects?" -- which is just more useless configuration and requires the
choice of an arbitrary default, why not just link it directly to a
per-desktop-tasklist-panel?

In other words:

1.  If a panel contains a tasklist that is global, then by default, it
sticks around during desktop effects.

2.  If a panel contains a non-global tasklist, it fades out during
desktop effects.

It's based on consistent logic, and the only downside is that it
tethers panel-fading to whether or not it contains a global tasklist.

But in the short term until you guys come up with a better solution,
it sounds like it solves the "should a panel stick around?"
inconsistency, as well as appease the "but I _want_ my global panel to
stick around!" people.  And it's consistent, and requires no extra
text or configuration option -- just a little extra logic.  (Assuming
it's fairly trivial to figure out that a panel contains a global
tasklist).

On 2/9/09, Sebastian Kügler <sebas at kde.org> wrote:
> On Monday 09 February 2009 21:24:30 Lubos Lunak wrote:
>> On Monday 09 of February 2009, Sebastian Kügler wrote:
>> > Just to clarify, the original problem was that the panel would be the
>> > same on all desktops (because it changes appearance when desktops are
>> > switched).
>>
>> ...
>>
>> > The whole patch is so simple and the issue so seemingly minor
>>
>>  Oh really? So, let's say we do the change and patch over the problem.
>> The 'DesktopGrid shows desktops incorrectly' bugreport however stays, only
>> now it will say 'the panel is not there'. And, of course, once people
>> finally get different-wallpaper-per-desktop, we get the original problem
>> back anyway, only for window type Desktop. Which, to use the same
>> solution,
>> we also patch away, at which point we may possibly scrap DesktopGrid and
>> start it over, since by that time it won't look much like a preview of all
>> desktops. Finally, if we get unlucky, we also get a bugreport about an
>> application set to be on-all-desktops that exhibits the same.
>>
>>  But of course the issues, just like the patch, are so simple and minor
>> that we are the bad guys just because we don't apply the patch blindly
>> without a thought right after asked. Thanks for treating us like some kind
>> of incompetent retards who can't even maintain their own application.
>
> It's minor compared to the number of bugs we fix usually and also compared
> to
> the severity of other problems that get fixed daily in both, KWin and
> Plasma.
>
> Whether the issue is valid (I don't care a lot, I think it's a minor bug) or
> the patch is a good or valid fix, I don't care a lot. It looked easy enough
> to
> whip up a patch in five minutes, which I did since I had touched the code
> before and knew how to do that.
>
> We had a session about kwin-plasma integration right before, and given the
> history of our collaboration (i.e. a very short one, as you note), I figured
> it'd be a good idea to start with an easy issue, and with a patch attached
> to
> create a comfy and productive atmosphere, and to show that we care.
>
> Which we do. All of us.
>
>> > that I'm very
>> > concerned about collaboration between Plasma and KWin. Long ago I wanted
>> > to have more interaction and integration between Plasma and KWin (and I
>> > even think it's critical for a good user experience). I'm not blaming
>> > anybody here, but it depresses me how badly that collaboration sucks
>> > right now, at least when done via mailinglist. I hope we can find some
>> > time to sit together at Akademy to sort out the most glaring issues
>> > preventing the KDE workspace becoming one user experience, but that's of
>> > course way too late for KDE 4.3, so we're looking at a timeframe of
>> > nearly a year before this would become visible, if at all possible.
>> >
>> > From a Plasma developer POV that loves KWin as well, and has even worked
>> > on it a bit, if an issue like this costs so much energy to tackle, I
>> > have
>> > little hope that for a better integration of those two components. It
>> > feels a bit like everything that's coming from the Plasma team is
>> > rejected by default and only accepted in very rare cases. That certainly
>> > makes me sad and is not in line with interaction in other parts of KDE.
>> > :-(
>>
>>  Carefully there. First of all, if this issue were brought up here by
>> anybody else, I think we'd have the same discussion, although probably
>> without the tiresome "we know usability and you don't" argument. Secondly,
>> it feels a bit like being offended here, since I cannot recall anything
>> from the Plasma team off the top of my head, and even a kwin at kde.org
>> search
>> for "plasma" doesn't bring up anything interesting for the last year. And,
>> if memory serves me well, we have accepted almost all (specifically) your
>> previous contributions.
>
> Oh, yes you did, and it was a pleasant experience getting direction from you
> and other KWin people, getting the TimeLine class right and in as well.
> Really, I felt (and feel) honoured that you took the time to get me on the
> right track, and proud that I was able to get my patch good enough for KWin.
>
> And please get me right, I'm not blaming you or anybody from the KWin team
> specifically. It only makes me sad how hard it seems to be for the two teams
> working together, especially since I kind of feel part of both teams. (This
> is
> also why I chose to chime in here, to zoom out and to try to think about how
> we can fix that. I cannot imagine it's that hard, but it seems to be.)
>
> So please, by all means don't feel offended, that's not what I tried to
> achieve, not even in the slightest. I want us to get over it and to
> KDE-style
> solve problems and create a better desktop.
>
> My (user-)head just doesn't wrap around the idea of window manager and
> desktop
> shell being separate components.
>
>>  I've already also thought about reserving a part of Akademy time for
>> talking to Plasma people, but if this is how you see us, then I suggest
>> you
>> start over before we get to that.
>
> It's not how I see you, but how I see *our* collaboration.
>
>> > We sat together here in Porto yesterday and though about what where we'd
>> > like to see more integration between KWin and Plasma. This thread makes
>> > me believe that it'll cost a lot of energy along with much frustration
>> > to
>> > actually get there -- and that while I know that all of us share the
>> > same
>> > goals and are actually very nice people.
>> >
>> > Can we all try a bit harder, please?
>>
>>  Yes. Your turn?
>
> Hugs :)
>
> So getting back to real issues, rather than whining about how bad the world
> around us is. Stuff that we've discussed is:
>
> - having access to pixmaps / composited windows from Plasma for example to
>   pimp the pager
>
> - shadows and non-rectangle shaped windows and their input masks (we took
> the
>   appearance of the Mac OSX dock as example)
>
> - Having panels on more than one and less than all virtual desktops (so one
>   desktop could for example be a mediacenter w/o the panel)
>
> - per desktop struts
>
> - common theming between Plasma and KWin elements
>
> - (slightly unrelated) using the windows key to open kickoff (vs. modifier
>   behaviour)
>
> Rich and Chani have a more detailed list, they'll post it shortly.
> --
> sebas
>
>  http://www.kde.org | http://vizZzion.org |  GPG Key ID: 9119 0EF9
>
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>