I’ve neglected this indicator since the first day because it drove me into package dependencies that aren’t used in openSUSE (we use YaST and not system-tools-backends and friends).
The documentation of Unity suggests that if no indicators are present, Unity will use the notifications from GNOME. This is very interes
ting, but from the debugging I’ve done from the Unity Panel, I’ve found it it scans the indicators directory and loads whatever it finds there. So it will eventually find something. One of the coolest features in Unity Indicators and the one I’m currently working on, is ‘appmenu-gtk’ which removes the menu from GTK+ applications and displays it on the unity-panel. This is interesting and the behavior is actually a bit different from OSX. The window buttons are also placed very close to this indicator.
If we have such feature enabled, I suppose the panel will always pick up at least one indicator which might endanger the fallback to GNOME notification area. I’ve tested this yet (unity isn’t launched properly yet), but if this happens, it will be wise to have the whole stack of indicators. This explains why I had to build also this clock indicator despite it’s wicked dependencies (liboost, not used on openSUSE).
This is how it looks and minimal functionality is already enabled, though configurations aren’t because I haven’t implemented the whole backend, a
nd if this indicators are to reach Factory (which depends mainly on the patching on GTK+ and GDK Pixbuf), there is the need to pass this packages through SUSE Security Team. If the indicators are only to live on GNOME:Ayatana, then we skip this process (running this package dependencies through SUSE Security Team).
Here’s how it looks the current stack of indicators (there’s a couple more packaged, but I’m not using them at the moment, ex: nm-applet patched, indicator-network and friends).
Within the next days, I will I will make a 1 click installer and run a BETA phase for the Indicators/GNOME2.
Special Thanks to Didier Roche, Jorge Castro and Ken VanDine from Ubuntu/Canonical which have been hyper helpful answering questions and helping me accomplishing and overcoming several issue. Also to Malcolm Lewis (Novell/openSUSE) for keeping up with Compiz and other fixes for the requirements of Unity, and in general to openSUSE GNOME Team for keeping up the motivation and giving some awesome pointers in several GNOME related matters. This work so far has only been possible due to the commitment of all this people.
Both comments and pings are currently closed.
Weren’t KDE and Ubuntu developers already working on a general menu-handling spec compatible with both gnome and KDE? Is that what this is, or is it something else? And how does this interact with the new notification spec?
I haven’t covered KDE, only looking into GNOME stuff. If anyone wants to take this to KDE, go for it. About the GTK menu handling, this is done by a proxy, so far it requires 4 patches on GTK stack, but I haven’t looked properly into it yet, as most of this software is under development, and my plans are to use the versions available for Natty.
One of the main reasons why this work is only being developed for 11.4/Factory is exactly because of the libnotify requirements which are only present so far in 11.4 and Factory. Libnotify >= 0.5 is a must.
Yes. According to Canonical’s Qt/KDE guru Aurelien Gateau the required Qt patch ships with (K)Ubuntu’s Qt 4.7 and was accepted by Nokia for Qt 4.8. That Qt patch + Aurelien’s menu bar Plasma applet and it should work for all Qt/KDE and GNOME applications in both directions.
However so far nobody was willing or capable to provide patched Qt 4.7 + Plasma applet for openSUSE.