My suggestion (unaware if it’s possible or not) was probably to explore GNOME3 features to serve YaST integrated already with GNOME3. This could be an interesting approach as it would offer integration and some advantages:

* Better integration with GNOME3 without having to write(/maintain another application;
* Take advantage of YaST2 modular structure;
* Present YaST in a prime space in GNOME3, thus offering a openSUSE differentiation point;
* No conflicts with possible KDE existing front-ends for YaST2;
* Improve users experience.

My proposal would be something like (maybe to be served as an extension for gnome-shell). Please neglect my ‘lame’ photo manipulation skills:

Mockup: YaST2 on GNOME3

For some time I wanted to check out GNOME3 and gnome-shell… My current chipset is ATI M92 RV710 and while the thermal performance with the proprietary driver is somewhat what I expect, the open source radeon driver does overheat my laptop a lot compared to flgrx. For the time being, fglrx isn’t really a choice because it just borgs the ‘activities’ bar on top… And until ATI fixes their driver, there’s no other choice than running with the standard radeon drm driver, which does provide a very pleasant experience with GNOME3 / gnome-shell.

For all that matters, KMS is to be enabled, period, full stop. And from this point… we have two options regarding power management:

1. Dynamic Frequency switching (not really working for me);
2. Profile based frequency switching (does provide what I need);

For all that matters regarding ‘profile based frequency switching’ we have 5 profiles available:

• “default” uses the default clocks and does not change the power state. This is the default behavior.
• “auto” selects between “mid” and “high” power states based on the whether the system is on battery power or not. The “low” power state are selected when the monitors are in the dpms off state.
• “low” forces the gpu to be in the low power state all the time. Note that “low” can cause display problems on some laptops; this is why auto only uses “low” when displays are off.
• “mid” forces the gpu to be in the “mid” power state all the time. The “low” power state is selected when the monitors are in the dpms off state.
• “high” forces the gpu to be in the “high” power state all the time. The “low” power state is selected when the monitors are in the dpms off state.

Now, what I did might not be an option to everyone, but for sure it does provide a nice solution for my problem… So be mindful of that… this is a personal preference based on the fact that I don’t require intensive GPU usage, neither I run intensive GPU requiring applications within GNOME3/gnome-shell (I have a normal openSUSE 11.4 with GNOME 2.32.x with fglrx dual boot config for those apps).

The first thing we might want to do is to switch to profile based frequency switching… how do we this? As root:

[code] echo profile > /sys/class/drm/card0/device/power_method[/code]

Now we have to pick one of those 5 profiles… and since I’ve already stated… I want the ‘low’ profile since I don’t really do much intensive GPU work…

[code] echo low > /sys/class/drm/card0/device/power_profile[/code]

Now… you might want to check out the different profiles and the different clocks used… this can be done through:

[code] cat /sys/kernel/debug/dri/0/radeon_pm_info[/code]

and will report something like this:

[code]linux-331w:~ # cat /sys/kernel/debug/dri/0/radeon_pm_info
default engine clock: 680000 kHz
current engine clock: 299530 kHz
default memory clock: 800000 kHz
current memory clock: 249750 kHz
voltage: 900 mV
PCIE lanes: 16[/code]

This one is using the ‘low’ profile… Feel free to test stuff around and find which one better answers your needs… Also there’s far more that can be done… I hope this helps ATI users with DRM driver to bring out the best of your system and improves your GNOME3 / gnome-shell experience, at so that you can run it with good thermal performance without fglrx.

NM

Screenshot using Radiance Light Theme and default Ubuntu indicator layout.

Some brief updates about the ongoing work towards bringing Ayatana Project software into openSUSE:

1. Software Updates

Canonical recently released a batch of updates which bring new functionality (Indicators seem to respond faster now) and very nice improvements, some of them contributed by down-streamers. From my humble experience I would risk to claim that Canonical is doing an excellent job as an upstreamer. I’ve updated all packages to the latest versions. This allowed to remove some patches.

2. Unity

Unity is now one step closer. For Unity I’ve started to package Compiz git snapshots from the correct branches pointed by Unity documentation. This brought something new to me, cmake. I’ve done this very slowly, reading some docs meanwhile about cmake. My packaging around Compiz is mainly based on OBS X11:Compiz repository, so pretty much all the credits should be for the original project Packagers which done an awesome job. Currently I’m missing only 3 packages to test Unity. Recently with kernel and mesa updates some issues around ATI hardware seem to have fixed for openSUSE Factory users, which enabled in my case FireGL, therefore I can test properly Unity now and check for the integration into openSUSE.

Unity by default uses the Ayatana’s Indicators, and if they are not present, it will fallback to GNOME’s applets. This is very nice and I’m thankful Canonical made it this way. This brings non-Ubuntu users the Unity experience at almost no trouble, since there isn’t actually much patching required to implement Unity.

3. GNOME:Ayatana Repository

GNOME:Ayatana Repository will be populated during the next two weeks with the latest changes and will provide for the time being the Ayatana’s Indicators and Unity. I am currently working around libappindicator stack and it’s Indicators. Currently I’m testing the patches required on the GTK+ stack and this is pretty much the last barrier before going into #STAGE2, polishing and populating GNOME:Ayatana.

It’s not decided yet what packages are going to present on Factory. My wish is to push only Unity into Factory and it’s dependencies, this might not happen for 11.4 as I’m not sure about the freeze schedules and it might be too late already, but since we’re depending on Compiz upstream, we’ll see what happens. Even if Unity isn’t going to be available on Factory, I’m sure we can use KIWI or SUSE Studio to release a small openSUSE Unity Spin.

I’ve also decided that I (typo: previously would) wouldn’t like to see Unity available by openSUSE before the official release from Ubuntu, for which I wish all the success.

Since the very early start that I’ve been using pkg-config as much as I can. According to some information that I collected previously, this would be great for cross-distribution build. Depending on the time and work done, I might make the necessary modifications and enable cross-distribution building on this project, thus, making it available for other RPM distributions supported by OBS. This will require a bit of testing before, so it will be work to be done after 11.4 is released and during it’s lifecycle. Maybe by the time of openSUSE 12 gets released, we will have this project also available for other RPM based distributions. I have no knowledge on Debian packaging, but Ubuntu ships this software and Debian probably has it also available so… that won’t be a problem.

4. Artwork

I am providing on GNOME:Ayatana Ubuntu’s Light Themes (Ambiance and Radiance) and offering a patched version of Metacity that renders those themes perfectly. I’m not changing the original colors from the themes or modifying them in any way. So they might be a bit more of orange and not green.

I’ve contacted some people to ask if they would be willing to donate some artwork to make a small package with Wallpapers, some have answered yes, so I will make a small package with a couple of wallpapers for the traditional resolutions and distribute it alongside with this software as optional as always.

5. GTK2, GTK3 and QT

Implementation of GTK3 will be done within the next days, as I am also considering enabling QT support for KDE users (Indicators only for now).

That’s pretty much the result of the last days of work… more news to come in the nearby future.

This has been one of the guidelines in my life for quite some time… It started as a curiosity a long time ago with Notify OSD and evolved to full project in openSUSE. It is important to acknowledge at this point the motivation provided by the openSUSE GNOME Team from which I’ve been getting plenty of guidance and help, namely from Vincent Untz (vuntz) and Dominique Leuenberger (Dimstar). Thanks to them, we have now a GNOME:Ayatana Project on OBS (openSUSE Build Service), currently being populated with the support libraries for Ayatana’s Unity and Indicators.

Susan Linton has made a small article for Linux Journal about this project in the past. Though some people pointed to me that it was advertising and excelling Ubuntu… I would like to leave a statement… We’re not taking a hike on Ubuntu visibility, and it isn’t bad at all, on the contrary… In fact it will help Ubuntu, us and many others… specially if some Ubuntu patches are accepted faster by upstream. I hope other RPM distributions will follow the way we, openSUSE, proudly seem to pioneering! From my personal point of view… a distribution ‘distributes’… and despite this software isn’t attractive for some openSUSE users, I’m happy it is available (totally or partially) for all those who want to test it… Wait… you don’t even need to install Ubuntu or changing the platform you run!

Due to several reasons, being the most important of them versioning, this repository will start on the next release of openSUSE in March 16th (World day of Conscience, interesting point). This is also interesting as if YOU are willing to improve a package or submit a package you can now do it to this repository.

This goes with a very huge cookie for Dimstar and Vuntz for taking care of this repository and making sure that everything will comply with the openSUSE Guidelines. You are my personal heroes.

It has been quite an interesting experience to be with openSUSE GNOME team which is full of knowledge and helpful in many ways. I can’t also forget to mention that last week Luis Medinas has taken tutorship of a Portuguese contributor to openSUSE GNOME, João Matias and will provide him the necessary help to integrate him on the workflow of the GNOME Team. My personal thanks to Luis for stepping into this task, which from my personal point of view is very important.

Regarding to Ayatana it is worth to mention that Dimstar provided some valuable help in fixing the dbusmenu package and taking care of the necessary patch submission in GTK and gdk-pixbuf to allow dbusmenu to build with introspection support and generate properly the Vala files required for other packages. This handicap beaten… we’re on the good road for better functionality. This patches also allowed to correct some behavior in some indicators, one fine example of this the ‘Me Menu’ which now displays correctly a  ‘dot’ on the selected status as the screenshot bellow shows:

In the last days, despite it’s Christmas season and soon new year…. I’ve been also working on providing additional extensions to enable some functionality on some indicators. This was the case of indicator-sound, which provides an alternative sound gadget that offers extended functionality with multimedia players. A fine example of this is Novell’s Banshee player which has astonishing out of the box implementation with the sound indicator from Ayatana by a small extension that can be enabled. I’m still wondering why so many people toss heavy critics at this indicator calling it ‘mac styled’… while to be honest I doubt such people have even seen OSX sound applet, which is more or less a direct copy of the one present in GNOME, the vertical switch. Interesting view nevertheless.

Indicator-sound has also been fixed and no longer requires the nasty hack in the previous package. Since I’m not an Ubuntu user, neither I have extensive experience on their Desktop, I’m not sure if the functionality present so far in the indicators is the one offered by Ubuntu. I plan to run a Open Beta on the Ayatana software repository during the last Milestone of Factory to all Factory users to collect more data and improve the packages, at least the indicators, as in the present since I have ATI hardware I don’t have FireGL enabled on Factory, so I can’t really push much on Unity and test it for the time being.

Another subject of plugins was Xchat which is GNOME’s premier IRC client. Novell’s Evolution also got it’s plugin which is found to be partially working. I haven’t tracked yet if there are patch submissions to Evolution from Ubuntu to enable indicator functionality. That’s for sure one of the next steps, and since Evolution is a bit of ‘in-house’, would be nice to have them approved upstream if submitted already, as it would serve openSUSE as well.

Most of this applications, evolution, xchat, gwibber, empathy, pidgin are supported by indicator messages which collects information from several messaging services and places them on a single indicator in a cascade style experience for the user. I personally find it weird as I’m not used to this, but seems nice. Unfortunalty some applications seem rely on patches to be fully supported, like empathy. I hope upstream accepts the patches from Ubuntu (if submitted) and we can also benefit from such changes in our side.

Basically to sum up everything in a short review…

* Indicators are working fully or partially depending on patch level on some applications. If upstream starts accepting Ubuntu patches (some shouldn’t be much of a problem), it will work out for Ayatana software in openSUSE as well.
* Unity – Though it builds already with some compiz packaged from git sources (to include glib mainloop patching), I have no way of testing it, neither I have done integration on it. Unfortunately both my systems have ATI hardware and I have no way of testing it on Factory which seems to be too much bleeding edge for ATI to keep up. It’s stalled a bit, but in the worst scenario will be available a few weeks after the next official release of openSUSE.
* During this wait time… we might see a new release of compiz with the patches upstreamed by Canonical, which will for sure help us also a lot. No need for hurry in Unity at this time.

My personal experience with this project has given me lots of knowledge about OBS, hacking Makefiles and configure scripts… debug skills… and specially I ended up loving the way openSUSE is built and how it works. I would take also this opportunity to make a small statement… all the development so far has been deployed over GNOME 2.32. Much of the software packaged already supports GTK3 and should be easy to migrate it to GNOME3. At the moment, since the next openSUSE release is still based on GNOME 2.32, I’m not testing all this software on GNOME3. It might take a few days/weeks to have it available for GNOME3 after it’s release, though from a personal perspective, what I’ve seen on GNOME3 seems to be overkill! It’s damn nice and I have no doubt GNOME3 will succeed as the ultimate Free Desktop.

I would also like to mention that I’m not testing this indicators with KDE. In case someone wants to do this, please feel free to nag me on IRC (#opensuse-gnome @ Freenode) and leave feedback. I’m focused only on GNOME2 and GNOME3 deployment of this software packages, though I will help in whatever way I can if someone wants to work them out for KDE.

I’m using a patched version of Metacity (patches were submitted upstream) which improves the display of buttons by improving overlaying of images (I think). Look at the sharp corners of the theme in the pic bellow. As always, Faenza Icon theme with Canonical’s light theme Radiance (not hacked). This is another change I hope that goes upstreamed soon.

My sincere congratulations to everyone working on the awesome GNOME3, I’m sure it will be a success and make the delights of many! My faith points that GNOME3 will change Desktop user experience forever!

Have a lot of fun…!

Nelson Marques