Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
- From: Sam Spilsbury <smspillaz gmail com>
- To: Johannes Schmid <jhs jsschmid de>
- Cc: Owen Taylor <otaylor redhat com>, gnome-shell-list gnome org, Neil Roberts <neil linux intel com>, desktop-devel-list gnome org, Tomas Frydrych <tf o-hand com>
- Subject: Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
- Date: Tue, 24 Mar 2009 16:17:45 +0900
On Tue, Mar 24, 2009 at 8:18 AM, Johannes Schmid <jhs 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.
>
> I also like that mutter would only keep that code that is based on
> clutter. The RENDER stuff is mostly taken care of by compiz and metacity
> is for non-composited Desktops. All three have their use-cases.
Compiz never used RENDER and has always been a traditionally OpenGL
compositing manager. While there is support to add a RENDER backend in
compiz (it is one of our goals), the likelyhood is that it would not
support the majority of our functionality.
>
> That said, besides testing from time to time (which is restricted by the
> state of current open-source api drivers vs. bad performance on my
> intel-graphik netbook) I am not very involved in gnome-shell
> development.
>
> Regards,
> Johannes
>
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
--
Sam Spilsbury
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]