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. Kind Regards, Sam Spilsbury > > Using Compiz to create a GNOME desktop using GNOME applications, the > GNOME control-center, and so forth will of course remain possible. We > have no current plans to create hard dependencies on GNOME Shell within > the GNOME desktop (just as there are no hard dependencies on gnome-panel > now.) > > - Owen > > > -- Sam Spilsbury _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list