Re: gnome-panel & gnome-applets?

[Brian Cameron <brian cameron oracle com>]

Emmanuele:

On 12/28/10 10:50 AM, Emmanuele Bassi wrote:
> On Tue, 2010-12-28 at 13:42 +0000, Sergey Udaltsov wrote:
> > > As pointed out before the fallback-mode is not a continuation of
> > GNOME 2. It was just the easiest way to create a fallback because we
> > don't have the resources to create a non-3D shell that could act as a
> > fallback. As we have gnome-panel already it was choosen as the
> > fallback mode.
> >
> > Is it an indication of a problem in gnome3 architecture?
>
> I don't see any "problem" here.

I agree that there is no problem with GNOME moving towards OpenGL and
acceleration.  As you suggest, this is clearly the path to the future.
However, there still are issues that the GNOME community needs to
consider.

For example, I have concerns about how GNOME 2.x is going to be
maintained in the long run, and I think a lot of issues raised in this
discussion relate to such concerns.  To me, it seems that GNOME 2.32
and later 2.x releases were developed as transitional releases moving
towards GNOME 3 without a clear roadmap for how GNOME 2 will be
supported long-term.

To me it is not clear whether those who intend to deliver GNOME
2.x-based solutions should ship GNOME 2.30, 2.32, some random mismash
of module versions that you are able to get working, or what.  It also
is not clear what role(s) the GNOME community will play in helping
different distros who ship and support GNOME 2 to work together and
collaborate in that effort.

I can understand that, at the moment, the GNOME community is more 
focused on getting GNOME 3 done right rather than focusing on long-term
support issues with GNOME 2.  However, in time, I think that GNOME 2
support issues will become an increasingly important issue that will
require attention.  Perhaps through getting distros who need to support
GNOME 2 to collaborate together effectively, some of these questions
about the future of the GNOME panel, applets, etc. can be worked out.

> >   Is it simpler to maintain extra modules than to scale mutter and
> > gnome-shell down?
>
> define "scale down".
>
> if your definition of "scale down" implies "do not use hardware
> acceleration" then the answer is obviously no. that's the whole point.
> the whole graphics stack (cairo, x11, gtk) is trying to be as hardware
> accelerated - it's not a "new thing".
>
> the "scaled down" version of mutter is metacity with the default,
> xrender-based, compositor; but mutter is just providing the window
> management infrastructure for gnome-shell - and you simply cannot
> implement the gnome-shell designs using a non-hardware accelerated
> environment.

It is obviously not possible to provide OpenGL-based animations when
OpenGL is not available.  However, I would think that it could be
possible to create a GTK3 based user interface that provides the basic
functionalities of GNOME shell without the animations.  Such an
interface could be designed to resemble GNOME shell more than the
existing GNOME 2.x panel even if it does not provide as rich of an
experience.  So I disagree with your assessment that "you simply cannot
implement the gnome-shell designs using a non-hardware accelerated
environment".  If someone has the motivation to try, I think they
should not be discouraged.

Though, as you seem to suggest, it might not be worth the effort.  It
perhaps does make good sense to just use the existing GNOME panel and
mutter for users who need a "scaled down" experience.

While it may not be possible to have the GNOME 3 "GNOME Shell"
experience and the "classic GNOME" experience working together today,
I suspect that the technical issues will be worked out if there is a
real need to provide ongoing support for both together.  For example,
if there is a need to maintain the old GNOME panel and metacity so it
only supports D-Bus based applets or works with new GSettings
infrastructure, it could be done.

Perhaps a GNOME 2.34 release might be something to consider at some
point if there is enough interest to continue working on GNOME 2.x to
make it inter-operate better with GNOME 3, for example.  A lot of these
sorts of decisions, though, cannot really be made until it is more
clear how much ongoing investment will be made in GNOME 2.x.  But
perhaps the GNOME community could do more now to make sure that all
options are open for consideration and by being more accommodating to
discussion.  Things may seem impossible now simply since it is not
clear how such efforts will be resourced, but this could easily
change as GNOME evolves and if there is a real need.

Brian