Comment 66 for bug 150690

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
<email address hidden>

On 23 May 2010 18:41, Oded Arbel <email address hidden> 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.
>