I just noticed that the traditional way with a suffix-X added to the filename as in BeOS is not recognised by Haiku. Neither is the suffix cropped off in the add-on menu. Yet the default add-ons that ship with Haiku has associated shortcuts. I suspected it may be stored in attributes, because there was some discussion about using attributes insted (from before package manager), but that turned out not to be the case.
So the actual question: how can I add a shortcut to my Tracker add-ons?
Another difference I noticed is that I can’t disable add-ons, for example a translator, with the .disabled suffix as was the case in BeOS. Was this feature deliberalely removed, or just hasn’t been implemented yet?
Is there a “Haiku book” or some place where similar differences are documented?
The default shortcut is defined in the ressources. Add this to your rdef file for “P” s example:
resource("BEOS:default_shortcut") "P";
No idea about a “.disabled” suffix, but since most software today comes as a package, you wouldn’t be able to edit the file name. Now you deactivate (parts) of packages, see Disabling components of packages.
You can override the default Tracker add-on shortcut with the Shortcuts preferences: just add a new shortcut, set it to e.g. ALT+OPT+P and choose the Tracker add-on as target.
Yes, this works! Thank you, sir. (Not very user-friendly, though).
It reads “default shortcut“ - which implies that there is some mechanism to override it.
Is there?
The trick with the Shortcuts preferences doesn’t seem to work. It only opens the add-on as a normal executable, not in context as an add-on. The list of selected files etc. is not passed, so it is rather useless.
Defining shortcuts in ressource files is not something usually done by end-users. For the dev of the app it’s as simple as setting any other ressource, like the app signature, icon, or supported filetypes etc.
I just tried with PecoRename - setting an overriding shortcut - and after quitting/restarting Tracker it does work: the selected files open in PecoRename when using the new shortcut.
Maybe check out where your add-on differs from the PecoRename add-on.
I’m sorry, I’m not sure I’m doing things right. So I opened Preferences → Shortcuts. Then added a line Alt=Either, Option=Either, Key=A, Application=/boot/system/add\-ons/Tracker/PecoRename. Clicked Save & apply. Restarted Tracker. But it does nothing because it is just trying to start PecoRename as an executable.
Which is giving us the following output from the Terminal:
bash: /boot/system/add-ons/Tracker/PecoRename: cannot execute binary file: Not an executable
But is invisible when invoked by a shortcut.
Am I doing something wrong? Does the target in the “Application“ field require some protocol definition, perhaps? Or am supposed to use the app signature instead of the filename?
I do agree that it is not something users do or should do. But if there is no other way to define a shortcut for an add-on (which IS something the user definitely want to and should be able to easily do), editing the file resources with Resourcer, for example, is not an user-friendly solution. Also the fact that the Tracker needs to be restarted for a new shortcut to work is not user-friendly either.
Reasons the user wants to define shortcuts:
-he created a new add-on with ZooKeeper or similar “programmable” add-on
-he has an older add-on that still relies on the old suffix method which is not working now
example: TrackerGrep
-he is using different locale than english and wants his shortcuts to reflect the localized add-on names
I didn’t quite get the last sentence. Doesn’t it do anything, or start the PecoRename empty, i.e. without the selected files loaded?
How you describe your configuration, it should work. However, you wrote that as application you have: /boot/system/add\-ons/Tracker/PecoRename
There’s a wrong escape-“\” in there. Should be: /boot/system/add-ons/Tracker/PecoRename
You can right-click the field in the “Application” column and choose the first item in the context menu to get a file dialog. It’s easier to navigate to the app/add-on and less error prone than typing a path.
There’s a related ticket, Tracker add-ons: non-unique shortcuts fail silently, where madmax has fixed some issue, but also remarked that restarting Tracker isn’t very nice, but that it’s apparently not super easy to fix.
Agreed, setting shortcuts by the user is desirable. The Shortcuts preferences isn’t very userfriendly in general and using it for add-on shortcuts isn’t that obvious…
-he created a new add-on with ZooKeeper or similar “programmable” add-on
Maybe ZooKeeper could offer to set a shortcut in the generated add-on? Consider opening a ticket at its bugtracker.
Ahh, you are right, sir. I removed the escape and it works now. Btw, it wasn’t there by mistake but because there’s a path not found error in the background if the path is not “quoted“ or the hyphen is not escaped. But I guess Tracker (when looking for shortcuts) is scanning the settings file for literal paths so it doesn’t recognise the entry if it’s quoted. I’m not sure, though, if it is an elegant solution to rely on this error to prevent the add-on from running also as an executable. Anyway, thank you very much for your assistance.
I am already working on modernising ZooKeeper, so I guess I’ll just add this proposed option now that I know how it works.
I should really, really, write my TODOs somewhere. Though gerrit shows your pending patches already when you log in, so I don’t know if that’d really be of any use.
The thing I fixed is in fact the part about having to restart Tracker. I just didn’t push directly. I’ll see if I can retest the patch this weekend and push if it still works.
The part which I felt I’d have to understand many details before I touched and even then might not be able to solve myself was the one about the duplicate shortcuts.
For the dev of the app it’s as simple as setting any other ressource, like the app signature, icon, or supported filetypes etc.
