[haiku-bugs] Re: [Haiku] #14277: Shortcuts: Improve interface
- From: "Haiku" <trac@xxxxxxxxxxxx>
- To: undisclosed-recipients: ;
- Date: Thu, 08 Aug 2019 18:15:49 -0000
#14277: Shortcuts: Improve interface
-------------------------------------+----------------------------
Reporter: Janus | Owner: leavengood
Type: enhancement | Status: assigned
Priority: normal | Milestone: Unscheduled
Component: Preferences/Shortcuts | Version: R1/Development
Resolution: | Keywords:
Blocked By: | Blocking:
Has a Patch: 0 | Platform: All
-------------------------------------+----------------------------
Comment (by pulkomandy):
Replying to [comment:21 humdinger]:
We can have the app name and icon shown, and double clicking that
opens the relevant Tracker window. Why would you bother with showing and
allowing to manually edit the path for this?
As I said, to optionally add parameters (if that is supported).
Why should the parameters and the app path be in the same small textbox?
I can see the need for a textbox for the parameters, but not for the app
path, really.
Again, this is what Backgrounds does, it allows you to reach the
recently used files, or to browse for more. Just what we need here too,
and it's easier to locate apps (they are all in /boot/apps) than to locate
backgrounds (they are pretty much anywhere in your home dir)
I still don't see it. Choosing the app to open with a shortcut is a one-
off occasion. Having the last 5 or 20 recently 'shortcutted' apps in a
popup menu doesn't help. Only offering the last paths (/boot/apps/) and
opening the file panel there to choose an app isn't very useful either.
Same can be done by setting the file dialogs start location to it. The
"Browse..." button even saves one mouse click compared to the popup menu.
:)
Well, a browse button with no popup menu and no textfield either, then?
The textfield is clumsy for picking an app, the browse button will not
know what to do if the previous text field content had arguments to the
app, should these be preserved?
I'd say, no. The chances that another app uses the same parameters are
small. Frankly, I suspect that normally the target app won't be changed
often. Once you 'shortcut' an app you may change the keycombo or remove
the whole shortcut to that app, but only seldom decide to re-use the
shortcut to one ap for another.
You are contradicting yourself, as you previously brought the example of
changing the path to an application that has been moved or to point to a
custom build of it, in which case I think it makes sense the arguments
should be preserved.
But, besides this special case (which I find somewhat unlikely), I don't
think directly editing the path is desirable.
The issues I can see with "getsuites": Most apps don't have those
implemented and you just cannot fix them all. Also, the app has to be
running to query it.
The app has to be running for the shortcut itself to do anything as
well.
That's a given. Users expect that the thing they want to control has to
be running. They probably won't expect that simply creating a message
shortcut does, too.
Once you have picked the app, Shortcuts could run it on its own, ask it
its "getsuites", and then quit it, maybe? Or maybe we need to improve the
"getsuites" system to work offline?
Are we going to use this for anything else than servers anyway? Are
there use cases for automating things in regular apps from Shortcuts? (I
can imagine something like autohotkey, but I'm not sure Shortcuts is the
right place for it?)
Who knows? I'm not at all against providing 'standard actions' for known
apps/servers, however we go about providing these messages. I'd just like
to offer the possibility to send an arbitrary message to something.
I don't like this at all. As an application developer, it means all the
internal messages I use in my app suddenly become API, and if I change
them, some user will complain that I broke their setup. Or they could
manage to corrupt the application state in ways I didn't anticipate. This
is too brittle.
On the other hand, the "getsuites" system is actually designed for this,
and allow the developers to make sure they expose sane things through the
interface. This is much less dangerous, even if initially less flexible.
And I'm not sold on "who knows?" without some sample use cases.
There is a need to think more about these application specific shortcuts.
For example, I expect the next/previous media buttons to do the right
thing to whatever media application is running currently, be it APlayer,
MediaPlayer, or VLC, for example. I don't want a system-wide shortcut
entry that attempts to send a message to all 3 (and does not work
everytime I add a new media playing app to my system).
Probably each app needs to hook for these by itself while it is running,
that seems to be the best thing to do after all.
I think we should try to have something much simpler as part of the
default system. I can imagine the need for a more advanced tool, but I
think it's going to be a complex tool, and I'm not sure it's a great idea
to do everything at once in a single application that we ship by default
with the OS.
Anyway, I guess anything is better than the current situation?
--
Ticket URL: <
https://dev.haiku-os.org/ticket/14277#comment:22>
Haiku <
https://dev.haiku-os.org>
The Haiku operating system.
Other related posts:
