On Tue, Mar 31, 2009 at 3:23 AM, Alberto Ruiz <ar...@gnome.org> wrote: > 2009/3/30 Ted Gould <t...@gould.cx>: >> On Wed, 2009-03-25 at 12:07 -0400, Owen Taylor wrote: >>> So, basically, no I don't see a way that GNOME Shell coexists with >>> Compiz other than as two separate shells for the GNOME desktop. >> >> And I think that coexistence is part of the problem with GNOME Shell >> becoming the default GNOME interface. Distributions need something that >> can gracefully decline between a composited and a non-composited >> environment. Not saying that Compiz can do that today, but we >> effectively get that with the combination of metacity and Compiz and >> lots of nasty hacks. But, overall it works.
It can, see compiz 0.9.x (admittedly this is the new development branch and won't be stable for a while but it _can_ do it, if the opengl or composite plugins can't initialize for whatever reason compiz just falls back to being a normal WM and all the bling plugins aren't loaded. >> >> For a GNOME Shell like project to be successful it will need to have >> either two backends or some sort of architecture that would allow for >> GNOME Shell features to be integrated in other less featureful >> shell-like tools. > > I don't get why that statement is true. For a GNOME Shell project to > be successful, it hast to be freakin good. > Mac OS X and Windows XP are way far more successful desktop > environments than GNOME or KDE are, and they don't even have the > notion of swappable windows managers, and if they do, none uses them. > > So what's your point here? See KDE. They've abstracted a lot of their stuff and made special efforts so that it works with other composite window managers. > >> While I love many of the concepts being explored and have suggested >> ideas for some of them, I just simply can't see the currently >> incarnation of GNOME Shell being the default for GNOME. >> >> --Ted >> >> >> To be frank in the end, unless we see some kind of co-operation we are going to have to take a really bad route, which is forking shell so that compiz users aren't unfairly locked out of half of their desktop functionality when using future GNOME versions - I'd really hate it to come down to this. >From what I can see with the code, I know so far that gnome-shell is really just a plugin to gnome, making the job of abstracting it about 100 times easier. I don't think there needs to be a specific dependency on Mutter's scene graph - the shell isn't really transformed in any way, so it can just use the GL context and spawn another clutter context in which it draws on top. The idea would be to make your plugin a wrapper to the lib, so that the lib doesn't depend on mutter and the plugin is linked to the lib. We can do something similar in compiz as can a lot of other window managers. I was told however, that there were some javascript bits and bobs in the code which would make the task harder - but I couldn't find them in the source. Could anybody point me to these? _______________________________________________ >> desktop-devel-list mailing list >> desktop-devel-list@gnome.org >> http://mail.gnome.org/mailman/listinfo/desktop-devel-list >> > > > > -- > Un saludo, > Alberto Ruiz > _______________________________________________ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > Kind Regards, -- Sam Spilsbury _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
