unity-design team mailing list archive

[Tyler Brainerd <tylerbrainerd@xxxxxxxxx>]

Heres a mockup of a number of things, primarily how the title bar could
better work in a similar fashion as the panel and how it could stay visible.

A. The window title bars echo whats going on in the top panel. On the left
we have management, launching and closing windows. On the far right, we have
(App Info) and Window, which correlate to the user name and specific info
(im status and time in the panel, specific app info like inbox messages,
name of the document, etc) Next from the right are panel indicators, like
volume and sync status. Lastly, I made the window tabbed, because thats just
awesome.

The window on the left and right are the same, but the one on the right has
been moved, but no resized, against the panel. Thus, it got squished down
some and a scrollbar shows up. The title bar is never lost, so neither are
the windicators or window controls.

NOTE: I didn't add any app menus.

Second NOTE: The window tabs could easily be implemented on the panel, so
that Tabbed Windows mean multiple of the same program (like tabbed Nautilus)
while tabs on the panel represent actual different applications, or even
workspaces if you want to get crazy. Less important to the current
discussion, but still a thought.




[image: 2010-05-15-152609.jpg]

On Sat, May 15, 2010 at 3:16 PM, Tyler Brainerd <tylerbrainerd@xxxxxxxxx>wrote:

> " 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?"
>
> Especially considering we already have 'rolling windows' available, is
> there way a way to allow windows to partially roll when the title bar is
> forced to the top of the screen and continued to move upwards?
>
>
> On Sat, May 15, 2010 at 2: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.
>>      * 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?
>>      * 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).
>>      * 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.
>>
>>
>>
>> Thanks,
>> Dylan
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~ayatana
>> Post to     : ayatana@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~ayatana
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>