| 2011-07-20 01:41:51 |
Marco Trevisan (Treviño) |
description |
As partly discussed in the UDS-O Blueprint "Desktop DX Indicators Review", as defined by the StatusNotifierItem specifications [1], and as requested by indicator-sound bug #609860 indicators need to support a secondary_activate signal, that can be fired by middle-click to perform advanced operations.
So, I've made some branches for the affected projects to get this implemented both in unity and unity-2d:
* libindicator: added the "secondary-activate" signal support.
* unity (unityshell and unity-panel-service): catches a middle-click release over an
indicator, and emits the secondary-activate signal (via the panel service)
* unity-2d (unity-2d-panel): like unity.
Now, these changes are just needed for "standard" indicators, which directly uses libindicator. For the userland indicators, there are more things to consider... In fact as already discussed in ayatana list, we should avoid that developers would use the secondary-activate event to perform actions that can't be done otherwise using standard menu items (as not all the platforms can do middle-click and not all users would use it anyway). The problem is that for libappindicator could be quite complicated to check if the event associated to the secondary-activate signal can be done via another menuitem, especially when using complex menu-items (like the one based on ido); so I guess that we can only fallback to the developers responsibilities.
The only thing I've done to limit then is to provide a documentation for the AppIndicator::secondary-activate, stating how developers should safely use it.
From the other side, an advanced way to quickly control some operations is often needed by advanced users (that I guess are the most part of the ubuntu userland) and, as already said, is also required by the StatusNotifierItem specifications [1].
Of course, while in the official ubuntu indicators we must always guarantee that a secondary-activate is used only to perform operations that can be also done via menu items, we can't control how this API will be used by all the external developers. By the way in my opinion, not to implement features because someone could use them in a bad way is not the right decision, since it will limit too much who wants to use it in the right way.
Plus, some ideas about possible implementations of this feature for third-party indicators where provided by comunity also on this etherpad [3].
However, the code to get the secondary-event support in libappindicator-based indicators is available in my branches too:
* indicator-application: redirects the libindicator secondary-activate event to the
called indicator via the standard "SecondaryActivate".
* libappindicator: emits a "secondary-activate" signal to the application using this
event.
Speaking of the affected indicators, I've already done the work for indicator-sound in bug #609860, and for indicator-messaging in lp:~3v1n0/indicator-messages/clear-notifications-on-secondary-activate (also if this maybe would need more work, and support by libindicate to be discussed in a separated bug).
[1] http://www.notmart.org/misc/statusnotifieritem/statusnotifieritem.html#SecondaryActivate
[2] https://lists.launchpad.net/ayatana/msg01230.html
[3] http://piratepad.net/WepMYIaQbx |
As partly discussed in the UDS-O Blueprint "Desktop DX Indicators Review", as defined by the StatusNotifierItem specifications [1], and as requested by indicator-sound bug #609860 indicators need to support a secondary_activate signal, that can be fired by middle-click to perform advanced operations.
So, I've made some branches for the affected projects to get this implemented both in unity and unity-2d:
* libindicator: added the "secondary-activate" signal support.
* unity (unityshell and unity-panel-service): catches a middle-click release over an
indicator, and emits the secondary-activate signal (via the panel service)
* unity-2d (unity-2d-panel): like unity.
/* OLD DESCRIPTION */
Now, these changes are just needed for "standard" indicators, which directly uses libindicator. For the userland indicators, there are more things to consider... In fact as already discussed in ayatana list, we should avoid that developers would use the secondary-activate event to perform actions that can't be done otherwise using standard menu items (as not all the platforms can do middle-click and not all users would use it anyway). The problem is that for libappindicator could be quite complicated to check if the event associated to the secondary-activate signal can be done via another menuitem, especially when using complex menu-items (like the one based on ido); so I guess that we can only fallback to the developers responsibilities.
The only thing I've done to limit then is to provide a documentation for the AppIndicator::secondary-activate, stating how developers should safely use it.
From the other side, an advanced way to quickly control some operations is often needed by advanced users (that I guess are the most part of the ubuntu userland) and, as already said, is also required by the StatusNotifierItem specifications [1].
Of course, while in the official ubuntu indicators we must always guarantee that a secondary-activate is used only to perform operations that can be also done via menu items, we can't control how this API will be used by all the external developers. By the way in my opinion, not to implement features because someone could use them in a bad way is not the right decision, since it will limit too much who wants to use it in the right way.
Plus, some ideas about possible implementations of this feature for third-party indicators where provided by comunity also on this etherpad [3].
However, the code to get the secondary-event support in libappindicator-based indicators is available in my branches too:
* indicator-application: redirects the libindicator secondary-activate event to the
called indicator via the standard "SecondaryActivate".
* libappindicator: emits a "secondary-activate" signal to the application using this
event.
/* NEW DESCRIPTION */
The libappindicator code now contains a new API:
* app_indicator_set_secondary_activate_target
With it, an appindicator writer can simply define a new GtkWidget that will be activated when a secondary activation will occur.
The GtkWidget must be a sensitive and visible inner child of the appindicator MenuItem. When a middle-click is done over the appindicator, if the linked menu-item is visible and sensitive then it's directly activated.
Speaking of the affected indicators, I've already done the work for indicator-sound in bug #609860, and for indicator-messaging in lp:~3v1n0/indicator-messages/clear-notifications-on-secondary-activate (also if this maybe would need more work, and support by libindicate to be discussed in a separated bug).
[1] http://www.notmart.org/misc/statusnotifieritem/statusnotifieritem.html#SecondaryActivate
[2] https://lists.launchpad.net/ayatana/msg01230.html
[3] http://piratepad.net/WepMYIaQbx |
|
