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 582557 - need open with dialog box to use with IBM's Lotus Notes Linux Client
need open with dialog box to use with IBM's Lotus Notes Linux Client
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: Other
2.91.x
Other All
: Normal enhancement
: 3.0
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2009-05-14 01:43 UTC by Steve Best
Modified: 2010-11-30 16:38 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement


Attachments
squashed diff (564 bytes, patch)
2010-11-16 18:27 UTC, Cosimo Cecchi
none Details | Review
squashed diff (60.90 KB, patch)
2010-11-16 18:28 UTC, Cosimo Cecchi
none Details | Review

Description Steve Best 2009-05-14 01:43:02 UTC
I been exchanging e-mail with Alexander Larsson about getting a open with dialog box we could use for IBM's Lotus Notes Linux Client and he suggested to open new feature request here. In the past we were using eel_open_with_dialog_new in the eel library. This is no longer avaialble, it has been moved to /libnautilis-private/ and no longer in a library that we can use. The code is about 1000 lines and self contain in the file nautilus-open-with-dialog.c and would be a great addition to Gtk+. From Alexander other applications have requested this (eclipse, mozilla, etc.) also. So it would be used by many applications if it was added.

Here is an old thread about this:
http://mail.gnome.org/archives/gtk-devel-list/2008-March/msg00110.html

Thanks,
Steve
Comment 1 Cosimo Cecchi 2010-11-16 18:27:36 UTC
Makes a lot of sense; I went ahead and implemented this. Attached you can find a squashed diff of my branch (should I push it on git.gnome.org?).

It's basically a port of the nautilus-open-with dialog on steroids, as it adds some new API to make it more streamlined and customizable, and also has a nicer division between "recommended apps" (those who claim to support a content type) and other applications, with a way of choosing whether to show only the former or both.

Comments more than welcome!
Comment 2 Cosimo Cecchi 2010-11-16 18:27:55 UTC
Created attachment 174623 [details] [review]
squashed diff
Comment 3 Cosimo Cecchi 2010-11-16 18:28:36 UTC
Created attachment 174624 [details] [review]
squashed diff

Wrong attachment, sorry.
Comment 4 Matthias Clasen 2010-11-16 19:17:41 UTC
Some initial impressions from playing with it for 5 minutes:

- The section headings are interfering with activation/selection a bit.
  They should not react to double-click, and ideally, keynav should skip them (the second may be hard).

- We may want to make the 'custom command' part optional.

- I think showing the description in a label below the list is suboptimal.
Comment 5 Matthias Clasen 2010-11-16 19:19:21 UTC
Oh, and some more:

- Do we need to allow for variations, like embedding the chooser in another window, instead of having a standalone dialog ?

- At the very least, it should be easy (and documented) how to do a two-level selection like nautilus currently has, with recommended apps in a menu, + "Other..." which brings up the full dialog.
Comment 6 Cosimo Cecchi 2010-11-17 10:32:56 UTC
(In reply to comment #5)
> Oh, and some more:
> 
> - Do we need to allow for variations, like embedding the chooser in another
> window, instead of having a standalone dialog ?
> 
> - At the very least, it should be easy (and documented) how to do a two-level
> selection like nautilus currently has, with recommended apps in a menu, +
> "Other..." which brings up the full dialog.

I plan to split the dialog in some more classes for this, a bit like GtkFileChooser does:
- GtkOpenWithDialog - standalone dialog, pretty much what I posted here
- GtkOpenWithWidget - embeddable widget, the dialog would use this internally
- GtkOpenWithComboBox - possibly a good idea to have too at some point? This would only include recommended applications and have a "Other application..." entry to trigger the dialog.

I'll update the patch soon.
Comment 7 Emmanuele Bassi (:ebassi) 2010-11-17 14:29:45 UTC
OpenWithDialog sounds... a bit odd.

what about ApplicationChooser? at least, it would fit in with the other *Chooser, since you're modelling the API around them.
Comment 8 Christian Dywan 2010-11-17 14:44:30 UTC
(In reply to comment #6)
> GtkFileChooser does:
> - GtkOpenWithDialog - standalone dialog, pretty much what I posted here
> - GtkOpenWithWidget - embeddable widget, the dialog would use this internally
> - GtkOpenWithComboBox - possibly a good idea to have too at some point? This
> would only include recommended applications and have a "Other application..."
> entry to trigger the dialog.

+1 on the dialogue and the combo box. A lot of applications have either a combo box or an entry to choose an application. "Other..." should also allow entering a command line.

(In reply to comment #7)
> OpenWithDialog sounds... a bit odd.
> 
> what about ApplicationChooser? at least, it would fit in with the other
> *Chooser, since you're modelling the API around them.

+1
GtkAppChooser would seem to fit with GAppInfo.
Comment 9 Matthias Clasen 2010-11-17 16:47:13 UTC
I had a long chat with Jon about how to make this work nicely. Here is a summary of our thoughts (sorry, no mockups):

We don't want the commandline thing in there. Creating desktop files in this way is not going to work very well with the shell, since it will be missing many important ingredients, such as icon, wmclass, etc.

We don't really want the 'remember this' checkbox. Instead, just always default to the last choice. That also means that choosing an app from the 'other apps' list will move it to the 'recommended list' the next time you open the dialog.

Showing the description below the list is not really useful, propose to ditch it.

The remove button that changes sensitivity as you scroll through the list seems suboptimal. We recommend to instead have a 'remove' context menu item. And allow it for all apps in the 'recommended' list. Might be better to say 'Remove association' or 'Forget association' to make it clear that the app is not going to be removed. If an association is removed in that way, the app should go into the 'other applications' list.

We want to differentiate between three sets of apps:
• apps that directly claim to handle the mime type (recommended)
• apps that can handle a supertype (e.g. file-roller for office document) (fallback)
• other apps that can open files (other)

If the recommended list is not empty, we want the dialog to come up with the recommended apps shown in the list, plus a 'Show other applications' button at the bottom of the list. The last choice should be at the top, and preselected.
If you click on 'Show other applications', the button will be replaced by two additional sections of list items, for the fallback and other lists. These sections should have explanatory headings, such as 'Applications that can handle similar files' (for fallback) and 'Other applications' (for other).

In the lower left corner, there will be a 'Find Applications Online...' (or 'Go to Appstore...') button (assuming PackageKit integration) that will bring up something else listing installable applications handling the file type in question. In the lower right corner will be the expected 'Cancel' and 'Open'. One important point here is that the list of apps should be updated in the dialog when the user installs an app this way without closing the dialog first.

If the recommended list is empty (or we don't have a meaningful mimetype, such as application/octet-stream for a web download), the dialog will come up without the list, instead showing a text like 'Sorry, cannot find an application to open 'fun.odp'. 

In this case, the action area will again have the appstore button on the left, and
'Cancel' and 'Show other applications'. Clicking the 'Show other' button will switch back to the list, with the fallback and other sections expanded.
Comment 10 Cosimo Cecchi 2010-11-30 16:38:21 UTC
I implemented the suggested behaviour, with a nicer API too.

The new widgets are named:
GtkAppChooserDialog
GtkAppChooserButton
GtkAppChooserWidget

After some rounds of review and feedback with Matthias and Jon on IRC, I merged my branch to master, for bugs and feedback, please open new reports, thanks.