GNOME Bugzilla – Bug 91980
[Solaris Multihead] Keyboard shortcuts do not operate correctly in multihead mode
Last modified: 2004-12-22 21:47:04 UTC
Solaris 8 fcs, multihead non-xinerama mode, Gnome SUN beta2 build4 On screen 0 open gedit in workspace1. On screen 0 open gnome-calculator in workspace 3. On screen 1 open ghex in workspace 1, On screen 1 open character map in workspace 3. On screen 0 switch to workspace 1, select ctrl-alt-right and select workspace 3, you should now see gnome-calculator on screen 0. Select workspace 1 on screen 0, you see gedit on screen0. On screen 1 select workspace 1, you see ghex on screen 1. On screen 1 press ctrl-alt-right and select workspace 3. (You should now see gedit on screen 0 and character map on screen 1.) ERROR the user sees gnome-calculator on screen 0 and ghex on screen1. Note: intermittently using the ctrl-alt-right key does not work on screen 1 the user needs to use the ctrl-alt-up and down keys to move between workspaces.
This is a metacity bug reassigning to the correct category.
Please check my observation ... When metacity comes up, while the first meta screen is created (in meta_screen_new), 1. A new workspace is created ("Workspace 0") and activated. 2. After that it reads the number of workspaces(say there are 4 workspaces) and updates the first meta screen with workspaces 1,2,3. Then for the second screen again it 1. Creates a new workspace (which becomes "Workspace 5") and activates it. 2. Then it reads the number of workspaces and checks for the screen (w->screen == screen in screen.c:790). Since this will fail for second screen, new workspaces 6,7,8 are created. In the second screen when we select next workspace (by Alt+Ctl+Right from Workspace 5 to Workspace 6), since the active_workspace number is higher than total number of workspaces (in our case 4), by modulo it is changed (i.e.active_workspace is changed from 5 to 1). Since the workspace has changed from 5 to 1, the screen is also changed from screen 1 to screen 0 (because MetaWorkspace has the field screen) Now all the updations such as atom_net_current_desktop, changing the windows of the workspace etc are happening for the screen 0 rather than screen 1. We may Make MetaScreen have its own workspace list details rather than workspace having screen detail Get the current screen by querying instead of using the workspace->screen changing the workspace in one screen changes the workspace in all other screens
Pretty big if we actually want to tout multihead for 2.2.
Havoc can any please give your input!
Can someone please tell me how workspaces work in multihead in dtwm or other window managers?
Let's just dup this on the generic "figure out multihead workspaces" bug. I would still appreciate someone writing down how dtwm works in this case. *** This bug has been marked as a duplicate of 91797 ***
As requested by Havoc, here is how dtwm handles workspaces on multihead support: - dtwm keep a separate list of workspaces for which screen it manages on the display. This means : - one can was an arbitrary number of workspaces on each each screen. - each workspace is unique, this means that there is no relation between workspaces on different screens. Here is a little background on how people often use multihead setups instead of xinerama. Multihead setups are often used by : - CAD engineers : they have one or two screens with hardware acceleration to render there designs (e.g. 32 bits stereo mode or hardware opengl acceleration) and one or more "normal" screens (8-24 bits without acceleration) to display the "toolbox", terminals and productivity apps. - TelCo & co: they use one screen to monitor the system (e.g. graphic map of the system) and the other screens for the options (e.g. a set of dialog boxes). - Stock traders : they usually use 3 screens, 2 to monitor the trands (e.g. realtime graph) and one to place orders and communications. So in this context it makes sense to have completely unrelated workspaces on each screen. HTH, Erwann
Thanks Erwann!