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

Remove ShortcutReader #1069

Open
madoar opened this issue Jul 7, 2019 · 6 comments
Open

Remove ShortcutReader #1069

madoar opened this issue Jul 7, 2019 · 6 comments
Assignees

Comments

@madoar
Copy link
Collaborator

madoar commented Jul 7, 2019

As an alternative to #1068 we could think about remove ShortcutReader because it basically functions as a wrapper for a concrete engine specific shortcut reader implementation (currently only WineShortcutReader). Therefore we could alternatively use the concrete engine specific WineShortcutReader instead. If we later on add other shortcut reader implementations we would then need to add some selection logic in Java to choose the correct shortcut reader implementation.

See also PhoenicisOrg/phoenicis#2025

@plata
Copy link
Collaborator

plata commented Jul 7, 2019

Makes sense for me but I would like @qparis to decide.

@qparis
Copy link
Member

qparis commented Jul 8, 2019

For the moment I agree.
The shortcut thing has been made quickly so that we have something that can work, but it clearly lacks some features.
At the target, we could use a template system like mustache to generate different kinds of shortcuts

@madoar
Copy link
Collaborator Author

madoar commented Jul 9, 2019

At the target, we could use a template system like mustache to generate different kinds of shortcuts

The suggestion targets not the creation of new shortcuts just the reading part. I don't think a template system would work for reading. Another idea is: do we really need a custom shortcut reader for every engine type? Or can we create a more abstract implementation which delegates some tasks to the engine implementation?

@plata
Copy link
Collaborator

plata commented Jul 9, 2019

Or can we create a more abstract implementation which delegates some tasks to the engine implementation?

Could work. But probably this would only lead to the WineShortcutReader being moved inside of the Wine implementation. Is it an advantage compared to having it separated?

@madoar
Copy link
Collaborator Author

madoar commented Jul 11, 2019

I think this depends on how we define a shortcut. For me a shortcut is simply a location and a visualized name. A shortcut has the meaning that the file at the given location can be accessed with an application the user has installed.

The open question in this definition is: how can the file at the location be accessed, i.e. with which application? The answer to this is in my opinion given by the used engine. Therefore I think it is fine to add the shortcut execution logic directly to the engine implementation.

Slightly off-topic:
We could also think about adding other kinds of shortcuts that don't depend on the engine. For example shortcuts for text files. A text-file shortcut would then open a system editor for the specified text-file.

@plata
Copy link
Collaborator

plata commented Jul 26, 2019

@qparis what's your definition of a shortcut? Given @madoar's definition, we could even thing about using the Appdata standard and get rid of our custom shortcuts directly.

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

3 participants