New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add «Open in Finder / Explorer / …» to context menu #1859

Closed
timpulver opened this Issue Feb 28, 2016 · 17 comments

Comments

Projects
None yet
5 participants
@timpulver

timpulver commented Feb 28, 2016

I often need to access music files in Finder, e.g. to open them in another tagging application, copy them and so on. Right now I have to do: Right Click —> Information —> Copy Path —> Paste in Finder which is a long way.

@ned2

This comment has been minimized.

ned2 commented Feb 29, 2016

There is a Browse Folders plugin, which I use for this all the time. This brings your operations down to Right Click --> Plugins --> Browse Folders. But given that it likely a commonly desired feature and apparently not as well known as it could be, perhaps there could be an argument to move this to the main context menu as a core feature?

@declension

This comment has been minimized.

Member

declension commented Feb 29, 2016

@ned2 I agree actually... I've long thought it belongs in the core.

@lazka we could move to a pluggable provider style if we want to keep the flexibility... though really as long as it detects the "right" file manager I think most users won't care about configuring, (but will expect it to be there)

@timpulver

This comment has been minimized.

timpulver commented Feb 29, 2016

Just tried Browse Folders, thanks for the tip @ned2! Much faster than my initial workflow.
The plugin name Browse Folders is not fitting well imo, better would be Open In File-Manager or something like this. Browse Folders sounds like another pane to browse the music-collection by folder. When checking out the available plugins I thought of something completely different.

An improvement over the current Browse Folders-functionality would be if the file would be pre-selected in Finder / … . Currently only the folder is selected. As my DJ music-folder only contains single tracks this means I still have to manually search for the track I’m looking for.
Not sure if selecting files can be done in other file-browser other than Finder.

@lazka

This comment has been minimized.

Member

lazka commented Feb 29, 2016

@lazka we could move to a pluggable provider style if we want to keep the flexibility... though really as long as it detects the "right" file manager I think most users won't care about configuring, (but will expect it to be there)

yeah, I'd just have something like show_uris(uris).


Moving it into the core seems fine. I don't like that the menu is getting a bit long now... some alternatives/additional improvements to consider:

  • The name change to "Open In File-Manager" seems like an improvement.
  • We can add it to the default list of activated plugins.
  • We could order the plugins in the context menu by "most recently used".
@timpulver

This comment has been minimized.

timpulver commented Feb 29, 2016

We could order the plugins in the context menu by "most recently used".

I think that’s a bad idea. It’s much faster and less confusing if you know where to find a certain function. If the function you are looking for is moving, it will take longer to find it in the list – if you have multiple plugins activated you likely use more than one of them.

@lazka

This comment has been minimized.

Member

lazka commented Feb 29, 2016

We could order the plugins in the context menu by "most recently used".

I think that’s a bad idea. It’s much faster and less confusing if you know where to find a certain function. If the function you are looking for is moving, it will take longer to find it in the list – if you have multiple plugins activated you likely use more than one of them.

I do have 15 plugins or so enabled where I don't really remember where to find one without scanning through, but yeah, for less plugins that might be more confusing. An compromise would be to show the top 7 recently used plugins in normal order and hide everything else in a "More Plugins.." sub-sub-menu. But that's another issue, so feel free to ignore for this.

@lazka

This comment has been minimized.

Member

lazka commented Feb 29, 2016

@timpulver

This comment has been minimized.

timpulver commented Feb 29, 2016

Also it might be good to separate context-sensitive plugins from the others, e.g. Browse Folders can only be used when a track is selected, whereas other can be used all the time.

@timpulver

This comment has been minimized.

timpulver commented Feb 29, 2016

Not sure how to call that from Python/pyobjc.

Probably you have to call an automator script from python.

@timpulver

This comment has been minimized.

timpulver commented Feb 29, 2016

show the top 7 recently used plugins in normal order and hide everything else in a "More Plugins.." sub-sub-menu

This is a good idea!

@ned2

This comment has been minimized.

ned2 commented Feb 29, 2016

  • The name change to "Open In File-Manager" seems like an improvement.
  • We can add it to the default list of activated plugins.
  • We could order the plugins in the context menu by "most recently
    used".

