I'm not sure I would change hardly a word of my posting. It seems to me the multi-monitor Unix systems I was lucky enough to work on sometimes in the 1990's could have been implemented just as poorly as the multi-workspace idea we have in Gnome and similar on Linux. But they were not. If I wanted an app's display to open on a particular workspace on a monitor I could do so by specifying '-display xxxx:0.3' or to choose a particular monitor I could use '-display xxxx:3'. We miss a trick or two now. And whereas implmentation details are left unspecified the intention is clear. Where and when do we get the opportunity to use anything other than :0.0 on a modern Linux box, now? If that was sorted then this bug would not exist in its current form i.e. with a workaround simply being to disable Compiz.
Paul Beardsell p...@beardsell.com On 23 May 2010 18:41, Oded Arbel <o...@geek.co.il> wrote: > Paul Beardsell wrote: > > In my opinion the whole workspace thing is a hack implemented against the > > way X is supposed to work. Each workspace is not traditionally > addressable. > > E.g. I cannot choose which workspace/pane my windowed application opens > in > ... > > fails with an error. In my opinion > > > > xterm -display :0 & > > > > should best open in the first (or, better, current) workspace on the > current > > X server > > > > xterm -display :0.0 & > > > > should open in the 1st workspace and > > > > xterm -display :0.1 & > > > > should open in the 2nd etc > > I think you have a misunderstanding of how the display parameter works - > from 'man X': > ---8<--- > DISPLAY NAMES > From the user's perspective, every X server has a display name of the > form: > > hostname:displaynumber.screennumber > ... > screennumber > Some displays share their input devices among two or more > monitors. These may be configured as a single logical screen, which allows > windows to move across screens, or as individual screens, each with their > own set of windows. If configured such that each monitor has its own > set of windows, each screen is assigned a screen number (beginning at 0) > when the X server for that display is started. If the screen number is not > given, screen 0 will be used. > ---8<--- > > In a nutshell, X11 allows you to address a machine, then a server on > that machine, then a specific logical screen on that server (for example > when running with dual monitors and without Xinerama). Window managers > add on top of that the notion of workspaces, but it was never something > inherent in X. Granted different window manager implement workspaces in > different and conflicting manners, but that is not because of some > misuse of X semantics. > > Freedesktop.org's window manager spec (EWMH) has this to say about > workspaces ( > http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#id2552820): > ---8<--- > This spec assumes a desktop model that consists of one or more completely > independent desktops which may or may not be larger than the screen area. > When a desktop is larger than the screen it is left to the Window Manager if > it will implement scrolling or paging. > ... > Window Managers that require / desire additional functionality beyond what > can be achieved using the mechanisms set out in this specification may > choose to implement their own pagers, which communicate with the Window > Manager using further, window manager specific hints, or some other means. > ---8<--- > > In a nutshell "we don't know what to tell you, go ahead and do what you > want". Oh well. > > -- > Can't drag a window to another workspace > https://bugs.launchpad.net/bugs/150690 > You received this bug notification because you are a direct subscriber > of the bug. > -- Can't drag a window to another workspace https://bugs.launchpad.net/bugs/150690 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
