Re: [Ayatana] dialog sheet suggestions

[Thorsten Wilms]

On 05/18/2011 02:32 AM, Felix Lawrence wrote:


http://www.omgubuntu.co.uk/2011/05/os-xgnome-3-style-dialog-sheets-coming-to-ubuntu-11-10/



Firstly, Ubuntu's dialog sheets should be draggable inside their
parent window.  The sheet could even be dragged to be mostly outside
the parent window, with only a small region of overlap.  The sheet
would not be able to be dragged completely outside the parent window
- it must at least partially overlap its parent at all times.  This
allows the user to see/select any text in the parent window, while
the sheet is still 'stuck' to the parent window.


The only sane reason I see for wanting to move the sheet is to get a 
better view of the application window (usually the content area, 
specifically). That desire should only come up if you need a second look 
to decide on something to be carried out via the dialog.


But why obstruct the content area in the first place? A movable sheet 
would be better than a fixed one, but it adds to the window management 
hassle. These thoughts led me to create the following mockups (in 2007, 
explaining that brutal GNOME look):

http://thorwil.files.wordpress.com/2007/05/save_changes_01_i.png
http://thorwil.files.wordpress.com/2007/05/save_changes_02_i.png

The window should be resized to make room for the embedded dialog. If 
the window already fills the screen, the content area would have to 
shrink (and zoom out). After being told the resizing would be too hard 
to make happen, I made:

http://thorwil.files.wordpress.com/2007/05/save_changes_03_i.png


BTW, I think dialogs should not have window close buttons, because it is 
not obvious if those are equal to Cancel or not. Also, providing several 
means of doing the same thing can slow users down because of requiring a 
decision.


One could even consider to style the bottom area of a dialog like a 
title bar, as the most common commands there will Close the window.



--
Thorsten Wilms

thorwil's design for free software:
http://thorwil.wordpress.com/

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

[Ayatana] Global menu in Oneiric Ocelot (11.10)

[Niklas Rosenqvist]

Hi!
I as many have questioned the global menu bar which Unity features. I
believe there are several issues with it as it is today and I will air my
thoughts here.

Many has complained on that it is incredibly frustrating to be working with
on larger monitors. If the active window is in the bottom right corner and
you have the menu at the top (which isn't even visible until you hover it)
it makes no sense what so ever to look for it up there and it's really
ineffective. Consider the following:

2011/5/18 Ralph Green 
 > The global menu bar
 > is another matter. It must die. If there is one feature that will
 > drive me away from Unity, this is it. Again, there is no benefit,
 > except on really small screens. And, now, I don't even see the menu
 > until I move the mouse to the upper left hand corner of the screen.
 > That is often a long way from where my program is. This really take a
 > lot longer to operate. I don't understand how anyone could like it.
 > I am not saying they are wrong to like it. I just don't understand
 > how such a crazy thing was adopted. You know this feature was put on
 > the Macs because they had such tiny screens at the time(512 by 384
 > pixels). I have seen Mac people discuss why it is a bad idea in the
 > days of large screens and it only stays because of inertia. And Steve
 > Jobs obsession with simplicity over usability., to be sure.

Though I think that there has been proposed a really good solution to this:

On Mon, May 9, 2011 at 7:10 PM, GonzO Rodrigue  wrote:
 > [...] B) only appeared in the
 > "panel" space when the app is maximized. Leaving it in the window space
 > makes more sense when not maximized [...]

This way the menu wouldn't be taking up space when the application is
maximized and it would still leave the menu implementation up the developers
to design freely as they want. With this design firefox 4 could have it's
menu button instead of splitting it into a menu to work with the global menu
bar and developers doesn't have to make their programs compatible with the
global menu since it would just melt together the program's title bar with
the panel.

This makes much more sense than today's implementation and it would offer
more effective work flow when you don't have to move across the entire
screen.

There are also more situations where the global menu works like a crippled
narwhal. E.g. when working with programs as GIMP. GIMP has one main
application window and several smaller windows with tools and such and if
you have one of the smaller windows active you can't reach the menu, even if
they are a part of the same application. You must target the main window and
then you can reach the menu.

So what are your thoughts? If anyone already knows how it will be
implemented in 11.10 (maybe from a discussion at UDS) please share your
knowledge!
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Global menu in Oneiric Ocelot (11.10)

[Henrik Peytz]

I've been begging for this particular change too.

It makes more sense since vertical space is only an issue when you want it
(ie. when you maximize windows), so un-maximized windows have no use for the
global menu since, if they're un-maximized, they don't need the extra
vertical space to render properly.

