simon.schönbeck.dk

Tag: Kinoite

  • Android Studio Flatpak light/dark theme automatic change bug fix

    It is nice to have the desktop automatically change its theme from light to dark at sunset. Most applications work by default without further action in Fedora Kinoite. However Android Studio despite supporting light & dark themes for ages did not offer the option to automatically change the theme in Linux until very recently.

    After enabling the “Sync with OS” setting unfortunately nothing happened. Not even a restart of the application changed the theme. Guess Linux is still Linux where everything needs a bit of dedication to properly work.

    So digging into the topic it is (what else!) a Flatpak permissions issue. The dbus communication is not going through between the system and the application. After enabling the permissions I managed to get Android Studio to read the current theme on launch. But this was just a dead end as the automatic switching was still not working, I had to restart Android Studio to pick the switched theme which was not great for the workflow.

    After some time scouting sources of both Android Studio (really IntelliJ IDEA by JetBrains) and the application’s Flathub repo, the culprit was found. Android Studio itself is working fine as on a non-atomic system not using the Flatpak version there is no problem. The issue was in the Flatpak’s environment that missed a specific component, namely dbus-tools. Inside this module the command dbus-monitor is found and this is missing from the current Flathub build.

    The dbus-monitor is used to do exactly as its name states, it monitors the dbus for changes (signals) and this is what Android Studio uses to get the “color-scheme” parameter from the system. If this command cannot be executed it just dies silently and automatic theme change will not work. In a non-atomic system dbus-tools is part of the core system but Flatpaks run in a bare-bones environment and in this case the module is not included.

    To confirm this hypothesis I created my own Flatpak including dbus-tools:

    {
  "name": "dbus-tools",
  "buildsystem": "meson",
  "config-opts": [
    "-Dtools=true",
    "-Dmessage_bus=false",
    "-Dsystemd=disabled",
    "-Dx11_autolaunch=disabled"
  ],
  "sources": [
    {
      "type": "archive",
      "url": "https://dbus.freedesktop.org/releases/dbus/dbus-1.16.2.tar.xz",
      "sha256": "0ba2a1a4b16afe7bceb2c07e9ce99a8c2c3508e5dec290dbb643384bd6beb7e2"
    }
  ]
},
...

    There are a few more tweaks that are not relevant for the case in question but are just to get the Flatpak built with less overhead:

    $ cat com.google.AndroidStudio.Test.json 
{
  "id": "com.google.AndroidStudio.Test",
  "runtime": "org.freedesktop.Sdk",
  "runtime-version": "25.08",
  "sdk": "org.freedesktop.Sdk",
  "command": "android-studio-wrapper",
  "finish-args": [
    "--socket=x11",
    "--socket=pulseaudio",
    "--socket=ssh-auth",
    "--socket=gpg-agent",
    "--share=ipc",
    "--share=network",
    "--device=all",
    "--filesystem=home",
    "--allow=multiarch",
    "--env=JAVA_HOME=/app/extra/jbr",
    "--talk-name=org.freedesktop.Notifications",
    "--talk-name=org.freedesktop.secrets"
  ],
  "modules": [
    {
      "name": "dbus-tools",
      "buildsystem": "meson",
      "config-opts": [
        "-Dtools=true",
        "-Dmessage_bus=false",
	"-Dsystemd=disabled",
        "-Dx11_autolaunch=disabled"
      ],
      "sources": [
        {
          "type": "archive",
          "url": "https://dbus.freedesktop.org/releases/dbus/dbus-1.16.2.tar.xz",
          "sha256": "0ba2a1a4b16afe7bceb2c07e9ce99a8c2c3508e5dec290dbb643384bd6beb7e2"
        }
      ]
    },
    {
      "name": "android-studio",
      "buildsystem": "simple",
      "build-commands": [
        "install -D -t ${FLATPAK_DEST}/bin/ apply_extra android-studio-wrapper",
        "echo '[Desktop Entry]' > test.desktop",
        "echo 'Type=Application' >> test.desktop",
        "echo 'Name=Android Studio Test' >> test.desktop",
        "echo 'Exec=android-studio-wrapper' >> test.desktop",
        "echo 'Icon=com.google.AndroidStudio.Test' >> test.desktop",
        "echo 'Categories=Development;IDE;' >> test.desktop",
        "install -Dm644 test.desktop ${FLATPAK_DEST}/share/applications/${FLATPAK_ID}.desktop",
        "echo '<?xml version=\"1.0\" encoding=\"UTF-8\"?>' > test.metainfo.xml",
        "echo '<component type=\"desktop-application\">' >> test.metainfo.xml",
        "echo '  <id>com.google.AndroidStudio.Test</id>' >> test.metainfo.xml",
        "echo '  <metadata_license>CC0-1.0</metadata_license>' >> test.metainfo.xml",
        "echo '  <project_license>Apache-2.0</project_license>' >> test.metainfo.xml",
        "echo '  <name>Android Studio Test</name>' >> test.metainfo.xml",
        "echo '  <summary>Test Build</summary>' >> test.metainfo.xml",
        "echo '  <description><p>Testing theme switching configuration.</p></description>' >> test.metainfo.xml",
        "echo '  <launchable type=\"desktop-id\">com.google.AndroidStudio.Test.desktop</launchable>' >> test.metainfo.xml",
        "echo '</component>' >> test.metainfo.xml",
        "install -Dm644 test.metainfo.xml ${FLATPAK_DEST}/share/metainfo/${FLATPAK_ID}.metainfo.xml",
        "echo \"<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 10 10'><rect width='10' height='10' fill='purple'/></svg>\" > test.svg",
        "install -Dm644 test.svg ${FLATPAK_DEST}/share/icons/hicolor/scalable/apps/${FLATPAK_ID}.svg"
      ],
      "sources": [
        {
          "type": "extra-data",
          "filename": "android-studio.tar.gz",
          "size": 1541218005,
          "only-arches": [
            "x86_64"
          ],
          "url": "https://dl.google.com/dl/android/studio/ide-zips/2026.1.2.10/android-studio-quail2-linux.tar.gz",
          "sha256": "64445a54092e7056c6eb7f1a89ad116d0feec2ef5f965b8e594d62abdb58590f"
        },
        {
          "type": "script",
          "dest-filename": "apply_extra",
          "commands": [
            "tar xzf android-studio.tar.gz --strip-components=1",
            "rm -f android-studio.tar.gz"
          ]
        },
        {
          "type": "script",
          "dest-filename": "android-studio-wrapper",
          "commands": [
            "/app/extra/bin/studio $@"
          ]
        }
      ]
    }
  ]
}

    Then you install flatpak-builder, build your custom Flatpak and when finalised you can test it out:

    $ sudo dnf -y install flatpak-builder git
$ flatpak-builder --user --install --force-clean --disable-rofiles-fuse build-dir com.google.AndroidStudio.Test.json
$ flatpak run --command=dbus-monitor com.google.AndroidStudio.Test

    If the last command displays content it means dbus-monitor is now part of your Flatpak’s environment and you can safely launch the full appplication:

    $ flatpak run com.google.AndroidStudio.Test

    I ran all inside a toolbx so that I can get rid of it again easily. Also it should not affect your existing Flathub Android Studio installation, it is a completely parallel Flatpak (com.google.AndroidStudio.Test).

    Now the best moment comes, going into Settings>Appearance and enabling “Sync with OS“. Immediately Android Studio should change its theme to the system one. An easy way to change your theme if you have sunrise & sunset as triggers, is to simply change your location in the KDE Plasma settings e.g. to the other side of the planet, then you can quickly revert back and forth.

    As this is only a personal solution I have also created an issue at the Flathub repo so hopefully we will soon see this Android Studio Flatpak correctly switching light to dark themes and viceversa automatically for everyone.

  • Persist Asus battery charge limit after reboot on Fedora

    Despite many issues reported over the last years about this problem, as of Fedora Kinoite 44 on kernel 7.1.3 with KDE Plasma 6.7.2 it is still not possible to persist the battery’s maximum charge limit upon a reboot. To be fair it is mainly due to the laptop manufacturers’ way of resetting the value to 100% charge level upon each boot.

    Having to remember and set this value upon each boot may seem like no task but it becomes a real nuisance after each update. Running Fedore Kinoite means that a reboot is needed after each system upgrade so it happens more often than perhaps in the past when only a kernel upgrade needed a reboot.

    In this scenario the 2024 Asus TUF laptop does accept custom set charge limits providing plenty of flexibility for multiple use cases. I would usually set it at 50% level unless the laptop is needed on batteries later where it can then be raised to 80% prior to leaving AC power. This should ensure future battery health for many years.

    The “Charge Limit” value is set inside the “Power Management” settings under “Configure Advanced Settings” in the top right corner. I would guess each laptop would have different options depending on what the hardware exposes to the system. By default the value is 100% after boot so simply change it to the value you desire. You will be asked to authenticate as it is a system wide setting.

    Avoiding this cumbersome task is rather simple though. Until it gets fixed we can just set the charge limit programmatically upon each boot. There are several ways to skin the cat so the following is in my opinion the simplest and cleanest one. Using the tmpfiles.d service we can do this pretty fast (if curious there are many systemd-tmpfiles uses).

    First we can actually check the current battery charge limit value (please note BAT0 may instead be BATn on your device, usually 0-4):

    $ cat /sys/class/power_supply/BAT0/charge_control_end_threshold
100

    Then let us set and get the new value through here instead of using the GUI:

    $ echo 50 > /sys/class/power_supply/BAT0/charge_control_end_threshold
$ cat /sys/class/power_supply/BAT0/charge_control_end_threshold
50

    This would work fine for a quick change but now we will create the instructions to tmpfiles to do it at boot instead:

    $ sudo vim /etc/tmpfiles.d/asus-battery.conf
$ cat /etc/tmpfiles.d/asus-battery.conf
# Type  Path                                                 Mode UID  GID  Age Argument
w-      /sys/class/power_supply/BAT0/charge_control_end_threshold -    -    -    -   50

    The formatting needs to be as is, so please bear in mind that depending on the width of your screen it may not be displayed properly right here, so if you copy and paste the content into a text editor it would be easier to see. The first line is just a comment for reference so you get the idea of each column, the real action happens in the second line. Here the value of 50 is written into “/sys/class/power_supply/BAT0/charge_control_end_threshold” just as we did manually before.

    After next reboot the system will automatically change the charge limit, to 50% in this case. Obviously just change this value to the desired default. Please note that you can always later modify temporarily the limit in the GUI settings as shown earlier. This last change would apply until next reboot only.

  • AppImages require FUSE to run in Fedora Kinoite 44

    When running the latest VictronConnect Linux AppImage (v6.34) on Fedora Kinoite 44 an error is reported and it fails to launch:

    dlopen(): error loading libfuse.so.2

    AppImages require FUSE to run.  
    You might still be able to extract the contents of this AppImage if you run it with the --appimage-extract option.  
    See https://github.com/AppImage/AppImageKit/wiki/FUSE for more information

    Fedora actually came by default with both FUSE 2 and 3 but since version 44 FUSE 2 is no longer included due to security concerns.

    The option to run this AppImage and any other for that matter is to run it with the “–appimage-extract-and-run” parameter. This would simply extract its content directly on disk and delete it afterwards. Usually it would have run inside the FUSE virtual file system:

    $ Downloads/VictronConnect-x86_64_v6.34.appimage --appimage-extract-and-run

    The real solution would be for the Victron developers to use the latest AppImage which has FUSE 3 built-in.

  • Toolbx mount access from host on Fedora Kinoite

    Since Toolbx mounts are running in different namespaces than the host, the mounts cannot be accessed from the latter. I tried many workarounds to see if it really was possible to get around this limit. After some time I decided that using the network stack was probably a better solution to communicate between Toolbx and host.

    In my particular case I never do any layering but instead try to use Flatpak, Toolbx, or even a Boxes virtual machine for any specific software not included in the base layering.

    I needed to run restic to access some documents on a remote restic repo backup. Since restic is not included I had to use Toolbx for this task. Restic uses FUSE to mount the remote end on the local system. In an ideal world I could just have opened this mount in Dolphin to search and open the needed documents. However due to the namespaces difference this mount just shows empty on the host.

    A really quick and dirty solution is to simply use rclone and its webdav option, then Dolphin just opens the webdav address with no issues. Yes, there is a tiny performance hit, but the speed and easy execution greatly makes up for this:

    restic mount ~/remote-restic

    Now that the mount is working from Toolbx itself run rclone to serve it over the network:

    rclone serve webdav ~/remote-restic --addr :8080 -L

    That is all! Now simply open Dolphin and paste the webdav address and there you have your Toolbx mount visible from the host:

    dav://127.0.0.1:8080

    Please note that this is not only for restic but can be used with any mount type like sshfs or even another rclone mount like S3.

    Is it not ironic… using a 1990s protocol (WebDAV) to solve a 2026 container problem!

  • Firefox not opening mailto links in Flatpak Thunderbird

    Using Fedora Kinoite Thunderbird comes in a Flatpak. This caused me issues with mailto links in Firefox not opening Thunderbird’s new email window.

    Usually just setting Thunderbird as the default email client inside Thunderbird’s settings or KDE’s default applications would have worked. Even selecting Thunderbird inside the Firefox file handler applications settings would have done the job. However mailto links did nothing but open up the application selector in Firefox which did not work.

    The first two places were already set correctly (in Thunderbird and KDE) so not much more to do there. As I cannot directly select Thunderbird’s binary since it is a Flatpak, I tried to get Firefox to open the Flatpak binary instead and somehow customise the command being run.

    There was just no way to customise the command through its interface, unless I fiddled with handlers.json directly in my Firefox profile directory. I tried a few combinations and no dice. I was also still reluctant to believe that all other users would go through this mess just to get mailto links working which is such a basic feature.

    The most annoying part was that XDG actually returned Thunderbird as the default handler for mailto links:

    $ xdg-mime query default x-scheme-handler/mailto
    org.mozilla.Thunderbird.desktop

    But checking my ~/.config/mimeapps.list file revealed that there was no mailto handler defined. Adding the corresponding entries finally fixed the issue:

    [Added Associations]
    x-scheme-handler/mailto=org.mozilla.Thunderbird.desktop;

    [Default Applications]
    x-scheme-handler/mailto=org.mozilla.Thunderbird.desktop;

    Glad that I got it working but still not satisfied that this was really the way to go, so I decided to start from scratch.

    I went back to KDE’s System Settings>Apps & Windows>Default Applications>Email client. Despite having Thunderbird already selected I went and selected Other… instead. Here I could select Thunderbird again but interestingly there were more options:

    You will notice in my screen-shot the check-box stating “Remember application association for all files of type “x-scheme-handler/mailto“. This check-box once checked actually updates the same ~/.config/mimeapps.list file with the previous entries I mentioned earlier.

    So apparently this is an option which is not enabled by default when just selecting Thunderbird in the default applications list. Why not having mailto links working by default in KDE is a conundrum.

    I am sure there are edge cases not wanting mailto links to open the default email client, but I would assume the vast majority of users expect this behaviour of the default email client. What is the point otherwise of selecting a default application?