unity-design team mailing list archive

[Sam Spilsbury <smspillaz@xxxxxxxxx>]

On Sat, May 15, 2010 at 9:59 PM, Dylan McCall <dylanmccall@xxxxxxxxx> wrote:
> On Fri, 2010-05-14 at 21:05 +0530, Akshat Jain wrote:
>> Link Copy-Pasta
>> http://blog.martin-graesslin.com/blog/2010/05/why-you-should-not-use-client-side-window-decorations/
>> http://blog.martin-graesslin.com/blog/2010/05/follow-up-on-client-side-decorations/
>>
>> This guy named Martin Gräßlin is a hardcore KWin fan I think,looks
>> like if he were a senior GNOME developer he would have replaced
>> Metacity with KWin.Lol
>>
>> Design Team-?
>> _______________________________________________
>> Mailing list: https://launchpad.net/~ayatana
>> Post to     : ayatana@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~ayatana
>> More help   : https://help.launchpad.net/ListHelp
>
>
> I was really looking forward to client-side decorations, but Martin has
> pretty thoroughly changed my tune. I think there's a different problem
> that needs to be solved: there is a doomed effort right now to make
> window decorations feel like part of window clients even though the two
> know nothing of each other. For example, window decorations are fixed to
> the edges of the client area no matter what, as if they need to be. In
> some themes (like Lucid's Light themes) they apply some quirky tricks to
> blend with the client area.
>
> Perhaps more problems can be solved if window borders Stop Intruding on
> window clients.
>
> A few loosely related thoughts spring to mind:
>
>      * It would be really super if someone would implement unobtrusive
>        window manager controls that appear (with lots of alpha channel
>        goodness) when the mouse reaches particular hotspots at the edge
>        of the client area, maybe after being inside the client area.
>        That would lead to a valid solution to Bug #160311
>        (https://launchpad.net/bugs/160311), among other things, and
>        it's a requirement for client-side decorations to work at all
>        well.

So the window controls are essentially invisible unless you play a
hide an seek game with your mouse? I don't understand why you'd want
this - and it requires some form of meaningful acceleration within
apps, something that I don't think everyone has.

>      * Why does a title bar have to be at the top of its respective
>        window? This causes a serious usability problem when a window is
>        Alt+Dragged above the screen: only the bottom part is visible,
>        so it's impossible to drag it back unless you know how it got
>        there. I actually am quite surprised this isn't a common issue.
>        Why can't the title bar detach from the window and stay visible
>        regardless of where the client has gone?

You can do this with reparenting decorations, or even decorations
which draw separately as a texture on screen (like what you already
have with compiz!). You cannot do this with client side decorations.
Some window managers may reparent the window and not draw decorations
for it. This means that the window can never reliably tell it's
position.

>      * A window “title bar”, with goodies like the Close and Minimize
>        buttons (and soon, I guess, Windicators!), serves a distinct
>        role: it helps the user organize a window client quickly and
>        easily. These are proxies; helpers; tools. I think “title bar”
>        is a misnomer.
>      * A window client, in the Linux desktop, cannot trust the window
>        manager to do anything. As a result, we have a unique
>        arrangement where window decorations rarely introduce new
>        functionality that can't be achieved through the client. (Beyond
>        managing windows themselves, of course. The client can't be
>        reliably dragged to move it around. Now THERE is something that
>        could be patched in all the toolkits. If we want touch support,
>        it's a necessity).

The window manager absolutely depends on the client to not be stupid
and to obey rules (unless you want to make every client
_NET_WM_OVERRIDE_REDIRECT). If a client can't be dragged to move it
around, it is because the window manager strictly forbids this, and if
a window manager strictly forbids this, it is because the user told it
to. You should never override window management rules in the window
manager.

As for window decorations adding new functionality, as Martin and I
have already said, you can use DBus to specify what indicators there
should be, and the window manager will implement it meaningfully. If
you're talking about new functionality to /manage/ the window, then
again, putting that in the client is a big no-no, see point #2.

>      * Items in the window list mimic window title bars. (Title, icon -
>        that's how they typically look!). Windicators could fit in there
>        really neatly. We're moving to a world where the window manager
>        handles more of the surrounding desktop (eg: gnome-shell), so
>        these things could get cool.

If you're moving to a world where global contexts are the norm, then
why not just put windicators there? I don't understand this design
inconsistency where we are putting some things global and some things
local.

Then again, putting windicators global is probably just going to
result in each indicator being duplicated on the panel, so you'll have
two sound menus (local and global). Or maybe you could just drop the
whole "windicators" thing and put all your indicators in
indicator-applet with application specific menus tied into the global
ones.
>
>
>
> Thanks,
> Dylan
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~ayatana
> Post to     : ayatana@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ayatana
> More help   : https://help.launchpad.net/ListHelp
>



-- 
Sam Spilsbury