Darren:
Not relevant to this case review since it is about a future release.
If GNOME Shell is "just" the window manager, ie replaces metacity then
can't systems not wanting to (or unable to)use OpenGL window managers
continue to use metacity (or some other lighter weight WM) but have the
rest of GNOME 3 ?
Yes that is the plan.
However, GNOME Shell is really more than "just metacity". You can think
of it as metacity + gnome-panel + gnome-applets. There should be no
problem running the rest of GNOME 3.x with GNOME 2.x metacity,
gnome-panel and gnome-applets for OpenGL users.
Though, to be more accurate, GNOME Shell will likely also provide some
other miscellaneous features. For example, there are plans to
integrate IM features directly into shell to make chatting with others
more integrated with the desktop and to add more sophisticated "recent
documents" features directly into GNOME-Shell. So users using the old
GNOME 2.x metacity, gnome-panel and gnome-applets may miss out on some
of these usability features - they can still run an IM program to chat,
but it just may not be integrated into the desktop as directly or as
nicely as in GNOME-Shell.
Since GNOME 3.x is developing a different "applet" model, there may be
complications moving forward backporting new applet-like features back
to the GNOME 2.x infrastructure. It is hard to say if this will be
much of an issue or not. It mostly depends if new GNOME 3.x applet-like
things get written and there is a desire to backport the features.
There also may be work to keep the GNOME 2.x applets properly
integrated with the GNOME 3.x desktop as things change. For example,
the power-management applet talks via D-Bus to the power-manager
daemon, and if the GNOME 3.x power-manager daemon changes, it might
require updating the GNOME 2.x applet in order to keep using it with
GNOME 3.x.
I would say if this becomes a resource issue, there may be a need to
enhance the GNOME 2.x panel to work with GNOME 3.x applets.
That said, the GNOME 3.x applet model is so undefined at the moment
that it is hard to really predict how this will work out.
2.2.5 The adoption of upower and udisks
From GNOME 2.28, GNOME community starts to use upower and udisks
(previously called DeviceKit-power and DeviceKit-disks) to replace HAL.
A significant amount of work has been done for GNOME 2.30 and the
dependency of HAL will be fully removed in GNOME 3.0.
Gnome-power-manager now depends on upower and has abandoned the
dependency of HAL. Because upower is not shipped in Solaris currently,
we plan to continue to ship gnome-power-manager 2.24 in GNOME 2.30.
Other applications still depend on HAL optionally for GNOME 2.30. So
this is not a big issue for now, but may be a risk for the integration
of some GNOME components in the future.
So what work needs to be funded in the desktop consolidation and other
consolidations to allow the move away from HAL to upower/udisks ?
This seems like potential ARC opinion fodder, but only necessary if the
coordination hasn't already been discussed between the relevant
engineering teams (basically no need for an opinion just for this).
The GNOME Desktop team is working with both the upstream community and
the team at Sun responsible for HAL and we are working to keep pace.
However, it is probably too early to provide any real concrete plans.
The upstream community keeps changing their design and direction, and
their plans do not seem very mature. I think we need to wait and let
the dust settle a bit more to find what work is needed in this area.
Brian
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc@opensolaris.org
