GNOME Bugzilla – Bug 325225
Big usability problems with more than one screen
Last modified: 2008-03-23 23:39:08 UTC
Hi. In those days it is not longer rarely to find users with more than one monitor connected to their computer. Most modern graphic cards already support two monitors and if not, buying a second card is not that expensive. LCD Monitors are quite affordable, too. Ok,... this christmas ;-) I bought me a second monitor and now I'm having the following configuration: Eizo FlexScan L767 and LG Flatron 1950H both connected to an Asus Extreme N7800GTX... The Eizo is left of the LG. Ok, as far as I could see, there are three ways how to use those two LCDs with one PC: 1) Use Nvidias "TwinView" stuff... + This has the advantage that X (and of course GNOME) does not even realize that there are more than one display. It simply thinks that you have an display with a resolution of (in my case) 2*1280 x 1024. + You can drag windows from one display to the other, they can even reside with on both displays (that's not such a big advantage for me, as of my display positioning). - BIG disadvantage: That's not the way that X intends to use more than one display. X has that separation between host:display.screen (see the DISPLAY environment variable). => That should be reason enought NOT to use it ;-) - One can not use different resolutions on his screens... this is especially bad if you use for example WineX which switches the resolution in fullscreen mode for several games. - X, GNOME, etc. considers both screens as one desktop which is in my opinion ab big disadvantage. The main reason therefore is: As nearly everybody, I'm using virtual desktops in GNOME. But it is very rarely the case that I have one window, that I'd like to see on both monitors (which window need so much space?). Even if I'd had such windows (e.g. my programming editor or so) it would look very ugly due to the space between the screens. I'd prefer having on both screens seperate sets of virtual desktops. Which I can select independently, e.g. on monitor 1 I have virtual desktop 3 on monitor 2 I have virt. desktop 8. 2) Don't use TwinView but use Xinerama This is essentially the same as using TwinView, but as far as I understand it is not as performant. 3) Use two X screens (without Xinerama or similar stuff) Ok from now I should use the correct X terminology: Display is the whole thing that X controls. Screen is tha part of each monitor. First of all, this 3) is the way that I've decided to use: - Mainly because I don't want to have one big desktop, but I want to have two equal sized desktops. - this is the native X way of doing it. Ok,.. but - and this is the reason why I'm writing - HELL this doesn't work very well with GNOME. ############################################################################### Virtual Desktops: Ok it is possible to have different virtual desktops for each screen using solution 3) but... BUG/MISSING FEATURE: One can not set different number of virtual desktops for each screen. e.g. screen 0 has 8 virtual desktops but screen 1 only 4 BUG/MISSING FEATURE: One can not set different names for the virtual desktops of each screen. ############################################################################### Moving Windows between screens: Ok,.. it is clear that using 3), on window cannot reside on both screens (as with Xinerama or Twin View). It has to be either fully on screen 0 or screen 1. but: BUG/MISSING FEATURE: Metacity should allow to move the whole window to another virtual desktop on another screen. Currently one have the following structure (e.g. when right clicking on th title bar): +---------------------------+ |... | | | |... | | Move to Another Workspace >---------------------------------+ +---------------------------+ Workspace 1 (on current screen) | | Workspace 2 (on current screen) | | Workspace 3 (on current screen) | | Workspace 4 (on current screen) | +---------------------------------+ Imagine the following configuration: 3 Screens (0-2) Screen 0: 5 Virtual Desktops Screen 1: 4 Virtual Desktops Screen 2: 3 Virtual Desktops A user should be able to select between the following possiblities: (on a Window on Screen 1) +---------------------------------------------------------+ + Workspace 1 (on current screen which is 1 in this case) | | Workspace 2 (on current screen which is 1 in this case) | | Workspace 3 (on current screen which is 1 in this case) | | Workspace 4 (on current screen which is 1 in this case) | | - - - - - - - - - - - - - - - - - - - - - - - - - - - - | | Screen 0 >| => expands to the workspace submenu of screen 0 (=> Workspaces 1-5) | Screen 2 >| => expands to the workspace submenu of screen 0 (=> Workspaces 1-3) +---------------------------------------------------------+ or: +---------------------------------------------------------+ + Workspace 1 (on current screen which is 1 in this case) | | Workspace 2 (on current screen which is 1 in this case) | | Workspace 3 (on current screen which is 1 in this case) | | Workspace 4 (on current screen which is 1 in this case) | | - - - - - - - - - - - - - - - - - - - - - - - - - - - - | | Workspace 1 (on current screen 0) | | Workspace 2 (on current screen 0) | | Workspace 3 (on current screen 0) | | Workspace 4 (on current screen 0) | | Workspace 4 (on current screen 0) | | - - - - - - - - - - - - - - - - - - - - - - - - - - - - | | Workspace 1 (on current screen 2) | | Workspace 2 (on current screen 2) | | Workspace 3 (on current screen 2) | +---------------------------------------------------------+ or: +-----------+ + Screen 0 >| => expands to the workspace submenu of screen 0 (=> Workspaces 1-5) + Screen 1 >| => expands to the workspace submenu of screen 1 (=> Workspaces 1-4) | Screen 2 >| => expands to the workspace submenu of screen 2 (=> Workspaces 1-3) +---------------------------------------------------------+ So much for moving (complete windows between screens and virtual desktops,..) btw. the same must apply for keyboard shortcuts,.. this must be expanded to: Keyboard shortcut for workspace x on screen z. ... ... Keyboard shortcut for workspace x on screen z. ############################################################################### Focus issues.... A) Switching Focus via Keyboard -WITHIN a virutal desktop one can switch the focus using Alt+Tab (if configured default) and Alt+Shift+Tab. -With a lot of configurable keyboard shortcuts one can switch to/traverse between several virtual desktops within one screen (e.g. I have F1 for virtual desktop 1, F2 for #2, etc.) BUG/MISSING FEATURE: GNOME/Metacity (or what else is responsible for) should provide a way to switch to/traverse between screens. This means: Configurable keyboard shortcuts for: -Switch to screen #x. -Switch to previous screen. -Switch to next Screen. Perhaps some visual animation should show WHICH screen is now selected. B) Focus when creation new Windows. This is a big problem, I know, because of different focus models (normal, sloppy, etc.) and so on. At least in normal mode, the following should apply: - A window is created on the virtual desktop withing that screen that the creation application resides (I think this is already the standard, isn't it?). - If a new application is launched the window is created on the desktop of the window that has currently the focus (I think this is already the case) BUG/MISSING FEATURE: For that last case, when a new application is launched the users should be able to specify if, or if not, the window is created on the SCREEN on which the mouse currently is. So one would have the two options: - Create windows from NEW applications on the virtual desktop on the screen where the currently focused window is. or - Create windows from NEW applications on the virtual desktop on the screen where the mouse is. ############################################################################### Idea for a new panel applet an or general functionality: Now you have the following: Every SCREEN has different number/names of virtual desktops, each can be selected independently. There should be keyboard shortcuts and an panel applet (looking similarly to the workspace switcher) tha allows the define presets of combined virtual desktops (of different screens). E.g. -selecting preset #1 (via hotkey or via applet) automatically swithces to virt. desktop 1 on screen 0 and virt. desktop 3 on screen 1. -selecting preset #2 (via hotkey or via applet) automatically swithces to virt. desktop 1 on screen 0 but virt. desktop 8 on screen 1. etc. ############################################################################### Probably panel related bugs (I'm not sure): A) It happens very often (haven't figured out how to reproduce yet) that applets of a type (e.g. system monitor) crashes on panels of BOTH SCREENS at the same time. B) One can not move panels between screens C) One can not move applets/etc. between panels on different screens Both, B and C should be possible with drag&drop. More serious errors: D) Several applets don't work well if they're not on screen 0. E.g. I'm using the Lunar Clock applet. If I right click and "Preferences" every thing is ok, but if I select the 2nd tab in the preferences window ("Location") it crashes (only the applet). Not, this is not the case when the applet is on Screen 0, I cannot imagin that the problem is in the applets code. E) Problems with the panels itself when not on screen 0. e.g. I have a panel on my right monitor (Screen 1). When I right click that panel select "Preferences", it still works, but when I select the 2nd tab "Background". ALL panels and the applets/etc. on ALL screens crash (but immediately reload). But of course, the panel properties window is gone, too. ############################################################################### One last desperately needed feature It should be possible to create a hmm let's call it barrier between the screen borders. Imagine my configuration: +-----++-----+ | S 0 || S 1 | +-----++-----+ When I move the MOUSE from 0 to 1 it should be configurable how long (e.g. 100 ms) I must push the mouse agains the border until it really moves to screen 1. This should be configurable for each border independently. E.g. when moving to a screen above Screen 0 (ok in my example ther is no such screen) the delay should be uhm 42 hours (would be fun, eh?) ;-) If one uses this TOGETHER with the virtual desktop traversal (there is a plugin I think) we must think how the whole thing should work the best, i.e. when moving to another virt. desktop on the same screen, and when moving to another screen (and to it's current virtual desktop) ############################################################################### Puhh,.. much work... Some things I'd like to say in the end,... First of all I'm still using Gnome 2.10 (thanks to the slow folks at debian ;-) ).... But please don't flame me,... I think most of the issues I talked about are the same in 2.12. At least I could nowhere read anything about improved multi-screen behaviour.... Second, I'm not sure if this is the perfect place to post the whole stuff, perhaps one could suggest me an appropriate mailing list.... Last but not least, you may contact me via email (calestyo@scientia.net) or via IM: ICQ: 104576 Yahoo,AIM: calestyo Jabber: Sorry my server is down at the moment. Best wishes, Chris.
| Workspace 1 (on current screen 0) | | Workspace 2 (on current screen 0) | | Workspace 3 (on current screen 0) | | Workspace 4 (on current screen 0) | | Workspace 4 (on current screen 0) | | - - - - - - - - - - - - - - - - - - - - - - - - - - - - | | Workspace 1 (on current screen 2) | | Workspace 2 (on current screen 2) | | Workspace 3 (on current screen 2) | Must be corrected to: | Workspace 1 (on screen 0) | | Workspace 2 (on screen 0) | | Workspace 3 (on screen 0) | | Workspace 4 (on screen 0) | | Workspace 4 (on screen 0) | | - - - - - - - - - - - - - - - - - - - - - - - - - - - - | | Workspace 1 (on screen 2) | | Workspace 2 (on screen 2) | | Workspace 3 (on screen 2) |
One additional BIG problem I forgot... *g* It's perhaps panel related to... There is that system notification applet (very important for stuff like gaim/gnomemeeting and so).... The problem is: If the applet is on screen 1 (i.e. not on the screen 0),... applications (tested with gaim, gnomemeeting) don't recognize it. I've tested the following: - Notification applet on screen 1: -application launched with --display=:0.0 -application launched with --display=:0.1 (both does not work) - Notification applet on screen 1 and 0: -application launched with --display=:0.0 -application launched with --display=:0.1 (both does not work) btw: is it possible on startup to specify which on virtual desktop the application should be placed I*ve seen that I can controll the position via geometry=, the screen via display= but no such thing for virtual desktop. Best wishes, Chris.
Thanks for putting the time and effort into checking all these issues. Please note though that there should only be one issue filed per bug report. Additionally, bugs in applets or other programs should be filed in the location for those programs instead of against Metacity. It would also be helpful if you could check bug 324772 and bug 324773 to see if the Metacity bugs you are mentioning are already filed. Is there any chance you could split this up into separate bug reports and close this one? It'd be much appreciated!
Note that what you really want is TwinView. Nvidia provides an xinerama extension for TwinView so that metacity and GTK will know all about the separate monitors. This is how most people use multihead and it's really a _lot_ nicer.
No,.. first of all,... you cannot have seperate virtual desktops with this, and using sticky flag is no a solution to this problem. And as i said, in my opinion using several screens should be the default way. One exception is only,.. if a user want do put several monitors (with very very very slim edges) together to get one big monitor (e.g. for watching tv or so)... I've already tried TwinView in combination with the Xinerama stuff and real Xinerama alone,... but it's NOT what i want.
The way xinerama is implemented in metacity there is absolutely zero advantage to not using it compared to true multihead. Everything will work much better in that configuration. You talk a lot about windows filling up all the xinerama screens at the same time. This indicates to me that you haven't really used a properly-configured xinerama setup before, since by default metacity makes it somewhat difficult to actually cause that to happen. Windows will maximize to fill one xinerama only. You can have panels and the like that are on only one xinerama at a time. The only thing you mention is independent workspaces for the separate screens, which seems like a pretty minor issue. Most of the issues you mention are impossible to fix in true multihead. The two displays are truly independant. You can't generally move a window to the other display. You can't generally choose which display the window will start on. The displays are separate so things like the notification area aren't going to work well. You mention several things that aren't metacity-related. The fact that true multihead support in metacity doesn't work very well is a good indication that nobody uses it. It's very likely moving forward that unless somebody steps forward and decided to fix true multihead that it will always remain slightly broken, just because it gets tested and used much less often. That, and the fact that true multihead is an old clunky way to do it and is really largely deprecated.
This has stayed in NEEDINFO for three years. It's clearly an invalid bug because it addresses four or five separate issues. Reporter, please raise a bug for each issue; if you'd be good enough to check whether such a bug exists already, that'd be lovely, but if you're busy that's not entirely necessary.