"Open with" in context menus

Applications
,
1

Hello :slight_smile:

I’d like the ability to have multiple “Open With …” items appear at the top of the context menu for a file. Currently, as far as I can tell, there is a primary handler for a file which appears as the first item, and then any other registered handlers are accessible through a second menu item, “Open With Other Application”. Opening with another application requires navigating through another layer of UI and is tedious.

Is there already a way to configure it so that, e.g., when I right-click on an image file, the menu might display:

  • Open With Image Viewer
  • Open With Pinta
  • Open With Firefox Web Browser
  • Open With Other Application

The closest I’ve found thus far is the extension actions-for-nautilus that allows me to define a custom “Open With Pinta” menu item – but this option appears at an indeterminate location near the bottom of the context menu.

One option would be a mechanism to allow extensions to insert menu items near the top of the list, if they indicate that that is their purpose. Another option would be to allow the user to indicate within the “Select Application” dialog that they’d like a direct “Open With” option to be made available in the context menu, after which Nautilus would register that in its configuration internally and subsequent activations of the context menu would add an item for that application. A third option would be configuration that allows the user to statically define context menu items per file type, with the option to place them at the top of the list. There are no doubt additional options I have not thought of here.

Are any of these options possible right now? If not, is it realistic to hope that any of them might be added to Nautilus? :slight_smile:

2

Hi Jonathan!
There is only one default handle offered, because the system nautilus builds upon only cover having one default application.
I like the suggestion to allow extensions to add to the “open” section of the menu, since that’s probably quite a common use-case. However, I think there is the danger of running into the issue that you can observe in the Windows file browser, where every app feels it’s entitled to spam your menu with a separate entry. So I think we’d first need some extension mechanism in which a user would have to specifically enable installed extensions. There was some rudimentary work done in this direction, but it’s currently far from anywhere near being ready.

3

Maybe it could be one central option to “open the floodgates”, so to say, but defaulting to off. So, the user has to explicitly enable automatically adding additional “Open with” items. This would restrict the “Select Application” dialog too, which would not have the option to automatically enable it, but could perhaps direct the user where to go to manually enable it. Once it’s enabled, though, the “Select Application” dialog would then be able to, if the user ticks a checkbox, automatically add an “Open With” to the main menu. Having it be disabled by default would hopefully discourage app developers from just throwing items in there without thinking about it, since they wouldn’t show up by default anyway – and directing users where to go in the Settings would also mean that if they ended up with unwanted entries, they’d already have been taught where to go to delete them.

4

I’m not sure I can follow all your ideas.

The “open the floodgates” idea I get, that sounds like a good way this could be done without requiring a full-fledged extension manager.

What I don’t fully get is the selection dialog thing. Are you envisioning that the dialog can add additional apps to the menu? If this were provided, then the extension solution would not be required I guess. But I am not sure it’s common enough of a use-case to add this functionality to the dialog.

5

What I’m imagining is a registration mechanism that allows arbitrary items to be registered, but which only kicks in when the user explicitly enables it. Perhaps it could even clear its configuration at the time of being enabled, so apps couldn’t squirrel their way in ahead of time. This would be a system connecting text (“Open With Pinta”, e.g.) with an action. I’m pretty new to Nautilus and Linux for the desktop, so I don’t know what options there are – there seems to be some sort of Python binding system for Nautilus? The simplest action, though, would simply be a command-line with insertion points for things like file path, file name, extension, etc.

Then, the “Select Application” dialog that appears when you choose “Open With Other Application” would have a checkbox that says something like, “Add to context menu”. Except, this checkbox is disabled by default, and if the user tries to interact with it, they’re presented with a prompt that tells them to go to the settings and enable the mechanism described in the first paragraph. If it is enabled, though, then the act of opening the file with a particular app adds a registration that does the same thing as selecting the application in the “Select Application” dialog. So, e.g., if you right-click on an image file, you might get:

  • Open With Image Viewer (return)
  • Open With Other Application

You select “Open With Other Application” and the “Select Application” dialog appears. In this dialog, you select Pinta, and then you also check off “Add to context menu” (or whatever the exact text is). You click “Select” and Pinta opens with your selected image file. I’ve just checked what the command-line for this turns out to be under the hood, and based on that, this would add a registration so that the next time you right-click on an image file, you now get:

  • Open With Image Viewer (return)
  • Open With Pinta
  • Open With Other Application

…and if you select “Open With Pinta”, then just as with the “Select Application” dialog, it executes the command-line:

/snap/pinta/31/usr/bin/dotnet /snap/pinta/31/lib/pinta/Pinta.dll /home/username/Pictures/SomeImage.png

It would also be slightly cleaner if the registration actually had a mechanism to activate the actual action that is being invoked by the “Select Application” dialog, but if so, I feel that the underlying registration mechanism should still support directly specifying a command-line to be executed.

Later on, you could then go to the configuration and say, “Actually I don’t want ‘Open With Pinta’” and delete it and your context menu goes back to the way it was before. Or, you could manually add an entry with an entirely custom action.

To be clear, I’m seeing it as two separate features, one building on the other:

  • The ability to add registrations for the top of the context menu.
  • An integration between this and “Open With Other Application” to automate the process for common cases.
6

What’s being requested here is already how it works, as specified:

  • more than one app can be associated with a file type.
  • one of these associations is chosen as default.

And the “Open With” dialog is where the non-default associations are shown. Not the menu. This is an intentional design choice.

2 Likes
7

With all due respect, what’s being proposed is not at all covered by the current implementation:

  1. The current implementation allows multiple applications to register themselves as Open With handlers, but it does not allow the user to customize these. There is an extension allowing this, sort of, but the menu items generated by it are not in a convenient location and there is no way to change this.

  2. The request here is very explicitly asking for a way to promote additional actions to the first-level context menu. The way it works right now matches the way it is designed right now. It’s not a bug in the implementation. But I want more flexibility to be captured by the design.

Jonathan

8

The specification I’ve linked to says the opposite.

It’s okay if you don’t understand the implementation details. Disagreeing on design choices is also okay. But writing “With all due respect” doesn’t make it okay to proceed to lecture someone who took the time to share some insider knowledge.

9

I don’t know how customizable it is but maybe Junction could be a fit for what you want?

10

My apologies, it just seems to me that what you are referring to doesn’t address the requested functionality at all. Perhaps I am wrong. Is there a way to have more than one direct option to open with a particular application in a given invocation of the context menu? When you wrote this:

“And the “Open With” dialog is where the non-default associations are shown. Not the menu. This is an intentional design choice.”

…I got the impression that you were saying explicitly that it can’t be done, and that you were simply describing what I thought I had observed as the current behaviour, which doesn’t do what I’d like it to.

11

At the briefest glance, it looks like this adds an extra level of indirection to all launches. There effectively isn’t a default option any more because you’ll always get the Junction popup. Does that sound right?? If so, then Junction does not solve the problem, I’m afraid.

12

The functionality is there. It’s neatly packed into the “Open With…” menu item.

So it’s not the case that the Files app is missing functionality. It’s just that you disagree with our design principles.

  • Don’t overwhelm people with too many elements at once. Use progressive disclosure and navigation structures to provide a guided experience.
  • Frequently used actions should be close at hand, with less important actions being further away.
1 Like
13

Okay, but we seem to be at a fundamental misunderstanding ab out what “the functionality” means.

Yes, it is possible to open a file with an application other than the default one.

But, I’m not asking for that. I’m asking for the ability, on my own system, to have additional elements up front in the first menu that appears. I will not be overwhelmed by this. The system is not foisting it on me. I am asking for it.

For me, opening an image in the system Image Viewer is a frequently-used action. But, opening an image in Pinta is also a frequently-used action. Your design principle is essentially saying, “Nuh uh, you can’t have more than one freqouently-used action! That’s not what ‘frequently-used’ means!”

Not all users will want multiple “Open With” options up-front, and just blindly showing all possibilities all the time would reduce the usability of the system for at least some people. But, some users (like myself), do absolutely want multiple “Open With” options up-front.

Following your principles, I will not be overwhelmed with having both “Open With Image Viewer” and “Open With Pinta”, and they are both frequently-used actions, so they should be close at hand. Maybe “Open With Pinta” is, in some circumstances, slightly less frequently-used than “Open With Image Viewer”, which is why the latter would remain the default option, but it isn’t less important, per se.

So, I’m not asking for the functionality of “being able to open with multiple applications”. I’m asking for the functionality of “having multiple Open With applications – at my direct behest – be directly in the first-level context menu”. I feel deliberately minified to have my request be dismissed under the banner of, “The functionality is already there,” and “This behaviour is by design.”

14

I don’t understand the purpose of a wall of text lecturing me so emphatically.

Ideas and suggestions are welcome here, so I like to provide feedback to let people know their suggestions have been read, if and when I have the time to spare.

So, you have a developer caring enough to read your suggestion, give it some consideration, and provide you personalized feedback including references to sources of knowledge. Even though you were not entitled any of it because this is not customer support. And yet you feel minified by the privilege.

The only conclusion is we would both be happier had I ignored you, which I will try to do from now on.

2 Likes
15

I don’t understand why you don’t understand my frustration. I came here saying, “The current behaviour isn’t doing it for me. I’d really like this more comprehensive behaviour.” Your reply was, “The current behaviour is by design.” You basically said that what I asked for is already how it works, when I opened the discussion by saying that how it works right now is frustrating and incomplete for me. What I asked for is definitely not how it works right now. I’m not saying that what’s implemented right now doesn’t match the design documents/principles. For sure, the design documents would need to be changed to capture the behaviour I’m hoping for. But please don’t tell me, “You can already do what you want, just activate this option that opens up a new window for you to interact with,” because that is exactly what I don’t want to have to do.

16

The functionality is there. It’s neatly packed into the “Open With…” menu item.

The entire point of my post was that I find this really inconvenient. What’s there right now isn’t “the functionality” that I’m looking for.

17
18

Apparently discussion is typically done in a section called Whiteboards before mockups are made :stuck_out_tongue: Mechanism for allowing additional options for opening a file to be presented directly in the context menu (#250) · Issues · Teams / Design / Whiteboards · GitLab

19

This topic was automatically closed 45 days after the last reply. New replies are no longer allowed.