Launch instances directly from right-click menu of icon

[pixlxip]

The Problem

This isn't a problem, it's just a minor inconvenience. This is possible to do (in Linux, at least) by copying and modifying the desktop file, but I am left with two app icons and I would need to manually edit the file after each added, renamed, or deleted instance is created. I made a script to do it for me (linked below), but it would still need to be run every time I change my instances. It would be nice if this were included as a feature, or even optionally, because some package managers might now like it. I'm not sure how this could be handled on Windows and MacOS, but I'm sure this could be done on both, because they are used in Chrome.
Having this feature for servers would also be useful, to quickly launch them.

The Solution

Every time the list of instances or servers changes, regenerate the right-click options for the app icon. Use the name of the instance/server as the name of the option. Possibly add the option to whitelist or blacklist instances and servers, because these are meant for convenience (maybe a checkbox in Edit Instance ⏷ or in the Settings menu?). In Windows (only Windows, because Linux and MacOS don't support it as far as I know), you may want to experiment with using the instance image as an icon, but I personally don't think that it would look very good at that scale.

Additional Information

This is the Python script I used to add the options to the right-click menu of a new ATLauncher icon (it doesn't work perfectly):

import os, json
dirs = os.listdir("/home/pixl_xip/.local/share/atlauncher/instances")
actions_list = "Actions="
actions = ""

def parseName (path):
	with open(path, "r") as f:
		return json.load(f)["launcher"]["name"]
for d in dirs:
	actions_list += f"{d};"
	name = parseName(f"/home/pixl_xip/.local/share/atlauncher/instances/{d}/instance.json")
	actions += f"\n\n[Desktop Action {d}]\nName={name}\nExec=atlauncher --launch=\"{name}\" --close-launcher"

print(f"[Desktop Entry]\nName=ATLauncher Options\nGenericName=ATLauncher\nComment=A launcher for Minecraft which integrates multiple different modpacks to allow you to download and install modpacks easily and quickly.\nExec=atlauncher\nIcon=atlauncher\nTerminal=false\nType=Application\nCategories=Game;\nKeywords=game;Minecraft;\n{actions_list}Refresh;{actions}\n\n[Desktop Action Refresh]\nName=Refresh\nExec=~/Coding/atlrefresh")

Have you checked this issue doesn't already exist?

• I am sure this issue doesn't exist already

Code of Conduct

• I agree to follow this project's Code of Conduct

[pixlxip]

I also had a file called atlrefresh: (the file from before was called atlauncher.py)

#!/bin/bash

if test -e "~/.local/share/applications/atlauncher_options.desktop"; then
    rm ~/.local/share/applications/atlauncher_options.desktop
fi
python ~/Coding/atlauncher.py >> ~/.local/share/applications/atlauncher_options.desktop

[RyanTheAllmighty]

So I imagine we could do this fine for everything except flatpak installs.

My only question would be if there was any effect on AUR when the desktop file is updated outside of AUR. At minimum it'd need to be redone after an update.

As for other OS, for Windows can look at integrating into the start menu like chrome does:

As well as what is done for the docked icon right click:

My first guess is that this is likely not going to be simple to do, at least for Windows, but worth taking a look

Worth noting there is also #664 which will create shortcuts to specific instances

Also @pixlxip you don't need to parse the json for each instance, you can just use the instances folder name to launch the instance, should save you a step in your script, but I guess if you want the proper full name you still do, so nvm :)

[Doomsdayrs]

I will consult some documentation, but from my knowledge.

You should not be recreating the desktop file. That is supposed to be consistent and read only.

I recall there are platform APIs for these actions, which requires #709

[pixlxip]

I have been just making a new desktop file in ~/.local/share/applications
Therefore, I'd have two icons, one managed by AUR, one managed by me and user-only.

[pixlxip]

So I imagine we could do this fine for everything except flatpak installs.

Why wouldn't it work for Flatpak installs? Permissions?

[Doomsdayrs]

I have been just making a new desktop file in ~/.local/share/applications Therefore, I'd have two icons, one managed by AUR, one managed by me and user-only.

So I imagine we could do this fine for everything except flatpak installs.

Why wouldn't it work for Flatpak installs? Permissions?

Essentially the desktop file is not meant to be "dynamic", it is expected to be static and read-only. Allowing an app to rewrite its desktop file is just asking for malicious programs to pretend to be something else.

Giving an arbitrary permission to the uses .local folder would be breaking sandbox as well. I can break sandbox, but after fracturizer I will not give any write permissions to an application that runs arbitrary downloaded code along with the previous reason.

#664 is a better solution for Linux & MacOS in regards to desktop files. While #709 can help, we can also update the current indicator with this functionality (only works with ATLauncher already open).

[Doomsdayrs]

For Windows only. This is very much possible. But I am not the Windows developer, @RyanTheAllmighty is ahah.

[pixlxip]

Essentially the desktop file is not meant to be "dynamic", it is expected to be static and read-only. Allowing an app to rewrite its desktop file is just asking for malicious programs to pretend to be something else.

Is there any way of sourcing parts of the desktop file from somewhere else? This wouldn't break the sandbox if the file sourcing the desktop file was in the ATLauncher Flatpak directory and you wouldn't have to deal with the desktop file being overwritten by a package manager. I'll look into it and see if it's possible, and document my findings, and how you could go about it.

As for #664, I feel this isn't a perfect solution for this problem, because some people (like me) prefer to not have icons on their desktop, but I feel it should still be a feature nevertheless.

[Doomsdayrs]

Is there any way of sourcing parts of the desktop file from somewhere else? This wouldn't break the sandbox if the file sourcing the desktop file was in the ATLauncher Flatpak directory and you wouldn't have to deal with the desktop file being overwritten by a package manager. I'll look into it and see if it's possible, and document my findings, and how you could go about it.

I am unsure what you mean by this. The flatpak bundles a desktop file that is set on install.

Desktop files are specification files, not scripts that (as far as I am aware) can include other desktop files. This is evident by how firefoxes desktop file is cluttered with every translation in it.

As for #664, I feel this isn't a perfect solution for this problem, because some people (like me) prefer to not have icons on their desktop, but I feel it should still be a feature nevertheless.

While originally used for the desktop, desktop files now a days are used for application menus in general. #664 for Linux would not write to the ~/Desktop/ folder but interface with the xdg API to let the DE handle creation of new application menu entries (.desktop files)

[pixlxip]

Sorry, I didn't understand it in that way. That would work, but as a suggestion, could you add alternate options in the right click menu like offline mode or even something to just bring up the add mods and edit mods options? It would be useful to not have to open the launcher.