GNOME Bugzilla – Bug 669603
Allow apps to add extra items to their shell context menus (aka jumplists)
Last modified: 2014-04-27 14:09:02 UTC
Part of https://live.gnome.org/ThreePointThree/Features/Jumplists, in particular the static actions sub-feature. This is code I had locally for a while, I'm opening this bug partly because the underlying format was recently approved and partly because I'd like to publish it before The Freeze. It _should_ work. Clearly, if the original plans have changed (I didn't see many updates to that feature page), just disregard this bug and the associated gio API addition. PS: do we need a specific component for the overview?
Created attachment 207023 [details] [review] Introduce support for desktop actions in the dash Using the new GDesktopAction API in Gio, add entries for static actions specified in .desktop files in the right-click app menus, in the dash, app well and search.
I'm working on a GSoC project for Mozilla (https://wiki.mozilla.org/SummerOfCode/2012/LinuxNativeWebApps). Our plan was to use these jumplists actions to support web applications removal (http://abral.altervista.org/desktop_action.png). Do you have an ETA on when you can ship this feature?
Review of attachment 207023 [details] [review]: What GDesktopAction API? A quick Google gives nothing. ::: js/ui/appDisplay.js @@ +672,3 @@ + for (let i = 0; i < actions.length; i++) { + let action = actions[i]; + if (action.should_show()) { Seems like a silly API to have. I assume that we need to listen on some should-show property and toggle the visibility accordingly?
(In reply to comment #3) > Review of attachment 207023 [details] [review]: > > What GDesktopAction API? A quick Google gives nothing. It's in bug 664444 > ::: js/ui/appDisplay.js > @@ +672,3 @@ > + for (let i = 0; i < actions.length; i++) { > + let action = actions[i]; > + if (action.should_show()) { > > Seems like a silly API to have. I assume that we need to listen on some > should-show property and toggle the visibility accordingly? The API is modeled after Gio.AppInfo. There is no need to listen to notify::should-show because it can't change unless the original desktop file changes (which triggers "installed-changed" and a full refresh).
We obviously missed this for 3.4. In the Boston Summit, we're discussing Jumplists again.
And 3.6 too. What was the result of this discussion? Should I keep carrying this on?
(In reply to comment #6) > And 3.6 too. > What was the result of this discussion? Should I keep carrying this on? Which menus would this allow apps to extend? Would there be any limits on how many items they could add?
(In reply to comment #7) > Which menus would this allow apps to extend? Would there be any limits on how > many items they could add? The right-click popup menus in the dash and application view. And no, there would not be limits, but this is in control of the application author, so it's call to choose a reasonable number of launchers. Usually, in existing apps it's one or two extra actions.
Created attachment 266657 [details] [review] Introduce support for desktop actions in the dash Using the new list_actions() API in Gio, add entries for static actions specified in .desktop files in the right-click app menus, in the dash, app well and search. Rebased, and rewritten on the API that actually landed in GIO after Ryan's review.
Review of attachment 266657 [details] [review]: ::: js/ui/appDisplay.js @@ +1607,3 @@ + this._toggleFavoriteMenuItem.connect('activate', Lang.bind(this, function() { + let favs = AppFavorites.getAppFavorites(); + let isFavorite = favs.isFavorite(this._source.app.get_id()); Just use the isFavorite from above? @@ -1609,3 @@ - }, - - _onActivate: function (actor, child) { Can you make this removal a separate cleanup? ::: src/shell-app.c @@ +1187,3 @@ +static GAppLaunchContext * +make_launch_context (guint timestamp, Hm, can we replace shell_global_create_launch_context with this? Separate cleanup, though.
Created attachment 266667 [details] [review] AppDisplay: clean up handling of right click popup menu Instead of connecting a global activate handler on the menu, have one on each menu item, individually doing the right thing.
Created attachment 266668 [details] [review] Introduce support for desktop actions in the dash Using the new list_actions() API in Gio, add entries for static actions specified in .desktop files in the right-click app menus, in the dash, app well and search.
Created attachment 266669 [details] [review] ShellApp+ShellGlobal: unify app launch context code Extend shell_global_create_app_launch_context() with the required parameters and use that for shell_app_launch() too.
Review of attachment 266667 [details] [review]: ::: js/ui/appDisplay.js @@ +1591,1 @@ this._appendSeparator(); Two separators? @@ +1597,3 @@ + this._toggleFavoriteMenuItem.connect('activate', Lang.bind(this, function() { + let favs = AppFavorites.getAppFavorites(); + let isFavorite = favs.isFavorite(this._source.app.get_id()); We don't need the second isFavorite here.
Review of attachment 266668 [details] [review]: Looks good. ::: js/ui/appDisplay.js @@ +1593,3 @@ + for (let i = 0; i < actions.length; i++) { + let action = actions[i]; + let item = this._appendMenuItem(appInfo.get_action_name(action)); Gio will do translations for us, right? Just double-checking.
Review of attachment 266669 [details] [review]: Looks good. ::: src/shell-app.c @@ +1194,2 @@ global = shell_global_get (); + return shell_global_create_app_launch_context (global, timestamp, workspace); Can we remove the make_launch_context wrapper?
Yes, GIO takes care of translations during GDesktopAppInfo load. Pushed with suggested changes. Attachment 266667 [details] pushed as 9ba4790 - AppDisplay: clean up handling of right click popup menu Attachment 266668 [details] pushed as 7e27afb - Introduce support for desktop actions in the dash Attachment 266669 [details] pushed as 3227d4f - ShellApp+ShellGlobal: unify app launch context code
*** Bug 729055 has been marked as a duplicate of this bug. ***