On Wed, 2009-03-25 at 20:54 +0900, Sam Spilsbury wrote: > On Wed, Mar 25, 2009 at 12:47 AM, Owen Taylor <otay...@redhat.com> wrote: > > On Tue, 2009-03-24 at 16:17 +0900, Sam Spilsbury wrote: > >> On Tue, Mar 24, 2009 at 8:18 AM, Johannes Schmid <j...@jsschmid.de> wrote: > >> > Hi! > >> > > >> >> 2) Mutter could be renamed as a project to mutter (binary, GConf > >> >> schemas, > >> >> etc. Presumably, the internals would stay Meta*) and imported into GNOME > >> >> version control independently of metacity. The uncomposited and RENDER > >> >> code paths would gradually be removed leaving just a Clutter based > >> >> WM/CM. > >> >> The main disadvantage of this approach is that any ongoing maintenance > >> >> of Metacity would not feed from or to this project automatically. > >> > > >> > Actually I am bit in favor of this approach. Having the window manager > >> > and the shell separated has the advantage that they can be used > >> > independently. Think about things like Gnome Mobile or Netbooks - > >> > probably you want a composited wm here but you don't want GNOME Shell > >> > (but probably another shell that is based on a mutter-plugin). > >> > >> Definitely. If the WM and the shell were integrated, it would mean > >> that a severe chunk of functionality would be lost when using other > >> window managers like compiz with GNOME. It's totally possible to > >> separate the shell and the WM and instead abstract calls to the WM > >> with DBUS. That way compiz can have a plugin to support functionality > >> required by gnome-shell. > > > > To try and make GNOME Shell integrate with multiple window managers > > would either greatly constrain the user interface vision or greatly > > increase the amount of work involved. The power of the GNOME shell > > approach is that we are working within the desktop scene graph of the > > window manager/compositor. > > Hi, > > I'm not going to deal with a later remark about compiz, because I > don't feel that this is what this discussion is about (Even though I > am a compiz developer). > > We at compiz actually had a discussion over the phone with all the > developers, including those at Novell about the future direction of > our project and what our place would be (especially with the recent > KWin and GNOME-Shell projects). It would be difficult to have any sort > of position within the desktop if those two projects were to take > hold, however it would be very disappointing to see a lot of code be > dropped, especially considering that it may not see a life in KWin or > Mutter/Metacity-Clutter/GNOME-Shell. > > We decided that KWin was not going to be a huge issue for us - it is > perfectly up to the user to decide which WM they want to use, and if > they used either, we believe there would be no significant loss in > functionality. > > GNOME-Shell on the other hand is a far greater issue for us. While I > believe the panel will be kept around until 3.2, after that point, if > users were to use compiz with GNOME, they would lose a significant > chunk of essential functionality. > > This is the dilemma I am sure a lot of other desktop-agnostic window > managers are facing as well. It would essentially mean that users > _must_ use your window manager in order to use their desktop as > normal. > > A lot of window managers are starting to tinker with compositing, and > the functionality as far as I can see is easily achievable with any > window manager. If GNOME-Shell were made into a library, then it would > be possible for normal compositing window managers such as Mutter and > Compiz to hook into events generated by that library and do all the > effects themselves. This is certainly a much better approach than what > we had originally planned - which was duplicate code from GNOME-Shell > into a compiz plugin so that users don't lose functionality. > > I understand that GNOME-Compiz relations have been rather sour > recently (and it has been, up until last year, a dilemma we face with > KDE), however working together on this one would be a great step > forward between a productive relationship between the two projects.
GNOME Shell is an integrated window manager, compositor, and application launcher. This integration isn't some coincidental thing,it is basic requirement of the user interface thing GNOME Shell depends on two things: - Metacity's basic window management code: property fetching, stacking, etc, etc. - The Clutter OpenGL scene graph Now, of course Compiz has window management code. And it knows how to draw a scene with OpenGL. So we could have written GNOME Shell on top of Compiz, but for various reasons we didn't. Create some sort of "window management abstraction layer" and "scene graph abstraction layer" is what I mean by "greatly increase the amount of work". And by "greatly", I don't mean 20%, I mean multiple times the work. Because any time we wanted to do anything that involved the parts beneath the abstraction layer, we'd have to get the Compiz and Metacity and Clutter developers to all agree. And there would be no point. If working on top of Compiz was the right way to go, then we should have done that. Doing it both ways would have no benefit for all that pain. The code that's running beneath the user interface makes no difference to the user. And it's not like that in this hypothetical world you get GNOME Shell plus all the Compiz stuff that you normally have. GNOME Shell *conflicts* with the standard Compiz plugins. The scale plugin makes no sense when GNOME Shell already does that in the overlay. Putting your workspaces on a cube makes no sense when the overlay shows them in a grid, and so forth. 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. - Owen _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
