Re: [Ayatana] Middle-click on indicators

[Philipp Wendler]

Hello,

On 15/04/10 07:48, Cody Russell wrote:
> I guess my concern is that we're talking about breaking the concept of
> menus after it was previously decided at a UDS (by Mark, UX and DX
> teams, and community) that indicators should behave like (and be
> implemented based upon) menus.

Honestly, I don't like this decision for the following reasons:

1. Indicators are not menus in the eye of the user, they are quite
different to menus:
a) Menus have text buttons, indicators have icons. The indicators
"menus" are the only menus I know which have no text button. Even the
Application/Places/System menu in the same panel looks like a normal
menu and different from indicators, so why should users expect
indicators to be a menu? Using different styles for the same thing in
the same panel seems not to be the best thing. On the other hand,
indicators look exactly like the application starter icons (aside from
being less colorful), which are in the same panel, too. But indicators
behave not like the starters, which have a default action on left-click
and a popup menu on right click. The latter is IMHO also the most
commonly used user interaction pattern for icons since Windows 95.

b) Menus don't have sliders, checkboxes, progress bars etc. in them.
Perhaps next comes a text field to support changing the away message of
your IM client? Look at the "menu" of indicator-sound, does this really
look like a menu in your eyes?
c) Menus don't react on scrollwheel events, but indicator-sound does.
d) Menus don't appear/disappear and their button does not change
(neither in color nor in content), the only change over time may the
enabling/disabling of some of the menu items. Indicators however are
supposed to change or even disappear if I understood this correctly.

2. Menus are not powerful enough to support all kinds of user
interaction, and they are not meant to be that powerful. For the normal
use of menus this is fine, because they are accompanied by other user
interaction components. Almost all applications with a menu also have a
toolbar which provides one-click shortcuts for the most important
actions, so menus don't need to provide this. Menus also don't need to
provide configuration possibilities through checkboxes, sliders etc.
because there is a configuration dialogue which accomodates these
components. And if they are frequently used (like the volume slider),
there is an additional widget directly in the main window of the
application.
But for indicators, the situation is different. The user expects them to
be shortcuts (the long way would be to open the application window and
do the action there), so they can't require to open a configuration
dialogue to change something simple. And they are not accompanied by a
separate toolbar, which the user could use to invoke single-click
actions, so the indicators need to be used for this.
So in my eyes it appears that plain menus are simply the wrong tool for
the job.

> And from a usability side, I feel like we should minimize differences
> between menus in applications and menus in the panel rather than create
> more.

As I said, this would be ok if the panel would then also support all the
other user interaction ways that applications support. This means having
an additional toolbar with single-click actions, having a additional
sound icon which supports the scrollwheel (like Rhythmbox has) etc. We
can't use one single component which is normally used together with
other components and expect it to be best way to do things if used alone.


Just to make this clear: I'm not against indicators, I really think they
are promising and I think some of the possibilities they provide are
pretty cool. I'm just opposed to restricting them to the small feature
set of menus, they could be much cooler if they support more than menus.
Of course consistency accross different components is a good thing, but
indicators are already (and probably will always be) different than
anything else on the desktop, so adding a few additional user
interaction possibilities will not be significant. For consistency
accross different indicators, a nice solution has already been proposed.
A default action which is contained in the menu but may be activated
through a shortcut would be pretty consistent, especially if the default
action is highlighted in the menu in some way (the Windows Systray is
like this). This concept of default action could also be extended to a
default scroll action: An indicator which contains a slider could mark
this as the default slider which gets changed when the user uses the
scrollwheel over the indicator icon. Then the special case of
indicator-sound would be no special case anymore, so this would even
improve consistency.

Greetings, Philipp

___
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] Middle-click on indicators

[Philipp Wendler]

Hi,

Am 15/04/10 14:15, schrieb Matthew Paul Thomas:

