hellosystem/applications

Application Bundles for use with helloSystem

applications's Issues

Krita does not use system theme

Even with export KRITA_NO_STYLE_OVERRIDE=ON, it insists on its dark theme which is totally broken on helloSystem. We want Krita to entirely forget about its dark theme and use the style/theme from Qt (not KDE) which we are using system wide on helloSystem.

How?

This is the broken state with export KRITA_NO_STYLE_OVERRIDE=ON:

There are still remnants of the dark mode.

This is how other Qt applications look, and how I would like Krita to look as well:

Need to find a way to skip PRE-INSTALL scripts

===> Creating groups.
Creating group '_sndio' with gid '702'.
pw: could not lock the group file: No such file or directory
===> Creating users
Creating user '_sndio' with uid '702'.
pw: group `702' does not exist
pkg.real: PRE-INSTALL script failed

Inkscape needs to be patched not to hardcode libicuuc version

libicuuc changes version numbers all the time. We want to use whatever the system provides, in the hope that it won't break.

    libicuuc.so.69 => not found (0)
    libicudata.so.69 => not found (0)
    libicui18n.so.69 => not found (0)

Converting svg to png fails

convert -fuzz 10% -transparent white -background transparent -resize 256x256 -gravity north -extent 256x256 Blender.app/Resources/usr/local/share/icons/hicolor/scalable/apps/blender.svg Blender.app/Resources/Blender.png
convert: attempt to perform an operation not allowed by the security policy `MVG' @ error/constitute.c/IsCoderAuthorized/422.
convert: no images defined `Blender.app/Resources/Blender.png' @ error/convert.c/ConvertImageCommand/3322.

libicui18n.so: Firefox tends to break when quarterly packages are updated in base system

After updating the system in Q1/2022, a Firefox app bundle built in Q4/2021 will no longer run because we now have libicui18n.so.70.1 rather than libicui18n.so.69 in the base system.

Apparently libicui18n.so changes its version number in the filename all the time, even within the same FreeBSD release, in incompatible ways.

XPCOMGlueLoad error for file /usr/home/user/Applications/Firefox 93.0.app/Resources/usr/local/lib/firefox/libxul.so:
Shared object "libicui18n.so.69" not found, required by "libxul.so"
Couldn't load XPCOM.

What is the right thing to do?

Consider shipping as .app.uzip rather than as .app.zip

This was made on FreeBSD 13 with

makefs '/home/liveuser/Desktop/Chromium.app.ufs'  '/home/liveuser/Desktop/Chromium.app'
mkuzip -A zstd -C 15 -o  '/home/liveuser/Desktop/Chromium.app.uzip' '/home/liveuser/Desktop/Chromium.app.ufs' 

The advantage would be that it could be nicely mounted by the kernel through https://github.com/vermaden/automount/ rather than through the slow, clumsy, and error-prone sysutils/archivemount/.

Blocked by:
vermaden/automount#34

Blender and probably other applications: libicu* tends to break because it is versioned

Workaround:

FreeBSD% cd "/home/user/Applications/Blender 2.91.0.app/Resources/usr/local/lib/"
FreeBSD% ln -s /usr/local/lib/libicudata.so libicudata.so.69
FreeBSD% ln -s /usr/local/lib/libicuuc.so libicuuc.so.69    
FreeBSD% ln -s /usr/local/lib/libicui18n.so libicui18n.so.69

Maybe we should do something like this for all our AppImages. Because the version of libicu* will get updated on the target systems, at which point the AppDir still needs to be able to find it...