I have an application that is written using c++ and the wxWidgets toolkit. Several years ago I was able to port it to Haiku via wxQt, although it was quite buggy. I put it on the back burner until recently when I installed beta4. Since then both gtk and wxGtk have been ported, making my app build and run pretty well with very few changes.
For the anyhow of it. I decided to try building an installable package via the makefile. Using package, rc, and resattr along with a .PackageInfo file, I got it to generate a HKPG that installed perfectly, including Deskbar integration and a vector app icon.
I installed it and it ran perfectly until I tried to make changes to the application database which I had stored in data/ in the package. Turns out no rw for the /system/data/ folder. So I decided to try putting the appās data folder into /system/settings/.
Copying the app into an apps/ subfolder and app data into a data/ subfolder resulted in those files being installed to /system/apps/ and /system/data/ when the package was activated via HaikuDepot. However this did not seem to work with settings no matter what I tried.
Under Linux my app looks for ./Data_Folder_Name. If itās run from a folder, it looks in that folder. Otherwise it looks in ~. Under Windows it only looks in the same folder. I can set rw permissions for the data folder via the installer. Under macOS it gets included in the .app and gets copied to ~ on the first run.
After tinkering a little, I discovered that Haiku also looks in the local folder or home folder. However Iām at a loss on how to get that folder to where it needs to be via the package. I guess I could probably install it to /system/data then copy to ~ at first startup. But Iād like to try to install directly from the package if possible.
Then too, it seems ādotā application data folders are kinda frowned on in Haiku. I have not found a clear explanation on where exactly applications are supposed to store their rw resources. I can very easily modify my app to look in specific folders, but I like to know where the acceptable place would be and how to get the data there.
@mill-j
Haikuās packages are read-only. The contents cannot be changed. The storage of settings (dotfiles in Linux) go in ~/config/ subfolder designated to your application (I think itās ~/config/settings/appname/). Thereās another subfolder in there for application datafiles as well.
Another, maybe better, solution is to have the package install to the data folder - I suppose using ~/config/data/yourapp/ would be better than /system/data/yourapp/ in case Haiku becomes multi-user in the future.
Then your app checks on startup if there a user database at ~/config/settings/yourapp/ and if there isnāt copy it from ~/config/data/yourapp/. That way you have a way to recover, should users delete the database file in their settings folder.
There should be a difference in user data and system data, the latter comes with the app and is mostly installed in $dataDir (this is āmostlyā not required to be write able), the user data is something the app should look for and should point to ~/config/non-packaged/data, thereās also user config files, these should go to ~/config/settings/appName. My 2 cents
Have the package put the āemptyā database into /system/data/yourapp/
Use BPathFinder to load your database with B_FIND_PATH_DATA_DIRECTORY.
Itāll find a database in /boot/home/config/non-packaged/data/yourapp/ first, if not there it gets it from /system/data/yourapp/.
Save your userās database in /boot/home/config/non-packaged/data/yourapp/.
Thereās the findpaths command available to experiment in Terminal.
Iām wondering if boot/home/config/non-packaged/data/yourapp/ is the right choice. In theory
non-packaged directory should be used for, wellā¦ non-packaged software, shouldnāt it?
For packaged applications I donāt find it coherent. I would go for ~/config/settings/appName.
On a side note, I think the non-packaged directories require some clarity on when they should be used and the different recommendations provided above are maybe a sign of this unclarity?
IMHO, non-packaged should be used only for applications installed manually or by any other mean but a hpkg. non-packaged/data should be used for data, assets, and other resources that come with the software. Any other user data (preferences, project-related files, etc.) should go into ~/config/settings/appName. Any thoughts?
If I understand that correctly, I tend to agree. However, in case of an update the script should take care of any existing setting and not only not overwriting it but possibly migrating it to a new format, if applicable.
I can just provide my own take on this which is: this is the place for a piece of software (applications, add-ons, drivers, and more) that is not installed via the package manager.
I donāt think that non-packaged means anything that is not inside a package.
I see it as a mean for a user to install something that does not come with a hpkg, or if they want to customize the flags or the icon of a packaged app by installing it manually or more often a way for developers to quickly test their own software.
Does it make sense?
I think we can agree that thereās some confusion and things arenāt always easily separated between what should go into āsettingsā and what into ādataā.
Generally, I like the idea of an app having one folder for writable files, e.g. settings and databases etc. So, ~config/settings/ seems to be fine.
In this case, I just thought itād be elegant to use B_FIND_PATH_DATA_DIRECTORY as itād load the user modified file and automatically fall back to the package-provided āemptyā database.
WRT ānon-packagedā, I think in past discussions there was the opinion, that itās just called that way for the lack of a better name. It wouldnāt be needed, if we had ātransparently mergedā folders, i.e. one folder that shows e.g. a merged ~/config/data/ and ~/config/non-packaged/data/ (though IMO that could also be problematic, because thereās be no distinction whatās writable and whatās not).
Meaning, ānon-packagedā can just as well be used by applications that are themselves packaged.
I think. Others may have a better understanding of it allā¦
Try my tutorial (BeSly knowledge base)about porting compiled software, because here we have most times problems with files they need to placed at other places as the package himself.
Although it is used mostly for settings, thereās also the possibility to make a packaged file writable. Hopefully, it seems that thereās no abusive use of it yet.
From a user point of view, I like the idea to keep user data and settings separated. Sometimes, old settings can be incompatible with the new version specially if you waited long before upgrading. In these cases, you may prefer a fresh start. Thatās almost never the case with user data or an importation thing is provided.
Thanks everybody. It appears that installing app data to /system/data/appname and copying it to /home/config/settings/appname on the first run is the way to go.
Only one problem. Iām using wxGTK. I can modify two lines of code and Iām good. Using another API would require linking against just another library that doesnāt exist on any other platform.
I donāt see /system/data changing anytime soon. And if Haiku becomes multi-user, it should still be fine since the app uses the working directory (currently home folder) as a starting point to find config/settings/.
There are some other possible locations to install , but that doesnĀ“t mean those are the recommended ones.
Same as MS directory conventions, from the times of Windows 3.x onwards : there was the āofficialā way, mentioned in the documentation, and then there are the million of different ways developers chose to use ājust becauseā. Or in linux, same thing. And that brings us to our current chaotic situation ā¦