> Yes, as the Windows UX guidelines say: "Left single-click" should
> "Display whatever users most likely want to see", while "Right-click"
> should "Display the context menu, with the default command in bold."
> 
> 
> But even though (a variation of) that guideline has been around since
> Windows 95, it hasn't worked out well. Many users have given up on
> left-clicking on notification area items -- probably, I think, because
> the left-click action wasn't predictable or memorable enough. Instead,
> they right-click to get the menu every time. "What? You can left-click
> on that thing and it does something different from right clicking? Dude,
> why didn't anybody tell me this? I've been doing it the hard way all
> this time!"
> 

For me this shows that it is not worth trying to let the indicators
behave exactly like a single other UI component. This interaction
pattern is the same as for almost all icons in Windows (desktop, start
menu, files in the explorer etc., with toolbars being probably the
single big exception) and for these icons everybody knows how to use it.
But indicators look somewhat different and users expect them to do
something different, so they don't expect indicators to support the same
interaction pattern. And I think this is the same for our indicators,
the users will not expect them to behave exactly like menus, because
they look different and they are there for a different purpose. So why
bother restricting the indicators to plain menus?

However, I do not support the "users don't use it, so we don't need to
implement it" conclusion one might draw from this article. On Windows,
altough there is this guideline, there is some inconsistency between
different indicators, and some of the users might have experienced
unwanted actions to be executed on left click, so they trained
themselves to only use right click. Also they need to know about the
right-click menu, because some options are available only there. So it's
either "know both of them" or "know the right click".

If we enforce that the default action has to appear in the left-click
menu, this inconsistency is gone. Also, as Conscious User wrote, we want
to use the opposite: left click (which is still the default click mode)
will bring up the menu, and this is all you ever need to know, if you
don't want to know more. Also a left click will never execute an
unwanted action. But if you know more, and want to be faster, than there
is a shortcut for you. But the advanced UI will not disturb or confuse
the beginner user. I think this is the right way to provide user
interfaces that behave well for both beginners and experts.

Greetings, Philipp

___
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] Two suggested designs for the Sound Indicator

[Philipp Wendler]

Hello,

Am 20.05.2010 23:48, schrieb Jan Claeys:

Op donderdag 20-05-2010 om 12:00 uur [tijdzone +0100], schreef Mark
Shuttleworth:

We discussed auto-attenuating music when a *phone call* comes through,
which makes sense. But multiple music players that's up to the user
to handle.


Can anybody give a use-case for having 2 music players *playing* at the
same time?  And I'm thinking about playing music from a music library or
listening to on-line radio or similar, not another sound-producing
application...


I often use this.
One example is when looking through a folder of video files to find the 
correct one or to sort them. I have rhythmbox in the background playing 
my favourite music and I open each of the video files in vlc, and I 
would be upset if rhythmbox stopped playing every time.


Ok, that's not exactly "playing music from a music library or listening 
to on-line radio", but where would you draw the line? I would expect 
that if playing music is a reason to pause the first player, playing a 
video player would be, too.


I wouldn't even be sure if the browser shouldn't be considered a player 
in this case, too. I guess a lot of people today use online sites 
(Youtube etc.) as their primary source of audio and video, so they would 
wonder why this is different from playing local media. But if you add 
the browser, every silly website with audio would make your player stop, 
because you cannot tell whether the user wanted this website to play 
sounds or not.


As someone else on the thread said:
If you keep it like it is, every user will understand the situation, and 
will know what he needs to do if it disturbs him. After all, this is 
nothing different from having a radio and a cd player playing in the 
same room.
But if you do automatically disable audio applications, users will be 
surprised because something happened (first player stops) that they 
didn't initiate, and probably many users wouldn't notice why this 
happened. You would need to add controls to disable this behaviour for 
now, and globally.


So I'm strongly against this.

Greetings, Philipp

___
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] Two suggested designs for the Sound Indicator

[Philipp Wendler]

Hello,

