helloSystem / helloSystem/hello

About running applications

Open
#160 4 comments 1 reaction 0 assignees View on GitHub
Dominant language
No language data
Stars
2.5k
Forks
59
PR merge metrics
No merged PRs in 30d

Description

The documentation describes in detail what an application stored on disk is. But little is said about what an application should look like in a running state. There are only guidelines for a window manager or a taskbar on how to determine which application corresponds to some window. In my opinion, parsing a cmdline is not the most reliable way. I ran into this problem when I was making my dock. There were many variations to take into account, there are different interpreters, they can have different parameters, etc. The cmd line can be like this: `launch python3 /Applications/Some.app/Some --arguments 123` or like this: `launch python3 many many python options /Applications/Some.app/Some --arguments 123`. Also, what if it's a wrapper and launching `launch python3 /Applications/Some.app/Some` will launch a completely different executable file that is located outside of `/Applications/Some.app/Some`? How to associate windows of another process with this application? GNOME used to have a whole daemon for mapping windows and `.desktop` files – `bamfdaemon`. I don’t know is it still here. Nowaday I use KDE and can't find this process.

Since all applications are launched via `launch`, we could somehow label the processes to associate them with the application. For example, set environment variables `APP_NAME=SomeApp` and `APP_BUNDLE=/path/to/SomeApp.app`. Then finding an app becomes much easier. Yes, there may be a problem here, if one application directly launches another one, then a new application will inherit the environment variables. But, if all applications will be launched only through `launch`, then there will be no such problem.

Another, more advanced option would be to create a special environment for a running application. For example, the application directory is mounted at `/run/user/1000/SomeApp.app` using `overlayfs`. Inside it are mounted directories necessary for the application to work, such as configuration and cache. At the same time, it would be nice to put things in order in the user's home directory so that heaps of files with periods at the beginning of the name do not lie there. I mean, not every application puts its config files in `.config`. Many apps just puts a config right in the home directory. This behavior is annoying. Also, in current system it is difficult to link a config directory and the application. it would be nice to be able to easily remove a config after the application is uninstalled. So, let's say the home directory will have subdirectories `/home/user/.config/SomeApp` and `/home/user/.cache/SomeApp`, which are mounted in `/run/user/1000/SomeApp.app/config` and `/ run/user/1000/SomeApp.app/cache`. Also this is necessary because the system allows user to have many versions of one application, also easy editing of applications by the user himself, easy various tests and experiments. For example, the user wants to try a new version of an application, but does not want it to change the settings of the old version. Then the user can launch the application like this: `launch --config=/new/config --cache=/another/cache /Applications/Some.app/Some --arguments 123`. So, launch will mount other directories inside /run/user/1000/SomeApp.app and the application will have a clean environment. It would be nice to add `--permanent` option for `launch`, then the path to the configuration and cache directories will need to be specified only once.

In addition to the above, the `/run/user/1000/SomeApp.app` directory could be the place, where the application connects to the IPC. For example, at `/run/user/1000/SomeApp.app/IPC`, the application opens a socket (or some other method of communication). Other applications that want to send messages write to `/run/user/1000/SomeApp.app/IPC`, and if they want to be notified of some event, they read from this file. I don't know what an IPC system can and should be in helloSystem (instead of DBus), but I think it would be nice if it maps to the filesystem. Then it can be easily explored and interacted with using standard command line utilities: `echo ‘new window’ > /run/user/1000/SomeApp.app/IPC`. I think one of the basic UNIX tenets, which says "everything is a file", has begun to be forgotten. Plan9 nowadays is more UNIX than any other UNIX-like.

By the way, it would be nice to create a rule for naming applications. For example, the reverse domain name format and a version number: `org.hellosystem.SomeApp-1.23.4.app`. And in the file manager, display only `SomeApp`. Anyway, what is displayed in the file manager may differ, since support for localized names is planned. Then it will be easier for the `launch` to distinguish between different applications and versions. It is possible to mount the application in `/run/user/1000/org.hellosystem.SomeApp-1.23.4.app/` and create a link `/run/user/1000/org.hellosystem.SomeApp.app`. Of course, a user will be able to rename the app directory if desired, everything will continue to work.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.