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 <o...@geek.co.il> 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 <o...@geek.co.il> > > -- > 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
