Skip to content
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

File actions API #149

Closed
PVince81 opened this issue Jun 7, 2018 · 10 comments
Closed

File actions API #149

PVince81 opened this issue Jun 7, 2018 · 10 comments
Assignees

Comments

@PVince81
Copy link
Contributor

PVince81 commented Jun 7, 2018

A Phoenix app must be able to register custom file actions with handlers.

See the FileActions JS class in core to get an idea:

@felixheidecke we might want to chat about this at some point

@PVince81
Copy link
Contributor Author

PVince81 commented Aug 7, 2018

  • make sure to support multiple actions per mime type, etc. For example to make it possible to open text files both with the text editor and Collabora

@PVince81
Copy link
Contributor Author

some file actions will be about viewing and editing files, see #215

@felixheidecke
Copy link
Contributor

As discussed with @pvincent:
Apps will be able to register a file-action for the default click (first come, first serve). We will also send the click action to the event-bus so other apps and plugins will be able to pick it up and do whatever as long as it doesn't interfere with the file-action itself.

Optionally, we can have multiple file-actions registered and let the user choose the default app as it's common in windows. (The preferred app should be saved to the user setting)

select_and_ok

All those file-actions will also be available in the context-menu (right-click and the dot-dot-dot-menu)

@michaelstingl
Copy link
Contributor

michaelstingl commented Sep 20, 2018

@PVince81 Is there already a core API that exposes what actions are available for a file? (actions from core or apps)

Clients want to use this as well. Imagine a server app that shows up in the "three-dot-menu" in the web UI, but also in the "right-click-menu" of the desktop app for example. (would open the web UI with the selected app open in a defined state)

/cc @ogoffart @felixboehm @labkode @moscicki

@PVince81
Copy link
Contributor Author

The current core API is neither HTTP nor PHP. It's pure JS.
JS apps register actions and specify callbacks.

@DeepDiver1975
Copy link
Member

Apps will be able to register a file-action for the default click (first come, first serve).

I would not allow to change the behavior of the default action. I find this very confusing. Furthermore in case two apps register the default action: who wins?

Furthermore: registered actions can be rather heavy weigthed: collabore, only office, office online.
The fire of full actions on the backend system - we better not trigger that accidentially.

@PVince81
Copy link
Contributor Author

file actions are somehow tied to the file list: ex trashbin has different actions

@tempelgogo
Copy link
Contributor

tempelgogo commented Nov 22, 2018

As discussed with @pvincent:
Apps will be able to register a file-action for the default click (first come, first serve). We will also send the click action to the event-bus so other apps and plugins will be able to pick it up and do whatever as long as it doesn't interfere with the file-action itself.

Optionally, we can have multiple file-actions registered and let the user choose the default app as it's common in windows. (The preferred app should be saved to the user setting)

select_and_ok

All those file-actions will also be available in the context-menu (right-click and the dot-dot-dot-menu)

please take a look at the screenshots from #324 (comment)

@PVince81
Copy link
Contributor Author

yes. the above is only the "open with" action.
there are other actions like "share", "rename", etc.

@tempelgogo
Copy link
Contributor

tempelgogo commented Jan 8, 2019

It is possible to register multiple actions on a per-filetype basis since #356 is merged.
Apps can even provide custom icons for different filetypes e.g. office apps could provide different icons for their registered file extensions.

The app can additionally enable editing feature for it's own filetypes, so they will appear in ActionLauncher if you edit a file instead of just showing it; The App could react accordingly.

As discussed while UX workshop, other actions like share, rename, delete, etc. are not globally available, and therefore not exposed via 'phoenix app registration API'

So it seems, that all requirements of this issue are fulfilled.
I therefore take the liberty of closing this issue; please reopen it at any time if necessary.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants