Shouldn't this be tracked as one of the accessibility bugs?

Thanks Havoc; adding accessibility keyword.

Apologies for spam... marking as GNOMEVER2.3 so it appears on the official GNOME
bug list :)

Anyone have a suggestion on what the keybinding for this should be?
Any precedent in CDE/Windows/whatever?

Windows doesn't have any sort of equivalent to true multihead.  Don't
know about CDE or others.

I'm reasonably sure CDE doesn't either, it wasn't known for its
accessibility :)  If it did, it probably involved one of those useful
Sun keys that lesser keyboards don't have anyway (Alt+Front or
something)...

I think we've pretty much exhausted all the combos involving
Alt-Tab... we'd be getting into the realms of Super-Alt-Tab or
Hyper-Alt-Tab, which isn't nice.

Maybe something involving PrintScreen, or is that too off-the-wall...?

Well there's always Ctrl-Alt-Hyper-Super-Meta Esc.  We wouldn't want
people to hit it accidentally or anything :-)

How about using the ctrl-alt-left and right keys that cycle workspaces? 

Like: (I am on screen 1, workspace 1)

1. ctrl-alt-right moves focus to screen 2 workspace 1
2. ctrl-alt-right moves focus to screen 1 workspace 2

Notes: Changed GNOMEVER to 2.7 to match up with target milestone.

marking "AP2" since this is relevant to the problem identified with
fullscreen magnification, e.g. how to change screens if the mouse is
currently on the "wrong" one.

Attaching a patch where I am using "<Ctrl> <Alt> s" as the key to
switch between screens.

Created attachment 25798 [details] [review]
patch which fixes the bug

Can we avoid keybindings involving a-z with Ctrl,Alt,&Shift? 
Ctrl-Alt-s, for example conflicts with emacs' regex
search-and-replace--something I use heavily.  I wouldn't be surprised
if other apps used it as well (especially since Ctrl-s is so common
for save).  I know in general that Metacity needs to be able to
reserve a certain number of keybindings and apps should just be fixed
(e.g. Alt-space), but it really seems suboptimal to me to start taking
away bindings involving alphanumeric characters.

However, I wouldn't see any problem of perhaps using Hyper or Super
and a-z.  And if someone can afford multiple screens, it could be
argued that they can afford a keyboard with such keys (I can get one
for under $5 at a thrift shop).

Just some food for thought...

<Ctrl><Alt> s doesn't conflict with emacs regex search and replace. 
That's <Ctrl><Meta>s.  The <Ctrl><Alt>* keybindings are generally
reserved for the window manager.

Sure, assuming you have a Sun keyboard.  If you have a PC keyboard,
since there is no Meta key, Alt is used in place of Meta.

I don't have a sun keyboard, yet somehow I have a meta key.  It's the
"windows" key.  If you're an emacs user, you really have to bind your
keyboard that way, since you really need a meta key.  And regardless,
you can always reconfigure your keybindings.

It's impossible to completely avoid every key combination ever used by
anybody.  I don't know if ctrl alt s is the best possible key
combination, but I don't think that "it conflicts with an emacs
binding if you have your keyboard configured in a particular weird
way" is a very good reason to rule it out.

I have several PC keyboards, some with and some without a "windows"
key.  For all of them Alt is used for Meta, and I didn't do a single
thing to configure it that way.  But, we are really getting away from
the point because as you said, conflicts with emacs aren't a
sufficient reason (or likely even a good reason) to rule out a
keybinding.  (I probably shouldn't have used emacs as an example, but
well...it's just an example that came to mind)

Basically, I think that Ctrl-Alt-[a-z] shouldn't be taken by the
window manager.  I think that doing so could cause lots of application
conflicts.  In particular, Ctrl-s is extremely common for save.  So if
the app has any other shortcuts they want for an action beginning with
s, Ctrl-Alt-s would seem natural.

If you disagree with me, that's fine.  I'm not the maintainer.  I was
just pointing out something that I thought might cause problems. 
Hopefully you'll take it into consideration, but, of course, the
ultimate decision is yours.

Well I think that we should get usability guys involved before we do
anything with potentially large impact like adding new default
keybindings.  Martijn's idea has some appeal I think.

But it's really hard to tell since find it hard to imagine anyone
would want a multihead system sans xinerama, and since I don't know
what people are using such systems for, I can't really know what would
be convenient or inconvenient for them.

One thing that we should definitely do though is make it so we don't
bind the key if we're managing just one screen.

FWIW I know lots of uses for multihead without xinerama.  Particularly
if you really *do* want to keep the displays notionally separate.

Ctrl-Alt-arrow for switching workspaces seems intuitive to me, so
perhaps Ctrl-Alt-PgUp and Ctrl-Alt-PgDn?

Apologies for spam-- ensuring Sun a11y team are cc'ed on all current a11y bugs.
 Filter on "SUN A11Y SPAM" to ignore.

Comment on attachment 25798 [details] [review]
patch which fixes the bug

Please update the patch so the keybinding is only actually enabled if we have
multiple screens, then the keybinding collision issue basically goes away.  I
apologize that this has sat so long.

Attaching an updated patch to bind the switch_screen and switch_screen_backward
key only in case of multihead setup. 

The keybindings META_KEYBINDING_SWITCH_SCREEN and
META_KEYBINDING_SWITCH_SCREEN_BACKWARD are added to the keybinding table in
rebuild_binding_table () only if the number of screens are more than 1. To
acheive this I am doing an strstr () for META_KEYBINDING_SWITCH_SCREEN. 

Kindly let me know if there is any other better way to do this other than using
string comparisions. Thanks.

Created attachment 47383 [details] [review]
Patch which binds switch_screen keys only for multihead setup

I probably would have added a multihead_only bit to the keybindings struct, but
the str comparison isn't all that horrible.  Havoc?

Comment on attachment 47383 [details] [review]
Patch which binds switch_screen keys only for multihead setup

String comparison is fine but shouldn't it be strcmp not strstr?

The gnome-monitor.png icon needs to be done in a themeable way for a11y. Though
just not having an icon is probably fine too.

The patch introduces two new keys for screen switching: switch_screen and
switch_screen_backward. If strcmp () is used, need to do something like:

if (!strcmp (prefs[src].name, META_KEYBINDING_SWITCH_SCREEN) ||
    !strcmp (prefs[src].name, META_KEYBINDING_SWITCH_SCREEN_BACKWARD))
  {
     ....
  }

So used strstr () instead of strcmp () to avoid an extra str comparision for
each key. 

Kindly comment which one to use.

I would use strcmp, the clarity is better than any possible performance difference.

Created attachment 47535 [details] [review]
patch using strcmp () and themed gnome-monitor icon

This patch partly works for me (I've patched metacity-2.10.0-2.fc4 from Fedora
Core 4). When Ctrl-Alt-s is pressed, it correctly displays the screen list
pop-up, and focus is switched to the opposite screen to the window which has the
same coordinates as the cursor had on the previous screen (I use follow-mouse
focus). However, the cursor is not warped to the newly-activated screen, which
is quite confusing for further work.

And when I press Ctrl-Alt-s once more (without moving the mouse, i.e. the cursor
is already on the screen I want to switch to), the cursor is moved to the (0, 0)
coordinates of the _opposite_ screen. I think the patch should warp the cursor
to the new screen to the same coordinates. Or even better, to the coordinates
proportional to the screen size, i.e. the cursor in the lower right corner of
the previous screen should be moved to the the lower right corner of the new
screen, even if the screens have not the same dimension or even aspect ratio.

While providing support for the mouse cursor movement to the selected screen, I
found that while focussing a screen with no windows (mru list empty), the popup
came up but was kind of stuck and sometime later metacity crashed. I am looking
into this issue also.

Remove old target milestones on old bugs; sorry for the spam.

Created attachment 58240 [details] [review]
Leena's patch with some fixes

I just attached a new patch as a result of trying to find and fix issues in the previous patch.  Note that the patches from bug 319348 and bug 319423 are somewhat related and someone testing the patch might think they've uncovered bugs in this patch when it's really those two other bugs.  Anyway, the patch I just attached functions, but still has some annoying issues.  I want to work on other stuff, so I thought I'd attach what I have.  Anyway:

Problems with the previous patch (mostly nit-picky stylistic stuff; the patch was pretty good overall):
  - naming inconsistency; I renamed handle_move_to_screen() to
    handle_switch_to_screen() for naming consistency (the former version sounds
    like we're moving a window to a different screen rather than just moving
    the focus to a window on a different screen)

  - keybinding handler inconsistency; I removed the GINT_TO_POINTER's being
    passed as handler data and added a separate
    handle_switch_to_screen_backward(); this is more in line with how switching
    between windows is done.  Granted, Leena's version was similar to the
    workspace switching code, but we're not going to add keybindings for
    switch-to-screen-n.

  - fix the assertion sanity check instead of just removing it

  - use gboolean instead of int for boolean values

  - space between function call and opening parenthesis

  - entries[i].hidden and entries[i].demands_attention were not
    initialized giving random strange results at times

Other bugs I tracked down or changes I made:
  - As noted previously, I _really_ dislike the Ctrl-Alt-s keybinding.  Given
    that Mozilla and gnome-terminal use Ctrl-(PageUp|PageDown) for activating
    different tabs, I thought Ctrl-Alt-(PageUp|PageDown) would be good
    candidates for activating different screens.

  - The pointer warping was really weird (and it could happen when e.g. doing
    an alt-tab after switching screens too).  I fixed that by just having the
    pointer warping removed for keybinding grab ops.  We never meant to have it
    anyway; we just didn't think about the dual head case.

  - tabpopup.[ch] is kinda weird in that it's part way general, but part way
    hardcoded for window & workspace switches -- and the hardcoding is based on
    an "outline" parameter passed to meta_ui_tab_popup_new().  Passing TRUE for
    this parameter for the screen popup would cause random black outlines to
    appear on the screen (due to being treated like a window switch popup with
    uninitialized window locations), and passing FALSE would cause segfaults
    from trying to treat MetaScreen*s like MetaWorkspace*s.  I had to add an
    enumerated type, use it to replace this outline parameter, and do a number
    of small changes throughout tabpopup.[ch] and a bit of screen.c.

Problems that still exist:
  - The user is interacting with all the screens; but we only show the screen
    switching popup on the one they started on.  Very weird.  We need to come
    up with something better.

  - The ChangeLog entry needs to be updated for the additional changes I made
    (yeah, I was lazy but I didn't want to spend time on it until everything
    else was fixed)

  - The screen switch popup is _really_ slow the first time it is used; is this
    because of loading the gnome-system-monitor icon or something?

It turns out to be important to warp the pointer to the current screen, for some accessibility use cases (especially onscreen keyboard users, where we otherwise confine the pointer to one screen or another).  Can we somehow ensure that the pointer is visible on the currently focussed screen?

Apologies for spam... ensuring Sun a11y folks are cc'ed on all current accessibility bugs.