Also, I think it's a bit of a stretch to expect application-devs to make
their applications global-menu compatible. I can see how maximized windows
getting stripped of their titlebar is relatively easy to implement in Unity
without requiring dev's to change their apps (if maximized, then...), but
making the standalone windows behave in this way must require some change in
the application itself.

2011/5/18 Niklas Rosenqvist 

> Hi!
> I as many have questioned the global menu bar which Unity features. I
> believe there are several issues with it as it is today and I will air my
> thoughts here.
>
> Many has complained on that it is incredibly frustrating to be working with
> on larger monitors. If the active window is in the bottom right corner and
> you have the menu at the top (which isn't even visible until you hover it)
> it makes no sense what so ever to look for it up there and it's really
> ineffective. Consider the following:
>
> 2011/5/18 Ralph Green 
>  > The global menu bar
>  > is another matter. It must die. If there is one feature that will
>  > drive me away from Unity, this is it. Again, there is no benefit,
>  > except on really small screens. And, now, I don't even see the menu
>  > until I move the mouse to the upper left hand corner of the screen.
>  > That is often a long way from where my program is. This really take a
>  > lot longer to operate. I don't understand how anyone could like it.
>  > I am not saying they are wrong to like it. I just don't understand
>  > how such a crazy thing was adopted. You know this feature was put on
>  > the Macs because they had such tiny screens at the time(512 by 384
>  > pixels). I have seen Mac people discuss why it is a bad idea in the
>  > days of large screens and it only stays because of inertia. And Steve
>  > Jobs obsession with simplicity over usability., to be sure.
>
> Though I think that there has been proposed a really good solution to this:
>
> On Mon, May 9, 2011 at 7:10 PM, GonzO Rodrigue 
> wrote:
>  > [...] B) only appeared in the
>  > "panel" space when the app is maximized. Leaving it in the window space
>  > makes more sense when not maximized [...]
>
> This way the menu wouldn't be taking up space when the application is
> maximized and it would still leave the menu implementation up the developers
> to design freely as they want. With this design firefox 4 could have it's
> menu button instead of splitting it into a menu to work with the global menu
> bar and developers doesn't have to make their programs compatible with the
> global menu since it would just melt together the program's title bar with
> the panel.
>
> This makes much more sense than today's implementation and it would offer
> more effective work flow when you don't have to move across the entire
> screen.
>
> There are also more situations where the global menu works like a crippled
> narwhal. E.g. when working with programs as GIMP. GIMP has one main
> application window and several smaller windows with tools and such and if
> you have one of the smaller windows active you can't reach the menu, even if
> they are a part of the same application. You must target the main window and
> then you can reach the menu.
>
> So what are your thoughts? If anyone already knows how it will be
> implemented in 11.10 (maybe from a discussion at UDS) please share your
> knowledge!
>
> ___
> Mailing list: https://launchpad.net/~ayatana
> Post to : ayatana@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~ayatana
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Global menu in Oneiric Ocelot (11.10)

[Niklas Rosenqvist]

 2011/5/18 Henrik Peytz 
> Also, I think it's a bit of a stretch to expect application-devs to make
their applications global-menu compatible. I can see how maximized windows
getting stripped of their titlebar is relatively easy to implement in Unity
without requiring dev's to > change their apps (if maximized, then...), but
making the standalone windows behave in this way must require some change in
the application itself.

I don't know exactly what must be done but I know it's something since all
applications does not utilize the global menu, only the ones supported. E.g.
if you download the latest version of PlayOnLinux you'll see that it uses
the traditional menu - not global menu.

2011/5/18 Henrik Peytz 