I agree that the name change to "Open In File-Manager" is an improvement.

I get that cluttering the right click menu is a concern, but I also feel
that opening up songs in the file browser is a fairly fundamental activity,
and (maybe) especially for the Quod Libet user base, which I assume is
slightly more tech savvy. So I would argue that an exception should be made
in this situation. In which case, the changes to the Plugin menu might
become separate enhancements.

Reply to this email directly or view it on GitHub
#1859 (comment)
.

@lazka

This comment has been minimized.

Member

lazka commented Mar 4, 2016

Sounds good (I think I prefer "Show in File-Manager" actually, as it will open the parent dir and highlight the file in the best case).

I've opened #1875 for the too many plugins issue.

@CreamyCookie

This comment has been minimized.

Contributor

CreamyCookie commented Mar 10, 2016

I also think that "Show in File-Manager" should be part of the core, not just a plugin. It's just such an essential thing that it seems just a little bit weird to have it as a plugin.

Regarding the concerns about cluttering up the context menu. Maybe we could group all file related actions together:

  • Show in File-Manager
  • Copy to Device
  • Move to Trash
  • Remove from library

btw. Why are "Device", "Trash" etc. capitalized?

@declension

This comment has been minimized.

Member

declension commented Mar 10, 2016

btw. Why are "Device", "Trash" etc. capitalized?

Hmm, yeah it's a bit inconsistent. I think the idea is more that the whole phrase is title-cased and it's just the short prepositions that aren't. Gnome HIG has fairly clear guidelines to which we (inconsistently) seem to adhere. So perhaps here we should actually just capitalise library and similar.

@CreamyCookie

This comment has been minimized.

Contributor

CreamyCookie commented Mar 10, 2016

Interesting! Some examples of the Gnome HIG seem a bit weird to me ("Document Cannot Be Found" instead of "Document cannot be found"). I also wonder if capitalizing nouns really improves readability.. (Sadly I can't find studies about that! ^^)

However, I agree, making it consistent (in one way or the other) would be better!

@declension

This comment has been minimized.

Member

declension commented Mar 10, 2016

Agreed - they're a bit iffy in places. But consistent > partially perfect, so I fixed up a bunch in e783b77.

@lazka lazka added the enhancement label Mar 11, 2016

@declension declension added the plugins label Jul 5, 2016

lazka added a commit to lazka/quodlibet that referenced this issue Jan 8, 2018

Add a show_files() function which allows opening the file browser and…
… selecting files.

This extracts the functionality already present in the browse folders plugin
and generalizes it a bit to work on filenames and handle the case
where only a directory is passed and no entries.

Make the browse folder plugin use that new API.

And use the new API in show_uri() under Windows/macOS. The show_uri() API
Gtk/Gio provides isn't working for file URIs there for some reason
(the new "app info" plugin uses it for opening the configuration directory)

Related issue: quodlibet#1859

declension added a commit that referenced this issue May 12, 2018

Move Browse Files to core (fully)
 * Add SongsMenu entry if there are any files to show
 * Called it _Show in File Manager_ or _Show x files in File Manager_ for now. We can change it if this seems clumsy, but it's good to indicate the extent of what's going to happen (activating this on a playlist can be... _surprising_).
 * If we have too many files to show (configurable in prefs manually for now),
 disable the button (as a visual indicator) - i.e. reasonable defaults without bothering the user; not dealing with #2453 here...
 * Port the actual code from plugin, mostly.
 * Remove plugin itself
 * Add some tests, and clean them up a bit.

Fixes #2835, #1859
@declension

This comment has been minimized.

Member

declension commented May 12, 2018

Fixed in 546e9b5

@declension declension closed this May 12, 2018

declension added a commit that referenced this issue May 12, 2018

Fix POTFILES.in (#1859 / #2859)
 * Remove deleted plugin from `POTFILES.in`
 * Note to self: make sure `polib` is installed locally...
 * Also though: add test to check `POTFILES.in` manually for safety
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment