This is an application of the xdg activation protocol that will allow
compositors to associate new foot toplevels with the command that
launched them.
footclient receives an activation token from the launcher which the
compositor can use to track application startup. It passes the token
to the foot server, which then activates the new window with the token
to complete the startup sequence.
... unless we’re re-using the main conf as-is, in which case we will
already have done this (and the conf’s user-notification list will
already contain a warning).
Send a generic “overrides” list to the server, containing options in
text, on the format “section.key=value”.
This reduces the size of the base client/server protocol packet, as
well as opens up for a generic -o,--override command line option (not
yet implemented).
When the connecting client overrides config options, clone the
server’s configuration, and then convert the overridden options to
config overrides, and apply them using config_override_apply().
When destroying the client, free the cloned config using the regular
config_free().
* foot exits with -26/230
* footclient exits with -36/220
This is to give each application a range of exit codes. Currently
unused, but we may want to change this in the future.
Normally, foot and footclient uses the exit code from the client
application (i.e. the shell).
However, foot (or footclient) itself may fail to run; if run outside
of a Wayland session, or no fonts are installed, or the client
application/shell cannot be found (“foot lsdjfldsjf”) etc.
Up until now, there has been no way to differentiate these kind of
failures from the client application exiting with code 1.
This patch changes foot’s failure exit code to -27/229, and
footclient’s to -28/228. Note that footclient will exit with foot’s
-27/229 if footclient ran successfully, but the foot server failed to
instantiate a new window.
Closes#466.
Instead of writing (and logging errors for) every parameter, one at a
time, send all fixed size data in a single struct, followed by all the
variable length data.
All are printf() formatter related. Even if a variable is e.g. a
'short', when used in an expression like '<variable> - 1' it is
promoted to an 'int'.
Closes#16
We now create a copy of the config for each client, and updates it
with the values passed from the client.
Since we're not actually cloning it (and e.g. strdup() all strings
etc) we can't call conf_destroy() to free it, but need to free just
the strings we've replaced.
Make both the server listening socket and the connecting client
sockets non-blocking.
Then, when reading the initial length of the setup packet, handle read
errors from partial reads separately.
Assume the client writes all four bytes of the 'length' field at once,
and bail out if we are unable to read those 4 bytes.
Limit the maximum setup packet size to 128K. This is to prevent
clients from pretending the setup packet is insanely large, causing us
to fail to malloc.
This is used when spawning the slave, to set its current working
directory just before we exec() the client.
In a regular foot instance, we set the cwd from getcwd().
In a foot server instance, each connecting client sends its cwd to the
server, and we use that.
* Client terminal initialization data is now received
asynchronously. To facilitate this, a couple of minor changes to the
protocol was made:
- The client now starts with sending a 4-byte unsigned integer
with the *total* size of the initialization data (*not*
including the size field itself.
- Strings (TERM variable + argv) are now sent NULL-terminated
* The server allocates a single buffer, and fills it
asynchronously. When full (as indicated by the initial 'total size'
integer), we parse it (taking care not to read outside boundaries
etc, and verifies the lengths (of the TERM variable and argv array)
indicated by the client matches the actual lengths of the strings
received.
* The server now ignores 'unexpected' data received from the client,
after the terminal has been instantiated.