> I've been begging for this particular change too.
>
> It makes more sense since vertical space is only an issue when you want it
> (ie. when you maximize windows), so un-maximized windows have no use for the
> global menu since, if they're un-maximized, they don't need the extra
> vertical space to render properly.
>
> Also, I think it's a bit of a stretch to expect application-devs to make
> their applications global-menu compatible. I can see how maximized windows
> getting stripped of their titlebar is relatively easy to implement in Unity
> without requiring dev's to change their apps (if maximized, then...), but
> making the standalone windows behave in this way must require some change in
> the application itself.
>
> 2011/5/18 Niklas Rosenqvist 
>
>> Hi!
>> I as many have questioned the global menu bar which Unity features. I
>> believe there are several issues with it as it is today and I will air my
>> thoughts here.
>>
>> Many has complained on that it is incredibly frustrating to be working
>> with on larger monitors. If the active window is in the bottom right corner
>> and you have the menu at the top (which isn't even visible until you hover
>> it) it makes no sense what so ever to look for it up there and it's really
>> ineffective. Consider the following:
>>
>> 2011/5/18 Ralph Green 
>>  > The global menu bar
>>  > is another matter. It must die. If there is one feature that will
>>  > drive me away from Unity, this is it. Again, there is no benefit,
>>  > except on really small screens. And, now, I don't even see the menu
>>  > until I move the mouse to the upper left hand corner of the screen.
>>  > That is often a long way from where my program is. This really take a
>>  > lot longer to operate. I don't understand how anyone could like it.
>>  > I am not saying they are wrong to like it. I just don't understand
>>  > how such a crazy thing was adopted. You know this feature was put on
>>  > the Macs because they had such tiny screens at the time(512 by 384
>>  > pixels). I have seen Mac people discuss why it is a bad idea in the
>>  > days of large screens and it only stays because of inertia. And Steve
>>  > Jobs obsession with simplicity over usability., to be sure.
>>
>> Though I think that there has been proposed a really good solution to
>> this:
>>
>> On Mon, May 9, 2011 at 7:10 PM, GonzO Rodrigue 
>> wrote:
>>  > [...] B) only appeared in the
>>  > "panel" space when the app is maximized. Leaving it in the window space
>>  > makes more sense when not maximized [...]
>>
>> This way the menu wouldn't be taking up space when the application is
>> maximized and it would still leave the menu implementation up the developers
>> to design freely as they want. With this design firefox 4 could have it's
>> menu button instead of splitting it into a menu to work with the global menu
>> bar and developers doesn't have to make their programs compatible with the
>> global menu since it would just melt together the program's title bar with
>> the panel.
>>
>> This makes much more sense than today's implementation and it would offer
>> more effective work flow when you don't have to move across the entire
>> screen.
>>
>> There are also more situations where the global menu works like a crippled
>> narwhal. E.g. when working with programs as GIMP. GIMP has one main
>> application window and several smaller windows with tools and such and if
>> you have one of the smaller windows active you can't reach the menu, even if
>> they are a part of the same application. You must target the main window and
>> then you can reach the menu.
>>
>> So what are your thoughts? If anyone already knows how it will be
>> implemented in 11.10 (maybe from a discussion at UDS) please share your
>> knowledge!
>>
>> ___
>> Mailing list: https://launchpad.net/~ayatana
>> Post to : ayatana@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~ayatana
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
> ___
> Mailing list: https://launchpad.net/~ayatana
> Post to : ayatana@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~ayatana
> More help   : https://help.launchpad.net/ListHelp
>
>
_

Re: [Ayatana] Global menu in Oneiric Ocelot (11.10)

[Thorsten Wilms]

On 05/18/2011 11:58 AM, Henrik Peytz wrote:

It makes more sense since vertical space is only an issue when you want
it (ie. when you maximize windows), so un-maximized windows have no use
for the global menu since, if they're un-maximized, they don't need the
extra vertical space to render properly.


It seems you didn't really think of cases where you have several windows 
next to each other, all fully exposed.


Actually it's the several non-maximized windows case where a global menu 
shines regarding space efficiency, as you don't save only one menu bar 
area, but several.



It would be an interesting _experiment_ to render non-maximized windows 
sans menus, and have the menu slide in inside a window, once it gets and 
for as long as it has focus. Or to avoid movement, switch between titles 
and menus in the titlebars.



--
Thorsten Wilms

thorwil's design for free software:
http://thorwil.wordpress.com/

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Global menu in Oneiric Ocelot (11.10)

[Henrik Peytz]

Or have a menu-toggle-button next to the other window-controls (close,
maximize etc.) so the user can decide on a per-window-basis whether he wants
the menus visible or not.
I think auto-hiding menus would be bad since it's possible for a user to
want to retain an overview of available menus, even if that particular
application is not in focus. This is particularly true when learning a new
application and the user doesn't remember all the options available to him.

Moving the menu to the titlebar is also a solution, though people will
probably complain a about the clutter, and dragging the window will be
problematic if the menus span the entirety of the window due to
menu-overflow or resizing the window too small.

2011/5/18 Thorsten Wilms 