Am 22.05.2010 01:11, schrieb Jan Claeys:
> Op vrijdag 21-05-2010 om 08:26 uur [tijdzone +0200], schreef Philipp
> Wendler:
>> One example is when looking through a folder of video files to find the 
>> correct one or to sort them. I have rhythmbox in the background playing 
>> my favourite music and I open each of the video files in vlc, and I 
>> would be upset if rhythmbox stopped playing every time.
> 
> Totem or VLC (or whatever you use) aren't music players taht should go
> into the sound-menu IMO; they are okay to quickly check out the
> occasional music file, but they are useless for listening to music in
> the background.

But this adds inconsistency again. Both VLC and rhythmbox are media
players. And VLC is not useless for listening to music in the
background, on the contrary I (have to) use VLC for listening to music
sometimes because I have music files that rhythmbox doesn't play (right).

> Playing music is a background-task, looking at those video files (or
> audio files, for that matter) is a foreground task and thus shouldn't go
> into or influence the sound indicator menu.

You cannot clearly determine the intention of the user in all cases. VLC
can be used for background listening, and rhythmbox can be used for
foreground tasks like looking through the music library and playing
short parts of a lot of audio files.

> Browsers are a problem, as there is no way for them to indicate the
> intention (and if websites would be given a way to indicate their
> intention, it would be abused by spammers from day one).  I suppose the
> best solution is to have dedicated programs for streaming music that's
> supposed to be running in the background (this could be based on prism
> or similar for a quick solution!).

I'm afraid this won't happen. I believe a lot of people use the web as
(one of) their primary media source(s) through sites like Youtube etc.,
and how would you use a dedicated program for this? In a lot of areas we
see the trend that stuff which was previously done by dedicated programs
is now done with websites in the browser (e.g. email), and I don't think
you can reverse this trend for media playing.

> As outlined above: this would *NOT* influence all audio-producing
> applications, only those that register themselves as background tasks,
> or services, or whatever you want to call them.

And how does the user know the difference? I think the only effect for
the user would be that in some cases his music player suddenly stops and
he wonders why.

Also I don't think that the current situation is a problem.

Greetings, Philipp

___
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] VPN

[Philipp Wendler]

Hi,

Am 14.06.2010 16:21, schrieb Shane Fagan:
> I see you guys are planning the design of the networking menu. My
> question is do you really need vpn in there? Is it something that we
> need to expose to every user? Barely any desktop (or netbook) user uses
> vpn at all they mainly use normal lan, dsl or mobile so why not add a
> configure networks menu item instead as a catch all and add vpn if they
> are using it? Thoughts?

Probably a lot of students, professors and university staff use VPN on
their notebooks, as universities often require it if you want to use
their WLAN. At least here in Germany. There are also people who work
from home (at least occasionally) and need VPN to connect to their
company's network.

So I definitely would like to have an easy way to start a VPN connection
(directly in the indicator). It is like this even on my cellphone, which
has very limited screen space. But it would be ok for me if the VPN
options are only shown if a VPN connection has been configured.

Greetings, Philipp

___
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] Yet another discussion on window resizing - where does the problem lie?

[Philipp Wendler]

Hello,

Am 23.06.2010 09:20, schrieb Vishnoo:


I'v never found the need to resize firefox&  evolution [always
maximized] or the various prefs dialogue windows[which have the right
size].


Don't forget that there are users that do not always maximize their 
windows. This will be even more common in the future, because it doesn't 
make sense to maximize firefox etc. on a 24" screen. The only 
application I ever maximize on such a screen is Eclipse.



Rarely resize certain windows - eg: nautilus,xchat,liferea,terminal.
These remember the last size I had set them to and they open in the same
size[seems to be the case with almost every application in the default
install]. Which I rarely adjust more than once. The most common action I
do with them is maximize.


I often resize terminals, editors and evince and arrange them so that I 
can view all of them, for example when looking at a manual or a paper, 
doing something on the command line and writing some text about it.


So window resizing is IMHO an important action, and I think it's a 
little bit too difficult to grab the resize handle in Lucid.


Greetings, Philipp

___
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] Yet another discussion on window resizing - where does the problem lie?

[Philipp Wendler]

Hello,

Am 28.06.2010 03:25, schrieb Frederik Nnaji:

On Wed, Jun 23, 2010 at 14:43, Philipp Wendlerwrote:



