GNOME Bugzilla – Bug 349559
in twinview, Workspace Switcher modifications are applied identically to both workspace lists
Last modified: 2007-06-26 14:25:16 UTC
Please describe the problem: I have a TwinView configuration. In the Workspace Switcher Options Dialog, all changes are applied identically to _both_ Desktops - be it the number of workspaces, their names, ... This should be treated on a _per-Desktop-basis_, instead. Steps to reproduce: 1. Start an X TwinView Gnome session. 2. Apply any modification in the Workspace Switcher Options Dialog. 3. Observe: Actual results: They are identically applied to _both_ desktops at once. Expected results: They should only be applied to that desktop where you modify it's options. Does this happen every time? Yep. Other information: To me, it seems quite likely that the structural problem behind this bug might be related to that of Bug 323169.
The workspace switcher is part of the panel.
Is twinview one big desktop or two different desktops?
Forgot to put the bug in NEEDINFO.
Manfred: ping?
(In reply to comment #4) > Manfred: ping? @ Jens: Sorry. To a user, a comment like "The workspace switcher is part of the panel." is no answer which really encourages to invest into further discussion. To me, this sounded like "the underlying struktures are in descrepancy to achieve this request". @ Vincent: "TwinView" is described in detail in the X documentations ... A quick search supplied evidence that - as time passes by - in between a gentoo howto has been set up: http://gentoo-wiki.com/HOWTO_Dual_Monitors Using two (or more) monitors in twinview setup, I expected them to be two separately configurable workspace environments, Kind regards Manfred ############## examplum gratia: With Matrox G550 dual head AGP Section "Screen" Identifier "Screen0" Device "G550_0" Monitor "Mon-F980" DefaultDepth 16 SubSection "Display" Modes "1600x1200" EndSubSection EndSection Section "Screen" Identifier "Screen1" Device "G550_1" Monitor "Mon-T761" DefaultDepth 16 SubSection "Display" Modes "1280x1024" EndSubSection EndSection Section "ServerLayout" Identifier "SingleView" InputDevice "Keyboard-IBM" "CoreKeyboard" InputDevice "Logi-opt-wheel_at_USB" "CorePointer" Screen 0 "Screen0" EndSection Section "ServerLayout" Identifier "TwinView" InputDevice "Keyboard-IBM" "CoreKeyboard" InputDevice "Logi-opt-wheel_at_USB" "CorePointer" Screen 0 "Screen0" Screen 1 "Screen1" LeftOf "Screen0" EndSection ###########################
(In reply to comment #5) > (In reply to comment #4) > > Manfred: ping? > > @ Jens: > Sorry. To a user, a comment like > "The workspace switcher is part of the panel." > is no answer which really encourages to invest into further discussion. > To me, this sounded like "the underlying struktures are in descrepancy to > achieve this request". Err, Jens was just explaining the change he was doing to the bug. > @ Vincent: > "TwinView" is described in detail in the X documentations ... I'm sorry, but I don't think so: TwinView is nvidia stuff. > A quick search supplied evidence that - as time passes by - in between a gentoo > howto has been set up: > http://gentoo-wiki.com/HOWTO_Dual_Monitors > > Using two (or more) monitors in twinview setup, I expected them to be two > separately configurable workspace environments, > > Kind regards > Manfred > > > ############## > > examplum gratia: With Matrox G550 dual head AGP > > > Section "Screen" > Identifier "Screen0" > Device "G550_0" > Monitor "Mon-F980" > DefaultDepth 16 > SubSection "Display" > Modes "1600x1200" > EndSubSection > EndSection > Section "Screen" > Identifier "Screen1" > Device "G550_1" > Monitor "Mon-T761" > DefaultDepth 16 > SubSection "Display" > Modes "1280x1024" > EndSubSection > EndSection > > Section "ServerLayout" > Identifier "SingleView" > InputDevice "Keyboard-IBM" "CoreKeyboard" > InputDevice "Logi-opt-wheel_at_USB" "CorePointer" > Screen 0 "Screen0" > EndSection > Section "ServerLayout" > Identifier "TwinView" > InputDevice "Keyboard-IBM" "CoreKeyboard" > InputDevice "Logi-opt-wheel_at_USB" "CorePointer" > Screen 0 "Screen0" > Screen 1 "Screen1" LeftOf "Screen0" > EndSection > > ########################### Hrm, it looks like a Xinerama configuration. In Xinerama, the two screens are used as one big screen. See http://en.wikipedia.org/wiki/Xinerama This seems to be why you're seeing this behavior in the pager. Of course, I could be wrong, but if I'm right, it's not a bug.
(In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > Err, Jens was just explaining the change he was doing to the bug. I deeply apologize. From the comment, I couldn't catch any hint to "change to the bug". I'm SORRY !!! > I'm sorry, but I don't think so: TwinView is nvidia stuff. NO. I've been using TwinView configurations with Matrox dual head cards: G400, G450, G550, frolicking with the open-source drivers, actively supporting on the Matrox Linux Forum (user: "mkn", signing with "manfred"). EDIT: Unfortunately, I just discovered that Matrox has closed the forums down: http://www.matrox.com/graphics/en/corpo/support/forums.php (Perhaps, because too many have complained about the downfall of Matrox Linux support?) So all the valuable information is smashed into the trash bin!, and I can't point you to the links anymore. man xorg.conf: " A "server layout" represents the binding of one or more screens (Screen sections) and one or more input devices (InputDevice sections) to form a complete configuration. In multi-head configurations, it also specifies the relative layout of the heads." > Hrm, it looks like a Xinerama configuration. Not to me, as far as I understood. I start with a simple "startx"; not with something like "startx -- +xinerama". There is _nothing_ like this in my xorg.conf: Section "ServerFlags" Option "Xinerama" "true" EndSection > This seems to be why you're seeing this behavior in the pager. > Of course, I could be wrong, but if I'm right, it's not a bug. In case, that would be true, indeed. I will enclose a complete xorg.conf for your convenience (Attachment). Kind regards Manfred --- /cite --- http://en.wikipedia.org/wiki/Xinerama: Xinerama requires that the physical screens have the same bit depth. (...) It is possible to have a multiple display desktop _without_ using Xinerama. In X terminology, a single X server can support multiple "screens". With multiple screens (or displays), each physical screen is effectively independent. You can run different window managers, have a different background image, and run different applications on each physical screen. Some window managers will automatically detect multiple screens, and provide services such as a task bar and window decoration on all screens. This is similar to Xinerama in some ways. (...) Some users prefer multiple displays like this, instead of Xinerama. There are many usability advantages to the independence of each screen, compared with Xinerama's method of a single virtual screen stretched over all physical screens. Some of the advantages: Being sure that new windows always appear on the screen where you launched the application; independent background pictures; independent task bars; notification areas show information about applications associated only with the screen they're on, and so on. All of these are possible with Xinerama too, if they are done by a Xinerama-aware desktop environment with the right features. However, one of the most popular environments, GNOME, although it does have some Xinerama support, is quite poor in the areas described above at the time of writing (GNOME 2.14). Unfortunately, the independence of each screen (which you get when not using Xinerama) has a noteworthy usability problem: There is no way to move windows between the different screens. (...) If there was a way to move windows between screens, the behaviour of multiple independent screens would be nearly ideal for many users." --- /cite ---
Created attachment 90138 [details] xorg.conf: ServerLAyout: SingleView and TwinView
(In reply to comment #7) > (In reply to comment #6) > > (In reply to comment #5) > > > (In reply to comment #4) Postscriptum: Confusingly, e.g. http://wiki.linuxquestions.org/wiki/Using_multiple_monitors_with_XFree86 states: 'Normal' MultiHead -- Every monitor has a different seperate X screen and session
later on, it clarifies: "Now if you start up X, you should have seperate X sessions running on each screen."
When I say TwinView is nvidia stuff, that's because it's a trademark of nvidia: http://www.nvidia.com/object/feature_twinview.html I'm not saying the concept behind twinview is only possible on nvidia cards... Anyway, this part doesn't matter :-) So, it looks like your configuration is dual head. Hrm... Ah, I got it. It's a metacity bug. I've just opened bug 448537 about it. Basically, those settings are owned by metacity, but there is no way to apply them to one screen only. Thanks!
(In reply to comment #11) > When I say TwinView is nvidia stuff, that's because it's a trademark of nvidia: > http://www.nvidia.com/object/feature_twinview.html > I'm not saying the concept behind twinview is only possible on nvidia cards... YEP ... "NVIDIA's TwinView™ Architecture" - "TM": @{roll on the floor} & ; @{roar with laughter} You remember: A short time ago, someone tried to patent the concept of "stack" ... crazy. Yes, in the early days of multi-head graphics adapters, there was quite a confusion between "TwinView" and "DualView" and "MultiView" and - later - Xinerama. In the Matrox Forums, concerning the DualHead Gxx series, more or less a nomenclature converged to use "TwinView" for normal MultiHead (~ DualHead) (for this graphics card adapter) setup to differenciate it to Xinerama "One big screen" (for this graphics card adapter) setup. It became especially nasty to explain in those cases where people wanted e.g. Xinerama on a DualHead G550 AGP combined with MuiltiHead to use an additional older PCI graphics adapter ... > Anyway, this part doesn't matter :-) Sorry, if unconsciously I added chance for confusion ... > So, it looks like your configuration is dual head. Yes. > Hrm... Ah, I got it. It's a metacity bug. I've just opened bug 448537 about it. Ah, Super! EDIT: Just saw the "Duplikate" marking from your 448537 linking to 91797 dating from 2002-08-27 ... clasified as "minor " (!?!) Sorry, although searching before opening my bug in 2006-08-01, I obviously didn't catch that one ... Seems the problem is hanging around quite long, already ... > Basically, those settings are owned by metacity, but there is no way to apply > them to one screen only. Is this, because the internal structures of metacity do not cleanly reflect multiple screens? Or what else blocks clear separation? There are numerous reasons / cases of applications (some already mentioned in 91797 already) where you defenitely _cannot_ work with "one big screen". For some clients, this is a knock-out reason against Gnome rightaway. > Thanks! I want to thank you !!! Kind regards Manfred
@ Vincent: cf. http://bugzilla.gnome.org/show_bug.cgi?id=91797#c14
(In reply to comment #12) > (In reply to comment #11) > > Basically, those settings are owned by metacity, but there is no way to apply > > them to one screen only. > > Is this, because the internal structures of metacity do not cleanly reflect > multiple screens? I don't think it's a problem with the internal structure of metacity. It might only be because of the way the settings are stored in gconf. I'm not a metacity developer, though, so I can't be sure.
Manfred: Can you move windows from one monitor to the other? If so, you are using xinerama (nVidia can call it what they want, but that's what it is in Xorg terminology). If not, you are using separate screens. (I suspect bug 448537/bug 91797 are not the same issue Manfred is annoyed with, but rather that a different bug report is.)
(In reply to comment #15) Hi, Elijah! > Manfred: Can you move windows from one monitor to the other? NO ! > If so ... :: see above --- At the time when I wrote the bug report, I was exploiting highly optimized Gentoo on ASUS Dual PIII with Matrox G550. In between, I'm happily frolicking amd-64 X2 ... the old box was transformed to server usage. O.K. - to make you guys happy: I re-installed the old box, but with current ubuntu 7.04 (to produce an answer more quickly :-), featuring the newer gnome-2.18. SAME RESULT. The adapted xorg.conf will be attached ... Because of a bug in the Matrox firmware, to get the dual head setup working properly, you have to apply a work-around: first startx -- -layout singleview (it would be sufficient and much quicker to just start twm), shutdown the X server, and then again startx -- -layout twinview (now with the desired gnome environment). I have 1600x1200 on the F980, and 1280x1024 on the T761. I can modifiy the panel width/height on both monitors individually. I can individually add applications to the panels. I can ... But when I change the number of virtual screens in the switcher, it is applied to BOTH monitors/(real) screens. And the names can only be changed synchronously. And, as described in 91797, shrinking / re-growing looses the names on both sides. To me, such a behaviour seems ridiculous. > (I suspect bug 448537/bug 91797 are not the same issue Manfred is annoyed with, > but rather that a different bug report is.) Maybe - which one? Kind regards Manfred
Created attachment 90491 [details] with 2 Layouts: SingleView and TwinView=DualHead
Another interesting observation: Setting both screens to the same res., eg. 1280x1024, the "logout, ..." Button appears perfectly placed on the very top right corner of both screens. With different screen res., e.g. 1280x1024 and 1600x1200, on the bigger plane, it becomes placed correspondingly to the corner of the lower res screen. Same applies to the clock an volume icons. For all of them, the "move" option is greyed out. To me, it seems to be related to "lock to panel" property. In contrast, the "Manual network configuration" icon becomes placed on the very top right edge of the primary screen only. Also, clearly, other manually added icons - generated without "lock to panel" - only appear on the panel of the screen where they were created and can be moved around. Nevertheless: Even if I remove the "lock to panel" on both of the workspüace switchers, a change of the number of virtual screens (e.g. reduction from 30 to 20) becomes instantly applied on both screens. Hope this helps for further investigation ... Kind regards again Manfred
@ Vincent: Please, c.f. / follow http://bugzilla.gnome.org/show_bug.cgi?id=91797#c17 ff. And it's not only because of gconf ... The code is reflecting this structure ... just load the metacity tree into your preferred IDE and let it search e.g. for num_workspaces. Even the One-and-Only "meta_workspace_index" is defined as: int meta_workspace_index (MetaWorkspace *workspace); without any dependeny upon (one or more) screens. As sorted out so far, I would be perfectly happy to have this bug marked as a "Duplicate of Bug 91797 – Store per-screen number of workspaces setting". But I really don't understand it being marked as "RESOLVED NOTABUG". Could you please be so kind and explain that to me? Yours Manfred
(In reply to comment #19) > As sorted out so far, I would be perfectly happy to have this bug marked as a > "Duplicate of Bug 91797 – Store per-screen number of workspaces setting". > > But I really don't understand it being marked as "RESOLVED NOTABUG". > Could you please be so kind and explain that to me? Because reopening and marking it as duplicate would send two mails to all the people receiving mails for gnome-panel, and I try to avoid sending such spam when it's not necessary :-)
(In reply to comment #20) > (In reply to comment #19) > ... would send two mails to all ... try to avoid Uuupps ... Yes, I defenetely and wholeheartedly agree! Thanks, Vincent! So I will follow and put any further stuff into Bug 91797. Have a good time!