After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 636311 - appinfo: tweak application positioning for content-types
appinfo: tweak application positioning for content-types
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: gio
unspecified
Other All
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2010-12-02 17:55 UTC by Cosimo Cecchi
Modified: 2010-12-20 14:48 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
appinfo: tweak application positioning for content-types (8.97 KB, patch)
2010-12-02 17:55 UTC, Cosimo Cecchi
none Details | Review
appinfo: add _set_as_last_used_for_type() (21.09 KB, patch)
2010-12-14 18:32 UTC, Cosimo Cecchi
none Details | Review
appinfo: add g_app_info_set_as_last_used_for_type() (25.41 KB, patch)
2010-12-15 17:12 UTC, Cosimo Cecchi
committed Details | Review

Description Cosimo Cecchi 2010-12-02 17:55:18 UTC
For GtkAppChooser, we want to remember the order in which custom
applications have been chosen from the dialog, i.e. when an application
is chosen, it should popup under 'Recommended Applications' at the top
of the list, or immediately after the default one.

Tweak the method that adds user applications to always insert
custom-added associations in the second position of the list, preserving
the rest of the order.
Comment 1 Cosimo Cecchi 2010-12-02 17:55:21 UTC
Created attachment 175722 [details] [review]
appinfo: tweak application positioning for content-types
Comment 2 Matthias Clasen 2010-12-02 20:51:13 UTC
Review of attachment 175722 [details] [review]:

Hmm. How will this look in the dialog, user-experience-wise ? 

The previously picked app will appear in the second place and be preselected ?
Comment 3 Cosimo Cecchi 2010-12-03 13:34:58 UTC
Preselecting is a matter for a separate patch to the GTK+ dialog; as for the ordering, yes, it will appear in the second place of recommended applications, or if the widget is configured to show the default in a separate section, it will show first among the recommended.
Comment 4 Matthias Clasen 2010-12-03 13:44:20 UTC
Hmm, not sure I love that (preselecting the second). Can we arrange things so the default is just sorted among the recommended apps unless we have a separate section for it ?

Other than that, the patch looked ok to me.
Comment 5 Cosimo Cecchi 2010-12-09 16:05:47 UTC
(In reply to comment #4)
> Hmm, not sure I love that (preselecting the second). Can we arrange things so
> the default is just sorted among the recommended apps unless we have a separate
> section for it ?

Not in mimeapps.list, as the first entry is always the default (per-spec).
I expect _get_recommended_for_content_type() to return the default application as the first of the list, followed by the others in whatever order GIO wants (e.g. 'last used', like in this patch).

What we could do in the GTK+ dialog is fetching both the recommended list and the default app; if the default list contains more than one application (and the default is equal to the first, as a sanity-check), we "artificially" move the default away from the first position.
Comment 6 Cosimo Cecchi 2010-12-13 09:36:44 UTC
(In reply to comment #5)

> What we could do in the GTK+ dialog is fetching both the recommended list and
> the default app; if the default list contains more than one application (and
> the default is equal to the first, as a sanity-check), we "artificially" move
> the default away from the first position.

I played a bit with this option, and it seems it's still not ideal, if I correctly understood the expected design.
What happens is, if you select the *default* app from the app chooser dialog, GTK+ won't have enough information to know it should pre-select it the next time (it will pre-select the last non-default entry).

I am now thinking about another approach, i.e. installing a new keyfile, entirely managed by GTK+ that saves the last used application for each content type. This would be completely internal to GTK+ and not exposed through API of any kind, and it would be updated by the GtkAppChooser classes once a non-default application is chosen from a widget.

What do you think?
Comment 7 Matthias Clasen 2010-12-13 15:14:26 UTC
I think it is fine to extend mimeapps.list for this purpose. AFAIK, only gio uses it, anyway. KDE never adopted it.
Comment 8 Cosimo Cecchi 2010-12-14 18:32:13 UTC
Created attachment 176422 [details] [review]
appinfo: add _set_as_last_used_for_type()

Add a new group to the mimeapps.list desktop file, which tracks
the last application used for a content type.
This is useful in GtkAppChooser-like widgets to pre-select the last used
application when constructing a widget.

--

A completely different approach, exploiting mimeapps.list to store more information, i.e. the last used application for a content type.
Tested with GtkAppChooser widgets, works fine.
Comment 9 Matthias Clasen 2010-12-15 01:36:57 UTC
Review of attachment 176422 [details] [review]:

I hate to come back with more comments, but shouldn't we have the recommended list sorted by mru, instead of just the last-used app tacked up front ?
I guess I would have expected to add a separate section for the default app, and then just always move the last-used app to the front in the association list.

::: gio/gdesktopappinfo.c
@@ +1408,3 @@
+                               TRUE, /* non-default */
+                               FALSE, /* remove */
+                               TRUE, /* last used */

This 4-bool-in-a-row api is a bit of a disaster...
Comment 10 Cosimo Cecchi 2010-12-15 15:19:14 UTC
(In reply to comment #9)
> Review of attachment 176422 [details] [review]:
> 
> I hate to come back with more comments, but shouldn't we have the recommended
> list sorted by mru, instead of just the last-used app tacked up front ?
> I guess I would have expected to add a separate section for the default app,
> and then just always move the last-used app to the front in the association
> list.

Good idea; if we go this way, g_app_info_add_supports_type() would add an application at the end of the list, and g_app_info_set_as_last_used_for_type() would add it in front of the list, to cover all the use cases. I'll have a go implementing it.

> ::: gio/gdesktopappinfo.c
> @@ +1408,3 @@
> +                               TRUE, /* non-default */
> +                               FALSE, /* remove */
> +                               TRUE, /* last used */
> 
> This 4-bool-in-a-row api is a bit of a disaster...

Yeah, I'm going to refactor that to use a flag enum instead.
Comment 11 Cosimo Cecchi 2010-12-15 17:12:31 UTC
Created attachment 176483 [details] [review]
appinfo: add g_app_info_set_as_last_used_for_type()

This commit also changes (maintaining compatibility) the way
user-specified default applications are stored (as in, those for which
g_app_info_set_as_default_for_type() has been called.

We now store the default application for a content type in a new group
in the mimeapps.list keyfile, and "Added Associations" tracks only the
applications that have been added by the user, following a
most-recently-used first order.

This is useful in GtkAppChooser-like widgets to pre-select the last used
application when constructing a widget.

--

Another patch, following Matthias' suggestion. Seems to work fine with GIO tests, GtkAppChooser and nautilus so far.
Comment 12 Matthias Clasen 2010-12-20 14:28:50 UTC
Review of attachment 176483 [details] [review]:

Looks good to me
Comment 13 Cosimo Cecchi 2010-12-20 14:48:14 UTC
Attachment 176483 [details] pushed as 678bcad - appinfo: add g_app_info_set_as_last_used_for_type()