Don't forget that there are users that do not always maximize their
windows. This will be even more common in the future, because it doesn't
make sense to maximize firefox etc. on a 24" screen. The only application I
ever maximize on such a screen is Eclipse.



24" ? good point there!
on my 10" i maximize everything except for Contact List, which i expect to
be an indicator menu at some point, hopefully.


Yes, I think it is very important for an OS nowadays to work with a wide 
range of screen sizes (and make use of it!). On the one hand there are a 
lot of mobile devices with small screens, but on the other hand a lot of 
people still use desktop PCs (probably almost all office users), and 
there screen sizes are increasing (24" screens are really cheap today).



I often resize terminals, editors and evince and arrange them so that I can
view all of them, for example when looking at a manual or a paper, doing
something on the command line and writing some text about it.



would resizing in a grid not help with all this? It would be easier to snap
application windows to each other this way. It would also make resizing
faster in general as far as i can imagine.


Actually I'm not that happy with the current situation of manually 
resizing and moving the windows. When I still had 19" screens, I used to 
maximize all important applications and not think much about window 
management, and I really had to train myself to adapt to a different 
usage style.


So I would like to see ways to make window placement easier. Do you know 
anything that I could try?


Greetings, Philipp

___
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] mail indicator not consistency

[Philipp Wendler]

Hi,

Am 06.07.2010 08:41, schrieb Mark Shuttleworth:
> Interesting questions. My gut feel would be:
> 
>  - incoming IM notifications would be suppressed
>  - incoming calls would be displayed

Why the latter? When I put my cellphone in DND (or silence) mode,
nothing is signaled: no calls, no SMS, no VoIP calls, no IM. I think a
PC should behave similarly.

Greetings, Philipp

___
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] CSD and the pressure to innovate

[Philipp Wendler]

Hello,

Am 07.07.2010 04:52, schrieb Apoorva Sharma:
> Since tabs in firefox and nautilus are just ways of combining
> multiple windows into one, why not have the window manager handle
> tabs for all apps? Maybe apps like firefox or nautilus etc could tell
> the window manager that they want tabbed windows, and it could be
> done for them. This would make tabbed interfaces consistent and more
> easily read for integration with the taskbar (like win7).

How would you handle the advanced application-specific features related
to tabs? In Firefox for example, there are quite a few actions when you
right-click on the tab bar:
- reload tab
- make tab into a bookmark
- undo tab closing

Also there are a lot of extension that would not be possible to use
anymore. I use ChromaTabs (colors the background of the tab button in
the tab bar according to the favicon to make it easier to locate the
tab) and PermaTabs (prevents accidental closing of certain marked tabs).
And when you look on addons.mozilla.org for addons in the category tabs,
there are 433 of them. I doubt that it will be possible to implement
them if the window manager manages the tabs.

Greetings, Philipp

___
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] mail indicator not consistency

[Philipp Wendler]

Hi,

Am 07.07.2010 10:43, schrieb Mark Shuttleworth:
> On 06/07/10 08:49, Philipp Wendler wrote:
>> Am 06.07.2010 08:41, schrieb Mark Shuttleworth:
>>   
>>> Interesting questions. My gut feel would be:
>>>
>>>  - incoming IM notifications would be suppressed
>>>  - incoming calls would be displayed
>>> 
>> Why the latter? When I put my cellphone in DND (or silence) mode,
>> nothing is signaled: no calls, no SMS, no VoIP calls, no IM. I think a
>> PC should behave similarly.
>>   
> 
> Does your phone vibrate?

Depends on a setting.

> Does the screen show the incoming call?

Yes.

But the point is, it behaves similarly for phone calls and for IM (the
latter also lead to vibration and screen message).

Greetings, Philipp


___
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] USB Device Removal Indicator

[Philipp Wendler]

Hello,

Am 26.08.2010 17:55, schrieb Frederik Nnaji:
> On Thu, Aug 26, 2010 at 15:56, Matthew Paul Thomas wrote:
> 
>> As soon as UI Freeze is past, how to eject/remove devices is something
>> I'll be investigating for Natty.
>>
>> It would be very helpful if people on this list could brainstorm
>> different ways to present it.
>>
> 
> combine it with the also device-oriented power menu.

There might also be other devices worth listing. For example scanners
(click should run simple-scan) and printers.

We might want to show the SMART status of hard disks (especially if it's
bad).

Greetings, Philipp

___
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] On Vincent Moulin's idea of partial global menu in unity

[Philipp Wendler]

Hi,

Am 28.10.2010 18:54, schrieb Barry Warsaw:


Third, it would be helpful if application focus switching via Alt-Tab were
application-centric not window-centric.  What I mean by that is that if I have
two Emacs windows open, or two mail windows open, Alt-Tab should cycle among
applications and not individual windows.  Choosing the application would bring
all of its windows forward, with the stacking order remembered from the
previous time the application was focused.  Then Alt-` toggles between the
application windows.


Using ` is a horrible idea in my opionion, because this character is at 
different locations on the keyboard in different layouts. For example on 
a German keyboard, it is directly left of backspace, and needs Shift 
pressed to access it. Furthermore, it is often a "dead key".


Greetings, Philipp

___
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] Focus follows pointer (Was: Re: Understanding the menu problem.)

[Philipp Wendler]

Hi,

Am 31.05.2011 19:27, schrieb Ed Lin:
> Truth be told, I never used focus "FFP" more than a few times out of
> curiosity. I'd be interested why people turn it on and how it helps
> them with their workflow.
> 
> In GNOME there are two relevant settings. One immediately focuses the
> window beneath the pointer. Additionally you can make the window rise
> after a given time interval. (See System Settings -> Windows).
> 
> To me the latter doesn't really make sense, raise on click will be
> faster except when you set it to "0.0" in which case, especially on a
> busy desktop it will get in your way.
> Without the rise feature enabled you only get focus which doesn't help
> you with mouse interaction if the desired  controls are behind another
> window. I guess it could make sense for keyboard shortcuts but then
> you'd have your hands on the keyboard and could use even faster
> keyboard combos to activate the desired window.
> On really busy workstations you probably don't have all windows
> visible all the times so the new Unity spread view should increase the
> efficiency even if ffp was completely removed.
> 
> I guess this leaves tiling layouts where all windows are visible all
> the times. In this case all I can say: You really should use a realy
> tiling WM and if you really care about speed and efficiency best thing
> you could do is throw out your mouse and learn the keyboard controls.
> 
> Well that's how I see it. Please enlighten me!

I use focus-follows-mouse, and I find it very annoying when I have to
work longer times on machines that don't have it enabled. I don't use
the "raise window" feature.

I have several use cases where I work with several windows. One is for
example working with an IDE, but repeatedly running the compiled program
from a terminal (often jumping back to the IDE while the program is
still running, jumping back when it has finished etc.). Another use case
is writing LaTeX documents in the terminal, jumping to the document
viewer to view the compiled document, or to the browser or to some other
open document repeatedly. A third use case would be to write an email
while looking at sources (e.g. a browser window). In the last case, the
typing task might actually be the secondary task, for which I only need
a window that receives and stores the typed letters.
These use cases make up for almost all of the time I use the computer at
work (which is actually almost all of the time I am at work).

This means that often I have windows where I want to follow whats
happening, and were I need keyboard interaction, but that I don't need
to bring to the front just to bring back the previous window a few
seconds later. So I have windows that usually overlap partly. This saves
space compared to tiling, and still enables a fast multi-window
workflow. I also don't want to use a tiling wm because it might not be
available on all the machines I use and it often feels inflexible for me
(all my windows are of different sizes normally).

So in general my use case is to rapidly switch to another window and
work there with the keyboard. With FFP, I reach to the mouse, but I
don't actually take it into my hand as I would have to in order to
click. Instead I just give it a little push in the right direction,
immediately withdrawing my hand. Sometimes the mouse is still moving
although my fingers are not longer touching it. This is a very fast
interaction, significantly faster as if I would have to click after
moving the mouse. It is possible, because as windows are pretty large
compared to other UI elements, the pointer will land there without
really aiming.

