GNOME Shell on OpenSolaris

With GNOME 3.0 around the corner, GNOME Shell is one of the exciting new usability enhancements that is being worked on. For the past few weeks, I have been working to get GNOME Shell building and running on OpenSolaris, and here is a screenshot of it running on Solaris build 112.

At the moment, GNOME Shell is still in development, so it is not fully polished yet. That said, I find that my desktop is still quite usable with GNOME Shell installed. GNOME Shell depends on GObject Introspection which is an exciting new piece of GNOME infrastructure, making it easier to generate language bindings. By installing GNOME Shell you can also experiment with this new GNOME feature.

At some point in the near future, I hope to make binaries available so that OpenSolaris developers and users can more easily try out the new code, and get more involved with developing GNOME Shell. In the meantime, I will share build instructions if you want to try it out for yourself.

To build GNOME Shell for Solaris, I would recommend using a recent OpenSolaris or Solaris build with GNOME 2.26 installed. Note that OpenSolaris currently ships with GNOME 2.24, so you will need to first update your GNOME stack. GNOME 2.26 will be integrating into build 115, so it might be easiest to wait until that is available if you do not want to bother with updating your GNOME stack to 2.26 yourself.

Once you are using Solaris or OpenSolaris with GNOME 2.26, you can update your system to use GNOME Shell by following these steps. First, you need to download the spec-files-extra SVN repository. In this repository you will find the following spec files:

  • SFEgobject-introspection.spec
  • SFEgjs.spec
  • SFEgir-repository.spec
  • SFEclutter09.spec
  • SFEclutter-gtk09.spec
  • SFEmutter.spec
  • SFEgnome-shell.spec

To build these spec-files, you need to use the pkgtool command which is a part of the OpenSolaris Desktop CBE (Common Build Environment). Instructions on how to set up and use the CBE can be found at this Building the Code at website.

Once you have your build system set up, then you need to uninstall the metacity window manager. This window manager is replaced by mutter (in the SFEmutter.spec file). I would advise having a copy of the SUNWgnome-wm packages associated with your OpenSolaris or Solaris build handy in case you have problems installing GNOME-shell and need to back-out. Or you could rebuild and reinstall the SUNWgnome-wm packages from the spec-files repository, as explained in the above "Building the Code at" website.

To remove metacity, simply run the following commands:

$ pkgrm SUNWgnome-wm $ pkgrm SUNWgnome-wm-root $ pkgrm SUNWgnome-wm-devel $ pkgrm SUNWgnome-wm-l10n

Then install all of the GNOME Shell packages by running the following command in the spec-files-extra directory:

$ pkgtool --download build SFEgobject-introspection.spec SFEgjs.spec SFEgir-repository.spec SFEclutter09.spec SFEclutter-gtk09.spec SFEmutter.spec SFEgnome-shell.spec

The SFEgnome-shell.spec file installs a "shell.desktop" file in the /usr/share/xsessions directory so you can run GNOME Shell by selecting the "GNOME Shell" session from the login screen when you log in. I find that running GNOME Shell this way works well. You can also run GNOME Shell from within your user session by simply running the "gnome-shell" program. However, I notice that there are bugs running it this way on Solaris. Windows do not draw themselves properly and are not very usable. So there are some kinks to work out.

You can also continue using the "GNOME" login session to log into a more traditional GNOME session, except you will be using mutter instead of metacity. Aside from the fact that mutter has some compiz-like animations, I find the "GNOME" session very similar to the traditional GNOME desktop and very usable in my day-to-day work. I do not miss metacity at all.

Note that many of these modules do not have an official release, and some of the above spec-files pull the modules directly from their GIT master repository. This means that you may have some troubles building these modules if the upstream source code has changed in a way that breaks the way the spec-files build the modules. I have been working to keep the spec-files up-to-date and working, but if you run into any problems, let me know and I'll be happy to help fix the problem.

Enjoy! And remember, feedback is your friend! :)


Awesome, nice work! Would be fun to get this into the contrib repository!

Posted by Glynn Foster on April 28, 2009 at 12:37 PM CDT #

Of course by contrib repo, I actually mean vermillion on jucr

Posted by Glynn Foster on April 28, 2009 at 12:40 PM CDT #

Post a Comment:
Comments are closed for this entry.



« July 2016