A post was split to a new topic: Multimonitor support
Even if considering multiple GUI sessions, what should be done with Registrar? Currently Registrar do not allow to run more than one instance of single-launch application like Tracker or Deskbar. Should Registrar be adjusted to allow launch second instance if session is different or separate Registrar process should be running per each session. If second, how do discover Registrar port of current session? Currently connection to Registrar is established by global port name.
Having multiple GUI sessions may be also useful for testing purposes, because it allows to implement nested app_server that run in a window without libbe_test.so and separate test_app_server.
Yes, we’d have to solve all these issues. Probably it will have to be some sort of “hybrid” approach, given that launch_daemon has both a “root” process, and a “user” process, the same may need to be true of Registrar. And we can change the port discovery method to something else, as it’s private API.
Single-launch applications should obviously be per-user, there’s not much point to the flag otherwise, though.
Well, several system daemons probably use it too. What happens if an user tries to start their own media_server, for example? Or net_server?
Some of these we will want to duplicate per user, but some not. That is, if we allow multiple users logged in at the same time at all.
Maybe the “root” user should be global, and anything that’s run there would be “globally single launch”. While things run by an user would be more namespaced. Then, your users start to look more like FreeBSD jails and less like UNIX users.
Another question will be where to store session id? In environment variable? In kernel process info? In root Registrar team list? Session id is needed to decide on what desktop application should be displayed when started from Terminal.
Whatever started the Terminal (i.e. the user’s launch_daemon) should be the determining factor in that. An environment variable sounds OK to me; though maybe a “sessions API” makes some kind of sense…
I have an idea to introduce sessions in Registrar. Each session save own application list, clipboard etc. When session started, launch_daemon should start session tasks like Tracker and Deskbar. Registrar will store session id for each registered BApplication and be able to get session by team_id. New API will be introduced in BRoster for creating/destroying/enumerating sessions. Sessions are organized in a tree, user session can lookup root session applications by signature. app_server can be run in a window of another app_server in separate session without using libbe_test.
Terminal is a bit of problem because GUI process is started by bash that is non GUI process and it is not present in Registrar. Registrar will not know what session should be assigned.
But Terminal is itself a GUI app, so whatever session it belongs to should be what session Registrar assigns the app to, right?
Applications are started by bash, not Terminal. Terminal is just input-output system for command line programs. bash is not listed in Registrar. Session id in environment variables seems to be best solution for command line programs, Linux does similar thing.
But Terminal is a process, so registrar can determine by going up the process tree until it finds a GUI app with a session.
I guess if the media_server is per session… the that means they can plug in a USB DAC for a second seat and change to that in the media preflet and be good to go? Would a second media_server default to no output if there is only one device? Or if they were connected remotely audio could automatically be routed to the remote session… or perhaps not say for instance someone had a Headless TuneTracker system they would probably not want local audio disabled since that is driving thier station and potentially also not want it rerouted if they already have a solution for monitoring audio otherwise?
Session support is in early planning stage, media_server is not yet considered. Leaving media_server as-is in a root session is fine for now.
A bit of background on how Terminal is handled in UNIX and why we got there and why this distinction between login and non-login shells and all that: https://www.linusakesson.net/programming/tty/
Whatever we decide to do, we have to consider how to integrate it with the UNIX way, especially if we want remote desktop to work relatively transparently (something like ssh -X would be nice, where you can essentially just use another computer’s app_server for display)
1 Like
I think that X11 is a bad architecture, current remote app_server is much better because client is simple and more efficient implementation is possible. Running app_server client on different PC would be difficult to implement because app_server use shared memory. It will also be slow on connections with big latency.