>
> Actually it's the several non-maximized windows case where a global menu
> shines regarding space efficiency, as you don't save only one menu bar area,
> but several.
>
>
> It would be an interesting _experiment_ to render non-maximized windows
> sans menus, and have the menu slide in inside a window, once it gets and for
> as long as it has focus. Or to avoid movement, switch between titles and
> menus in the titlebars.
>
>
> --
> Thorsten Wilms
>
> thorwil's design for free software:
> http://thorwil.wordpress.com/
>
>
> ___
> Mailing list: https://launchpad.net/~ayatana
> Post to : ayatana@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~ayatana
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Global menu in Oneiric Ocelot (11.10)

[Niklas Rosenqvist]

 2011/5/18 Henrik Peytz 
> [...] and dragging the window will be problematic if the menus span the
entirety of the window due to menu-overflow or resizing the window too
small.

Agreed, it was the first thing I thought about when I read the suggestion.

> Or have a menu-toggle-button next to the other window-controls (close,
maximize etc.) so the user can decide on a per-window-basis whether he wants
the menus visible or not.

This on the other hand was highly interesting. This together with the title
and menu merging with the top panel when an application is maximized would
probably solve the most problems. Consider when you use nautilus, I at least
never uses the menu since I only use it for browsing and lots of menu
entries have keyboard shortcuts. But when you use a program like GIMP you
always want to be able to reach the menu. If the setting is saved per
application this could work really good. It would also leave it up to the
developers how they want to design their menus, because when your not moving
the menu up to the top panel you can choose to create menu buttons as Opera
and Firefox 4 features. This would leave much more freedom to the
developers.

Or as an alternative can menu buttons ala Opera (can't call it firefox style
since Opera actually was first with it) get created automatically and be an
entry in the title bar. But what would cause other problems, e.g. the
developers actually creating their own menu button and in that case it could
get confusing.

2011/5/18 Thorsten Wilms 
>  Actually it's the several non-maximized windows case where a global menu
shines regarding space efficiency, as you don't save only one menu bar area,
but several.

This is of course true but that leads us to the question whether it's more
important to have an efficient workflow or save 24px vertical space? For
myself is the ease of access a higher priority, since an ineffective work
flow will get you frustrated and slow down your effective work time.


2011/5/18 Henrik Peytz 

> Or have a menu-toggle-button next to the other window-controls (close,
> maximize etc.) so the user can decide on a per-window-basis whether he wants
> the menus visible or not.
> I think auto-hiding menus would be bad since it's possible for a user to
> want to retain an overview of available menus, even if that particular
> application is not in focus. This is particularly true when learning a new
> application and the user doesn't remember all the options available to him.
>
> Moving the menu to the titlebar is also a solution, though people will
> probably complain a about the clutter, and dragging the window will be
> problematic if the menus span the entirety of the window due to
> menu-overflow or resizing the window too small.
>
>
> 2011/5/18 Thorsten Wilms 
>
>>
>> Actually it's the several non-maximized windows case where a global menu
>> shines regarding space efficiency, as you don't save only one menu bar area,
>> but several.
>>
>>
>> It would be an interesting _experiment_ to render non-maximized windows
>> sans menus, and have the menu slide in inside a window, once it gets and for
>> as long as it has focus. Or to avoid movement, switch between titles and
>> menus in the titlebars.
>>
>>
>> --
>> Thorsten Wilms
>>
>> thorwil's design for free software:
>> http://thorwil.wordpress.com/
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~ayatana
>> Post to : ayatana@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~ayatana
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
> ___
> Mailing list: https://launchpad.net/~ayatana
> Post to : ayatana@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~ayatana
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Indicator Emulation for Systray applications

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Chow Loong Jin wrote on 02/05/11 19:07:
>
> In Ubuntu 11.04, Unity has effectively removed notification area
> support for almost everything but a few exceptions, which are
> maintained in a whitelist specified in dconf.
>
> I'm not exactly sure why this happened, but I'm thinking that it's
> something along the lines of forcing all applications to move to the
> new and improved indicators.

Yes. 

> This actually got me thinking.. rather than hiding the icons of the
> applications not in the whitelist, how about emulating indicators for
> them? Disclaimer: I don't know if this idea has been brought up before,
> so if it has, please point me in the right direction.
>
> I haven't actually given much thought to the implementation, so I don't
> actually know how hard it is to implement, if it's even possible, but
> design-wise, it could be something like taking the context menu from
> the notification area icon and using that as the emulated indicator's
> menu, and add an extra entry to the top of the menu for launching the
> application.
>...

