registry team mailing list archive

[Paul Beardsell <paul@xxxxxxxxxxxxx>]

I had not realised I was criticising you so very personally as to provoke
that outburst.

Perhaps it is you who misunderstand.  The current workaround for this bug is
to disable compiz.  But, one has to ask, and this is my point:  Why should
compiz even have the opportunity of breaking workspaces?  Were the
underlying design better then compiz would need to know *nothing* of
workspaces.  A way, perhaps, to have a better design, would be to have the
workspace functionality built in at a more fundamental lower level within
Gnome etc.  Perhaps my suggestion is flawed, perhaps not, BUT either way:
that compiz breaks this aspect of workspace functionality shows something is
wrong - something is too closely coupled to something else.

And, whatever you say, it would be very neat to have the various workspaces
addressable as :0.0, :0.1, :0.2 etc etc  This suggestion would not break the
thin client functionality to which you allude.

Paul Beardsell


On 24 May 2010 10:09, Oded Arbel <oded@xxxxxxxxxx> wrote:

> On Sun, 2010-05-23 at 17:17 +0000, Paul Beardsell wrote:
> > 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?
>
> I would like you to know that multiple X servers on a single box are
> used heavily in enterprise and academic installations to run thin X
> clients, and multi-screen X servers (not Xinerama) are used to provide
> multiple consoles on a single desktop computer in many educational
> installations as well as a few home installations I've seen.
>
> Please don't knock off existing functionality just because you don't
> understand what it is used for - it is often there to provide for a
> legitimate need that cannot be satisfied otherwise, even if you have not
> personally have required it.
>
> > If that was sorted then this bug would not exist in
> > its current form i.e. with a workaround simply being to disable Compiz.
>
> I don't agree, and I think the implementation details for workspace
> management and paging should stay firmly inside a specific WM's
> implementation. I might be a good idea to specify a freedesktop.org API
> for pagers to talk to window managers, but if you've hardcoded in a spec
> how workspaces should be implemented then a lot of cool things like
> GNOME Shell's dynamic workspaces wouldn't happen (or be so much harder
> to implement).
>
> --
> Oded Arbel <oded@xxxxxxxxxx>
>
> --
> 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 Registry
Administrators, which is the registrant for libwnck.