helloSystem
About running applications
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.
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 agree. Actually I was surprised that you cannot just ask Xorg which application (on disk) has created a window. Unless I am missing something, we need to figure out which which application (on disk) has created a window on our own, and the best way I could find so far is documented at https://hellosystem.github.io/docs/developer/application-bundles.html#getting-application-metadata-for-running-applications. If there are better/easier/more reliable ways, I am all for it, just let me know how this can be improved.
Thinking about it, the following might possibly work (maybe you want to give it a try):
- From Xorg, get the process ID
- For that process ID, find out the absolute path to the binary (for executable binaries) or the path to the script (for interpreted scripts) (is this hard?)
- From that absolute path on, go "upward" in the file system hierarchy until you encounter a directory ending in
.AppDiror.app - This is the application
whole daemon for mapping windows and
.desktopfiles –bamfdaemon
Luckily we are moving away from .desktop files – one convoluted thing less to worry about.
Since all applications are launched via
launch, we could somehow label the processes to associate them with the application
Interesting idea. Only question is, how do you "label" a process? You suggest setting an environment variable. What if the process launches sub-processes? Also, can we really be sure that all applications are launched by the launch process at all times? What if they are not? Maybe you'd like to fork the launch repository and experiment a bit with it.
Another, more advanced option would be to create a special environment for a running application.
Yes, this is something I had started looking into. But I've always seen this as optional for those applications that reqiure union mounts because they were compiled with absolute paths.
IPC
Again, interesting concept. I'd welcome experimentation in this area but I don't have enough knowledge in the area of IPC to do much myself regarding this. For now I just accept the fact that most applications are settled on D-Bus anyway.
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
The version information should be carried in a file inside the application bundle rather than in the filename. Possibly we can re-use the format that GNUstep is using, or Apple's Info.plist, or somehting simpler that we introduce. I am strongly against using the reverse domain name format in the filesystem because it makes things hard to use on the command line.
From that absolute path on, go "upward" in the file system hierarchy until you encounter a directory ending in .AppDir or .app
This is also an option. However, it will not work if the .app directory is just a wrapper for a system installed application. Or you need to establish a rule that all applications must be inside their .app directory and nothing outside.
What if the process launches sub-processes?
Yes, child processes will get this environment variable too. On the one hand, this is good, because some applications may spawn multiple processes. All windows of these processes will fall into one group. On the other hand, this is a problem because an application can start a process that is not related to the application itself.
In this case, and in the case of path parsing (and .app search), I see one solution: the rules for applications. In the first case (path parsing and search of .app dir), the rule will prohibit having executable files outside the .app directory. So, no wrappers. In the second case, the rule will oblige to launch applications only using the launch. And the launch will set the necessary environment variables.
Luckily we are moving away from .desktop files – one convoluted thing less to worry about.
Yes I know. That is the reason why I became interested in this system, it makes it possible to get rid of old and bad standards.
This is also an option. However, it will not work if the
.appdirectory is just a wrapper for a system installed application. Or you need to establish a rule that all applications must be inside their.appdirectory and nothing outside.
Right... so that's not a good option.
oblige to launch applications only using the
launchcommand
I don't think everyone will follow that, especially already-existing applications that are spawning child processes.
But possibly this has been solved already: git://anongit.kde.org/scratch/brauch/appimage-exec-wrapper is described as:
Whenever your application invokes a child process through execv() or execve(), this wrapper will intercept the call and see if the child process lies outside of the bundled appdir. If it does, the wrapper will attempt to undo any changes done to environment variables before launching the process, since you probably did not intend to launch it with e.g. the LD_LIBRARY_PATH you previously set for your application.
Would something like this help here?
As for separating config and cache, there are environment variables for that.