A further advantage is that I don't have to think about where in the
target window I might click without producing unwanted actions which
saves further time (and more important: saving my brain from thinking
about something that has nothing to do with what I want to accomplish).

I don't use the keyboard to switch windows, because I find it annoyingly
painful to cycle through all the open windows. Or is there a keyboard
shortcut for "please focus that terminal window right here on the left
bottom corner of the screen"? Because that is what I want when I am
working with multiple open windows. Using the mouse with FFP, I can
immediately transform that thought into an action, without having to
think further, because the mouse movement will directly correspond to
the movement of my attention (and my eyes) on the screen (by using FFP,
I can be sure that the cursor is currently somewhere in the window I was
working with). An example: If I work in a window on the right side of my
screen and something in a window on the lower left corner of the screen
draws my attention and I want to respond (let it be a chat window, or a
terminal were a program asks a question etc.), I can do with the mouse
through my hand the exact same movement that my eyes also did: from
right to lower left. No further thinking, no further aiming, no clicks,
just a slight push wit

Re: [Ayatana] Focus follows pointer (Was: Re: Understanding the menu problem.)

[Philipp Wendler]

Hi,

Am 31.05.2011 21:13, schrieb Ed Lin:
> On Tue, May 31, 2011 at 8:34 PM, Philipp Wendler
>  wrote:
>> I use focus-follows-mouse, and I find it very annoying when I have to
>> work longer times on machines that don't have it enabled. I don't use
>> the "raise window" feature.
> ()
> 
> Thank you for this detailed feedback!

Thank you for your interest.

> I still have some troubles understanding how focused but overlapped
> windows are useful in your three cases but obviously it works for you.

Well, I sometimes when I type in certain windows, I don't need to see
the whole window (because I know what will happen, or because a small
part of the window is enough to see). So I can use the screen space to
keep a window in the foreground that I need so see but not interact with
while I am typing in that other window.
I agree that this is definitely a workflow that only an advanced user
would use (and probably even few of them), but for me it saves time and
helps multi-tasking.

> Also I notice most of the tasks you do involve two main "active
> windows". In unity you can drag windows to either side of the screen
> and have them automatically tiled side by side.

Sure, I think it's great. But it works only if you have two windows that
should both occupy half of the screen space. But this is rarely the case
for me.
Also it currently doesn't work with two monitors (yes, I should really
file a bug for this sometimes).

>> A further advantage is that I don't have to think about where in the
>> target window I might click without producing unwanted actions which
>> saves further time (and more important: saving my brain from thinking
>> about something that has nothing to do with what I want to accomplish).
> 
> Couldn't this be solved simply by making all windows behave the same
> way: first click focuses and rises (gets trapped by the WM),
> subsequent clicks get sent to the application window.

Yes, this could make window switching without FFP easier of course.
However, I guess it would be hard to train myself that I can rely on the
first click having no effect (and it would probably hurt when I work on
another machine, so I don't know if I want to train myself to rely on
this at all). Also it would bring the window to the front, of course,
which I often don't want.

>> I don't use the keyboard to switch windows, because I find it annoyingly
>> painful to cycle through all the open windows. Or is there a keyboard
>> shortcut for "please focus that terminal window right here on the left
>> bottom corner of the screen"?
> 
> Not really but an helpful keyboard shortcut in Unity which you might
> have missed is Super("Windows key") followed by a number. Just keep
> the super key pressed for two seconds or so and have a look at the
> launcher ;)

Oh, thanks. I really missed that, but I'll definitely try it out for
some time at least.

>> So please, keep FFP useable!
> 
> I think as long as Ubuntu largely depends on GNOME and other 3rd party
> for its apps you will be able to use it without a global menu and
> therefore keep using FFP. For now this should work:
> 
> sudo apt-get remove appmenu-gtk indicator-applet-appmenu indicator-appmenu

