PM: Putting fonts in non-packaged/data/fonts does not seem to work

[stippi]

I've created the folder /boot/home/non-packaged/data/fonts and copied files there. This did not result in /boot/home/data to appear, also not after a reboot. I have then moved the "fonts" folder into /boot/common/non-packaged/data, but this also did not make it appear in /boot/common/data. In my case it already contained /boot/common/data/fonts/wenquanyi, but the non-packaged fonts did not appear alongside that packaged font. Also not after rebooting.

[Giova84]

Personally, to avoid this issue, i made an hpkg package which contains my personal/additional fonts. For now seems the only solution to install additional fonts on Haiku PM.

[bonefish]

Replying to stippi:

I've created the folder /boot/home/non-packaged/data/fonts and copied files there. This did not result in /boot/home/data to appear, also not after a reboot.

Um, they are not intended to. The code looking for fonts simply needs to consider B_USER_NONPACKAGED_FONTS_DIRECTORY and B_COMMON_NONPACKAGED_FONTS_DIRECTORY. Apparently this has been forgotten in the app server or the respective change had become a merge victim.

[stippi]

I thought the idea is that /boot/common is merged from both the packages and the contents of non-packaged. B_COMMON_FONTS_DIRECTORY should still point to /boot/common/data/fonts. Why is there the need to have additional directories? Obviously that would not only break our own applications. WonderBrush for example looks in B_COMMON_FONTS_DIRECTORY and is still broken even when app_server is fixed. It has its own font engine.

Doesn't that mean it is not transparent any more to applications, which stuff stems from packages and which from non-packages? How does it work for libraries? I thought a library could shadow a packaged library by putting a version in home/config/non-packaged/lib, which then appears in home/config/lib, shadowing any version from packages in home/config/packages. I would find it intuitive if it worked the same for fonts, or rather all of the folders in that hierarchy.

[anevilyak]

Out of curiosity, was it a typo that you wrote that you created /boot/home/non-packaged/data/fonts? I thought the packagefs mounts were at /boot/{system,common,home/config}, so I'm not sure what creating a directory at the spot that you chose was supposed to achieve, I'd have thought it'd need to be under config/non-packaged.

[bonefish]

Replying to stippi:

I thought the idea is that /boot/common is merged from both the packages and the contents of non-packaged.

No.

B_COMMON_FONTS_DIRECTORY should still point to /boot/common/data/fonts.

It does.

Why is there the need to have additional directories? Obviously that would not only break our own applications. WonderBrush for example looks in B_COMMON_FONTS_DIRECTORY and is still broken even when app_server is fixed. It has its own font engine.

Yes, but the same is true for B_COMMON_FONTS_DIRECTORY and BeOS applications, since /boot/common didn't exist back then. This is really a design flaw -- or rather lacking feature -- of the find_directory() functionality. There should really be a more abstract API that simply allows you to iterate through e.g. all font directories without having to enumerate them specifically.

Doesn't that mean it is not transparent any more to applications, which stuff stems from packages and which from non-packages?

Well, in the same way it isn't transparent which stuff stems from /boot/system and which from /boot/common or /boot/config/home.

How does it work for libraries? I thought a library could shadow a packaged library by putting a version in home/config/non-packaged/lib, which then appears in home/config/lib, shadowing any version from packages in home/config/packages.

No, the shadowing happens at the runtime loader level. The path ~/config/non-packaged/lib is simply listed before ~/config/lib in LIBRARY_PATH.

[stippi]

Replying to bonefish:

Replying to stippi:

Doesn't that mean it is not transparent any more to applications, which stuff stems from packages and which from non-packages?

Well, in the same way it isn't transparent which stuff stems from /boot/system and which from /boot/common or /boot/config/home.

An enumeration of directories would not do. Ideally, there would be just one virtual directory, where all the shadowing and even turning off user add-ons and data (in safe-mode) is already taken care of.

How does it work for libraries? I thought a library could shadow a packaged library by putting a version in home/config/non-packaged/lib, which then appears in home/config/lib, shadowing any version from packages in home/config/packages.

No, the shadowing happens at the runtime loader level. The path ~/config/non-packaged/lib is simply listed before ~/config/lib in LIBRARY_PATH.

Ok, but then it's not as elegant as I thought. I thought the directory structure stays the same on the surface, where package fs takes care of dynamically and magically blending the contents of packages and the non-packaged structure at these "old" directories. As it is, in various places, apps now need to be aware of package management, plus the non-packaged hierarchy as it turns out.

[jua]

I thought the directory structure stays the same on the surface, [...]

Up until reading this ticket, I thought the same. And looking at comments in e.g. ticket #10041 it seems more people have the misunderstanding as well. Maybe the wiki-entry should clarify how non-packaged works to clear that up.

[jscipione]

I also tried installing fonts into /boot/home/config/non-packaged/data/fonts and it did not work, but, I was able to install them by putting them into /boot/system/non-packaged/data/fonts

[bonefish]

In hrev46170 I think I accidentally fixed that fonts can be installed in /boot/system/non-packaged/data/fonts (formerly /boot/common/...). Not in non-packaged home path, though. I believe src/servers/app/font/FontManager.cpp is where it would need to be added.

[anevilyak]

Should be fixed in hrev46181.