As I understand it, an external process (such as Unity's menu bar) has
no way of knowing what kinds of interaction a notification area item
will respond to. Without actually triggering those events, there's no
programmatic way to predict what it will do when hovered over, when
clicked, when double-clicked, when right-clicked, or when dragged.

So there is no "context menu from the notification area icon" in any
parseable place. Rather, when a notification area icon is right-clicked,
it sometimes runs some code that happens to open a menu nearby.

- -- 
mpt
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk3T07kACgkQ6PUxNfU6ecpUEACeKvcW7LDElpepfvPLKtuPWjmg
lOgAoLc4/mHbLfEWkHUkJhDgJRtu3cAb
=MuGK
-END PGP SIGNATURE-

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Global menu in Oneiric Ocelot (11.10)

[Bazon]

Am Mittwoch, den 18.05.2011, 15:15 +0200 schrieb Niklas Rosenqvist:
> Or to avoid movement, switch between titles and menus in the
> titlebars.

I like that idea:
Consistent (menu/title toggle as for maximized window now, than simply
for all windows)
and contextual (it's clear where every menu belongs to). 



Additionally to the before mentioned idea of a menu/title toggle button
next to the window controls, i could also imagine a window grip button
for moving the window when the whole title bar is occupied by menus for
moving the window.


___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Global menu in Oneiric Ocelot (11.10)

[Niklas Rosenqvist]

2011/5/18 Bazon 
> i could also imagine a window grip button
> for moving the window when the whole title bar is occupied by menus for
> moving the window.

Without testing I just get the feeling that this would be ineffective since
I know that I much more often move a window than go to it's menu. A small
grip will probably be annoying to always find with your cursor. The whole
title bar provides a much easier and faster way of rearranging windows.

I made some sketching on this and came up with a mockup which you can find
here:
http://i.imgur.com/f8q2c.png

The three top images is describing the solution we've talked about and the
fourth image is an extension of the implementation we've discussed. This
implementation is possible today thanks to a plugin, but it would be sweet
to have it natively.

2011/5/18 Bazon 

> Am Mittwoch, den 18.05.2011, 15:15 +0200 schrieb Niklas Rosenqvist:
> > Or to avoid movement, switch between titles and menus in the
> > titlebars.
>
> I like that idea:
> Consistent (menu/title toggle as for maximized window now, than simply
> for all windows)
> and contextual (it's clear where every menu belongs to).
>
>
>
> Additionally to the before mentioned idea of a menu/title toggle button
> next to the window controls, i could also imagine a window grip button
> for moving the window when the whole title bar is occupied by menus for
> moving the window.
>
>
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Global menu in Oneiric Ocelot (11.10)

[Niklas Rosenqvist]

Sorry people for accidentally sending duplicates, here is the real version:

2011/5/18 Bazon 
> i could also imagine a window grip button
> for moving the window when the whole title bar is occupied by menus for
> moving the window.

Without testing I just get the feeling that this would be ineffective since
I know that I much more often move a window than go to it's menu. A small
grip will probably be annoying to always find with your cursor. The whole
title bar provides a much easier and faster way of rearranging windows.

I made some sketching on this and came up with a mockup which you can find
here:
http://i.imgur.com/f8q2c.png

The three top images is describing the solution we've talked about and the
fourth image is an extension of the implementation we've discussed. This
implementation is possible today thanks to a plugin, but it would be sweet
to have it natively.

2011/5/18 Niklas Rosenqvist 

> 2011/5/18 Bazon 
> > i could also imagine a window grip button
> > for moving the window when the whole title bar is occupied by menus for
> > moving the window.
>
> Without testing I just get the feeling that this would be ineffective since
> I know that I much more often move a window than go to it's menu. A small
> grip will probably be annoying to always find with your cursor. The whole
> title bar provides a much easier and faster way of rearranging windows.
>
> I made some sketching on this and came up with a mockup which you can find
> here:
> http://i.imgur.com/f8q2c.png
>
> The three top images is describing the solution we've talked about and the
> fourth image is an extension of the implementation we've discussed. This
> implementation is possible today thanks to a plugin, but it would be sweet
> to have it natively.
>
> 2011/5/18 Bazon 
>
>> Am Mittwoch, den 18.05.2011, 15:15 +0200 schrieb Niklas Rosenqvist:
>> > Or to avoid movement, switch between titles and menus in the
>> > titlebars.
>>
>> I like that idea:
>> Consistent (menu/title toggle as for maximized window now, than simply
>> for all windows)
>> and contextual (it's clear where every menu belongs to).
>>
>>
>>
>> Additionally to the before mentioned idea of a menu/title toggle button
>> next to the window controls, i could also imagine a window grip button
>> for moving the window when the whole title bar is occupied by menus for
>> moving the window.
>>
>>
>
>
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp