Openrct2: Suggestions for a better Linux portable version

[legluondunet]

Hello,
I downloaded OpenRCT2 last dev version from here:
https://openrct2.org/downloads/develop/latest
OpenRCT2-0.2.3-develop-2d443b591-linux-x86_64.tar.gz
and when I launch it, as you can see on the screen capture above, there is no icon in my Gnome panel:

[AaronVanGeffen]

Whether an icon appears depends on whether you've actually installed the game, or just launching it from a non-standard folder.

Which distribution are you using, and which version (for what platform) did you download?

[legluondunet]

distribution: Ubuntu 19.10 64 bits
I downloaded from here:
https://openrct2.org/downloads/develop/latest
extracted the archive and launched it directly.
Where are the binary searching for an icon?

[IntelOrca]

If the icon comes from a .desktop file then you will not get that with the portable download.

[legluondunet]

So when an user launch a portable version, he has no icon in gnome panel, it is an issue.
It could be resolved by ask OpenRCT2 to search for an icon (png, svg) in his main folder? or in the OpenRCT2 icons folder?

[IntelOrca]

I don't know that much about how icons work with Linux desktop managers. I think it is up to the manager to supply the icon usually, hence how icon themes can change common app icons. We want to move to AppImage for the portable apps and that might be even harder to get the icon to show.

If there is a way of getting the icon to show then we will gladly look into doing it.

[AaronVanGeffen]

We supply a .desktop file and related icons in our Ubuntu/Debian release builds at least. Not sure how it would work, but we should be able to supply them in our develop builds, too.

[legluondunet]

During Linux OpenCRT2 compilation, are icons compiled inside the executable, libopencrt2.a library, G2.DAT or another OpenCRT2 file?

[AaronVanGeffen]

None of those. When installed through e.g. a Debian package, the PNG icon files end up in /usr/share/icons or some such location.

[legluondunet]

We supply a .desktop file and related icons in our Ubuntu/Debian release builds at least. Not sure how it would work, but we should be able to supply them in our develop builds, too.

This will not resolve this issue as Linux DE does no more permit to launch .desktop files out of official folders for security reasons.
I have a suggestion:
at launch on Linux platform, OpenRCT2 verify that there is his svg icon in this folder:
~/.local/share/icons
if not, it copies it from his main folder.
That means that openrct.svg file should be present in the main folder.

I just tested, when I copy openrct.svg to ~/.local/share/icons, it appears correctly in taskbar.

[legluondunet]

I opened this issue because I wrote an installer for Lutris that use your OpenRCT2 64 bits portable version. But I encounter some difficulties to use it because your Linux portable version is not fully "portable":

• can not launch on different Linux distributions, it always missed dependencies. Why your Linux portable version is not compiled statically?
• no icon in DE, I tested on Gnome, XFCE and Budgie.
• config files stored in user .config folder instead current executable path, necessary to be fully portable.

I finished my Lutris installer yesterday and I finally found solutions for this three issues. I share my experience:
1° resolve dependencies)
I launched OpenRCT2 on different and most used Linux distributions (Ubuntu 18.04, Manjaro 18.1, Fedora 30, Solus 4.4, Debian 10) and each time it missed dependencies, I added them all in "libs" folder one after one. All the dependencies files comes from Ubuntu 18.04 64 bits. Then I use LD_LIBRARY_PATH variable to use local libs folder when I launch OpenRCT2:
LD_LIBRARY_PATH=libs ./openrct2
I tried to compile a OpenRCT2 static build but I obtained errors compilation, perhaps because of this issue: https://github.com/OpenRCT2/OpenRCT2/issues/9592 that not affect only ARCH distribution.

2° integrate OpenRCT2 portable version with DE)
On Linux to integrate an executable with the DE (have an icon in taskbar or alt/tab is sexier isn't it?). Following the Freedesktop rules, DE search for an icon in this folders:
/usr/share/icons/executable_name
~/.local/share/icons/
As we want to use a portable version without root rights needed, we could use ~/.local/share/icons/.
Last thing, DE need a .desktop file too or no icon will be shown for OpenRCT2 executable. It should be store here:
~/.local/share/applications

3° config files)
For a portable version, config files should not be store in the user home but in current OpenRCT2 folder. For this I use the useful OpenRCT2 command line option:
--user-data-path=config

Finally I wrote a basic bash script to launch OpenRCT2 portable 64 bits and integrate it with DE in userspace.

#!/bin/bash

cp -R icons ~/.local/share/

openrct2path="$PWD"
echo "le répertoire courant est $openrct2path"
sed -i -e "s_Path=.*_Path="$openrct2path/"_g" -e "s_Exec=.*_Exec="$openrct2path"/OpenRCT2.sh_g" openrct2.desktop
cp openrct2.desktop ~/.local/share/applications/

LD_LIBRARY_PATH=libs ./openrct2 --rct2-data-path="../RCT2" --rct1-data-path="../../rollercoaster-tycoon-deluxe/drive_c/GOG Games/RollerCoaster Tycoon Deluxe" --user-data-path=config

So each time this script launch, it copies icons and .desktop launcher in user folder to obtain icon in DE.
The script rewrites .desktop file at each launch with current OpenRCT folder location in case user move the portable folder in another place.

I joined you the archives I use for my installer.
OpenRCT2_x64_portable_addons_files.zip

[legluondunet]

@IntelOrca said:

If there is a way of getting the icon to show then we will gladly look into doing it.

I think I now gave you a lot of elements to look into doing it ;)

[TheAssassin]

We want to move to AppImage for the portable apps and that might be even harder to get the icon to show.

How so? It even makes this a little easier.

A little background from my experiences with these kinds of icon issues on many, many desktops. There's two icons that play a role here, the window icon and the icon you choose in your .desktop file. Some desktops show the window icon in the task manager as well (IIRC that applies to XFCE for instance), some require a desktop file as launcher with a valid icon which will then be shown in the task bar for all related windows.

In an AppImage, it's easier to get both right. Let's first have a look at the window icon. A window icon is always defined by your UI toolkit. It forwards it to the desktop. Therefore during runtime you need to load that icon from somewhere. Some people compile them in, most people load them from files.

To load an icon from a file in a portable (read: relocatable) installation (such as an AppImage or tarball) you need to resolve the path from the current location of your application install tree. Most people hardcode some paths prefixed with /usr or /usr/local, basically breaking relocatability, because they're used to static paths like they're available to distro provided installations. However, there's better ways to resolve paths to resources than hardcoding them with some prefixes.
The typical approach is to resolve your paths relative to the main binary. Normally, your install tree is a set of directories that is installed in a so-called install prefix (classic autotools and also CMake approach). Knowing that information during compile time, you can compile it in your binary and don't need any fancy resolving.
In a portable installation, you still have your install tree with files distributed across a set of directories in one parent directory, however the location of the parent directory may change. Resolving paths now becomes a little more difficult, but not too hard. All you need is the location of the common "path prefix". You can do so by resolving the path of your main binary, then calculating the parent directory path. In a typical setup, this gives you the location of the common prefix, and you just have to append the paths to your resources. Think: bin/../share/myapp/icons/....

Tarballs never really ship with a desktop file that people shall double click to run a game. Mostly that's because desktop files are bad at relative paths. There's scripts to double click or people just use the commandline directly.
An AppImage on the other hand requires a desktop file, and there's some good integration infrastructure to integrate them into your desktop nicely. So, using an AppImage will help get the desktop file icon right, and will make desktops like GNOME 3 happy which use those icons.

Hope that helps. Still looking forward to playing the first official OpenRCT2 AppImage!

Edit: just saw there's an official AppImage already for 0.2.4! Yay! Going to test tonight.

[IntelOrca]

Edit: just saw there's an official AppImage already for 0.2.4! Yay! Going to test tonight.

Unfortunately we are unable to post it to the AppImage hub as a pre-req of Ubuntu 17 or later is not allowed.

Is it possible to make the single AppImage file that is downloaded have an icon?

[TheAssassin]

I'm not entirely sure what you mean. Do you mean when the AppImage is downloaded, it should have a thumbnail in the file manager?

[IntelOrca]

Yeah, like how EXEs have an icon on Windows.

[TheAssassin]

There are thumbnailers available. Integration tools like AppImageLauncher already set up the classic thumbnails as specified in the icon theme standard, only some desktops (KDE) don't use that standard. However, KDE built their own thumbnailer that should be enabled by default in the future somewhen soon.
I think there were plans to include our own thumbnailing code (it's rather small) into the AppImage runtime. I don't recall the exact location. Mind to open an issue at AppImageKit about it?

[IntelOrca]

What do we need to do to enable our icon for the app image so that it displays in any supported app image client?

[TheAssassin]

Unfortunately we are unable to post it to the AppImage hub as a pre-req of Ubuntu 17 or later is not allowed.

I know, I disagree with that rule... IMO any AppImage is a good AppImage, as long as it can reach a larger audience. I wouldn't permit stuff built on e.g., Arch, but any Ubuntu LTS release has a large user base. Sure, the older, the better, but if your AppImage runs on Ubuntu 18.04 it'll reach maybe 30-40% of all users already...

Anyway, you need to install AppImageLauncher (or some other libappimage based integrator) to benefit from the thumbnails. I run XFCE with AppImageLauncher, and this is a screenshot from my applications directory:

Your icons are set up correctly in the AppImage, you can use appimagelint to check that, thumbnails are generated correctly.

Perhaps you should add a little note that users might want to install AppImageLauncher as well?

[TheAssassin]

We have an AppImage now that works great (just tested it). I guess we can close this issue.