Re: Metacity, Mutter, GNOME Shell, GNOME-2.28

[Sam Spilsbury <smspillaz gmail com>]

On Tue, Apr 7, 2009 at 5:23 AM, Owen Taylor <otaylor redhat com> wrote:
> On Mon, 2009-04-06 at 17:37 +0100, Alberto Ruiz wrote:
>> 2009/4/6 Jason D. Clinton <me jasonclinton com>:
>> > On Mon, Apr 6, 2009 at 10:34 AM, Tomas Frydrych <tf linux intel com> wrote:
>> >> mainstream user. There are good reasons to provide legacy support, and
>> >> it's great to be able to run GNOME on a machine that is 5 years old, but
>> >> it must be seen for what it is -- legacy support, it cannot be where the
>> >> collective effort of GNOME should be concentrated.
>> >
>> > Actually, compositing requirements are fairly low. A machine that's
>> > five years old would be right on the border of being supported. The
>> > Intel 915 chipset with GMA 900 was released in June of 2004.[1] While
>> > there aren't a lot of people out there testing on this older hardware,
>> > it's supported by the same `intel` driver used on the newest Intel
>> > chips. airlied (and Red Hat) is doing great work on the DRI2 driver
>> > for R200/R300 ATI chipsets. And for the newest ATI/NVidia stuff,
>> > there's always the proprietary option (regrettable though it may be).
>>
>> You are missing the remote desktop scenario here. This is not only a
>> matter of working on old hardware, being able to run gnome smoothly on
>> a thin client solution through XDM, or VNC, or whatever is also
>> needed.
>
> I've already answered this previously: Composited desktops may not well
> with today's network protocols, but that's a software issue, nothing
> inherent to thin clients.
>
> I have no sympathy for the complaint that nobody has been working on it
> and we just have to live with VNC and remote X (*). If we care about
> thin clients, we have to compete on today's terms. We can't compete on
> yesterday's terms and hope that will be good enough.

VNC as been obsoleted by RDP anyways - however you can split your
output backends into plugins (like compiz) and either autodetect/allow
the user to drop to non-3D mode.

>
> But in the end, what we do for GNOME Shell doesn't come down to what we
> think would be nice to have, it comes down to what we write the code to
> do. Writing two versions of GNOME Shell, one using modern technology and
> one using ancient technology, and then switching between them depending
> on the available hardware is a big project. Not one person has showed up
> with an interest in working on this.
>
> If someone shows up and thinks this is how they want to spend their
> time, I'm certainly willing to discuss how that can be accomplished.
>
> - Owen
>
> (*) Of course, Novell _has_ done some work on this in the context of
> Compiz recently. And even results with plain old remote X and remote GLX
> are surprisingly good; that's my understanding of how the City of Largo
> is using Compiz.

This is fairly easy to implement AFAICT - you just need something
handle the DMX and RDP channel transmission via the local instance of
mutter and the remote one. The only gotcha with this is that you need
to write code that would have windows in a 'tree' and make all the
code aware of that tree.

On a side note - I'll be doing some work to see if we can abstract the
panel drawing bit of gnome-shell into a lib that will draw under any
openGL context. The actual gnome-shell plugin will display the
rendered shell onscreen and also handle the animation of the 'overlay'
mode. I think this can be done by setting a few function callbacks to
notify when certain animations need doing.

A bit of work needs to be put into separating the code out (i.e
separating clutter contexts, etc) but hopefully it should all work
out. I think the situation we want to avoid here is that other
composite window managers need to fork / rewrite the code in order
that users don't lose functionality when they want to use their window
manager with GNOME.

Such a design would be easy to implement in compiz via it's plugin system.

Kind Regards,

Sam Spilsbury

>
>
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>



-- 
Sam Spilsbury