Have seen in the ArtPaint package, the add-ons folder is stored in the program folder. This is write-protected. If it is not the correct way to create a link to /boot/home/config/settings/Artpaint/add-ons and then insert a post-install script that contains a package with the add-ons (add-ons.zip) from the program folder to /boot/home/config/settings/ArtPaint/ unpacked? Then you could manually add additional add-ons if available.
Or is it possible to create a package with the advanced add-ons, which is then inserted into the ArtPaint program folder when installing the hpkg? (Not tried so far).
I’d use (system|config)/add-ons/ArtPaint/ as the folder for add-ons and put the add-ons in separate .hpkgs which show up in that folder.
If you have installed several .hpkgs with files for the same folder, they all get combined and all the files show up in that folder. The only confusion is when the same file name is in two or more .hpkgs, then it’s random which one actually gets to be the file.
Or ArtPaint could be modified to search in system/config/add-ons and in /home/config/non-
packaged/add-ons too.
So it would be possible to install packaged and non-packaged add-ons too, and ArtPaint would pick all of them at start (preferably the higher version if something duplicated)
This is what I’m assuming will happen at the moment. An HPKG could contain just new add-ons, that would get added to the ArtPaint subfolder. If anyone does actually create their own add-on [which I’ve yet to see happen!] they can simply put it in an HPKG thgemselves. A future release of ArtPaint I’m sure could be extended to accept them in additional locations…
I think I’d keep the location of the basic add-ons as the current subfolder, but it sounds like a good idea to have an extended search path that includes all the above.
This means it is possible to install add-ons in any of these directories and they should be picked up. If that doesn’t work, then ArtPaint needs to be fixed
This makes it possible to put add-ons next to the application (in case they are specific to said app and not usable as generic things), or inside the non-packaged directory, if they are not in a package.
Unfortunately the idea of “slapping together and add-on” and wanting to plug it in is not reality. Once upon a time, Heikke intended an “Add-on Construction Kit”, but it never emerged, and anyway that was before he open-sourced the whole thing. So if you want to create a new add-on, the only practical route is to get the entire source (clone or download) and delve into the mechanisms that add-ons use. And while you’re doing that, you’ll surely take the 2 or 3 minutes to run the included build.sh that generates your own complete version of the app and its add-ons, so you have your own testing environment.
And when you have a final add-on version you want to distribute, I don’t find it much trouble to put it into a simple hpkg. Ten minutes work at the most. So though it would be nice to have a choice of locations, I don’t see it as urgent.
Hmm. The BeBook doesn’t exactly make this clear! [and I can find no reference at all in the Haiku Book]. “pathname can be absolute or relative; if it’s relative, it’s reckoned off the base path specified by the ADDON_PATH environment variable.” Which doesn’t really sound like a search… [Guess that’s why BeOS apps don’t seem to do that!]
ArtPaint actually does its own search, using absolute paths. Unfortunately it takes no account of PM, so it only looks in the read-only directories – a bit useless at the moment.
Looking at the actual ADDON_PATH, though, the leaf-directories all seem to be “add-ons”. Obviously ArtPaint add-ons would have to be in an ArtPaint subfolder – except for the local folder! So it wouldn’t be quite automatic.
The problem is that load_add_on only works if you already know the name of the add-on. So apps need to enumerate the add-ons in some way first. This is why we introduced the new BPathFinder API in Haiku (still not documented…) to ease the search and enumeration process.