Currently, I'm using unity with global menu (and FFP) on an "evaluation
basis", to see if I can work with it. I really like it for maximized
windows, so my ideal would be to have both. :)

Would it be an option to make the global menu for non-maximized windows
configurable? The window settings dialogue is not that overloaded that
it wouldn't fit in there. (Plus there are settings in this dialogue that
I think are much less important). Or if additional options aren't
welcome, disable it automatically if FFP is enabled?

Greetings, Philipp

___
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)

[Philipp Wendler]

Hello,

Am 15.06.2011 22:28, schrieb Matthew Bassett:

> What about just having the menu bar consistently appearing with the
> window buttons: i.e. in the panel when the window is maximised, and on
> the title bar on non-maximised windows -- appearing when the mouse goes
> over the title bar.
> 
> This leaves the issue of how to grab the title bar of a non-maximised
> window in order to move it, which I would assume to be an easier problem
> to design/resolve; my naive suggestions would be to either
> 
> 1) to not activate menu drop downs until mouse-up (so you can grab the
> the menu bar/title bar without issue and drag the menu around), or
> 
> 2) only make the menu appear when you mouse over the left hand half of
> the title bar.

There could also be a grab handle in the title bar, e.g. a fourth
button. I think "move window" fits nicely into the row of "close",
"minimize" and "maximize". When clicking on this button, you wouldn't
need to keep your mouse button pressed until the window is in the final
position, which might help some people that have problems with drag'n'drop.

For windows with short menus, clicking on the empty space beyond the
right-most menu bar entry could also allow dragging around, so you'd
need to use the small button only for windows with too long menus (which
are relatively rare I guess).

Greetings, Philipp

___
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)

[Philipp Wendler]

Hi,

Am 16.06.2011 10:24, schrieb Adrian Maier:

On Thu, Jun 16, 2011 at 09:53, Philipp Wendler  wrote:

Am 15.06.2011 22:28, schrieb Matthew Bassett:


What about just having the menu bar consistently appearing with the
window buttons: i.e. in the panel when the window is maximised, and on
the title bar on non-maximised windows -- appearing when the mouse goes
over the title bar.

This leaves the issue of how to grab the title bar of a non-maximised
window in order to move it, which I would assume to be an easier problem
to design/resolve; my naive suggestions would be to either

1) to not activate menu drop downs until mouse-up (so you can grab the
the menu bar/title bar without issue and drag the menu around), or

2) only make the menu appear when you mouse over the left hand half of
the title bar.


There could also be a grab handle in the title bar, e.g. a fourth
button. I think "move window" fits nicely into the row of "close",
"minimize" and "maximize". When clicking on this button, you wouldn't
need to keep your mouse button pressed until the window is in the final
position, which might help some people that have problems with drag'n'drop.

For windows with short menus, clicking on the empty space beyond the
right-most menu bar entry could also allow dragging around, so you'd
need to use the small button only for windows with too long menus (which
are relatively rare I guess).


Such a titlebar button seems tedious to use  (too small) .


Of course it is very small, but as I said I think it will be needed only 
for a minority of windows.
Actually there is a nice similarity to the minimize and maximize buttons 
here. These also handle window management, and both are very small, too. 
But for experienced users that want to work faster, there is a shortcut 
that involves mouse interaction with the title bar. The buttons are 
there despite the existence of a shortcut, because their are more 
discoverable for new users.


So the same rationale that is used for the minimize and maximize buttons 
actually applies to a move button as well, I think.


So is there a reason why we don't have a move button?


Having a titlebar for moving windows is not an absolute must :  it can
be replaced with  Alt + mouse_dragging.


Right, though I think there should exist a mouse-only way to move windows.


I enjoy to use this method wherever it's available because it doesn't
matter where you click inside the window .


In the other hand , I  think that it would be interesting to consider
merging the titlebar and the menu  :
- use the first 50 or 60 pixels of the titlebar for the window label .


I think for the normal state (no current interaction) this is too short. 
A lot of window titles only differ at their end, and so I'd prefer to 
see the full title.


Greetings, Philipp

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