The user can now save, load, and view calendars. A calendar is made up
of an array of events which are saved in a JSON file. In the future we
should implement the iCalendar standard instead of using a custom
format.
This allows it to read/write to the user's clipboard properly. Prior to
this, it would be writing to the Clipboard server running under the
window user, which doesn't impact other users (like anon).
Co-authored-by: Daniel Bertalan <dani@danielbertalan.dev>
This program has never lived up to its original idea, and has been
broken for years (property editing, etc). It's also unmaintained and
off-by-default since forever.
At this point, Inspector is more of a maintenance burden than a feature,
so this commit removes it from the system, along with the mechanism in
Core::EventLoop that enables it.
If we decide we want the feature again in the future, it can be
reimplemented better. :^)
This filesystem is based on the code of the long-lived TmpFS. It differs
from that filesystem in one keypoint - its root inode doesn't have a
sticky bit on it.
Therefore, we mount it on /dev, to ensure only root can modify files on
that directory. In addition to that, /tmp is mounted directly in the
SystemServer main (start) code, so it's no longer specified in the fstab
file. We ensure that /tmp has a sticky bit and has the value 0777 for
root directory permissions, which is certainly a special case when using
RAM-backed (and in general other) filesystems.
Because of these 2 changes, it's no longer needed to maintain the TmpFS
filesystem, hence it's removed (renamed to RAMFS), because the RAMFS
represents the purpose of this filesystem in a much better way - it
relies on being backed by RAM "storage", and therefore it's easy to
conclude it's temporary and volatile, so its content is gone on either
system shutdown or unmounting of the filesystem.
The clipboard service hasn't been ported to user-based portals with
others services as it is needed at `GUI::Application` creation and thus
before the first login, as the `LoginServer` needs one.
This problem as been solved thanks to session-based portals, a clipboard
portal is now created at boot for the "login" session and another for
each "user" session.
With a user-based portal, the "login" portal would have needed to be
created for the `root` user, exposing us to security issues. It now, can
be owned by the `window` user.
Various changes are needed to support this:
- The directory is created by Core::Account on login (and located in
/tmp).
- Service's sockets are now deleted on exit (to allow re-creation)
- SystemServer needs to handle SIGTERM to correctly destroy services.
This service is responsible for loading network configuration from a
/etc/Network.ini config file. It sets up static IP address + mask or
starts DHCPClient depending on configuration.
This will allow using the console tty and WindowServer regardless of
your kernel command line. Also this fixes a bug where, when booting in
text mode, the console was in graphical mode, and would not accept
input.
This will allow us to change between a couple of properties, for now
it's only Device and Virtual. (How about Remote :^) ) These get handled
by a different screen backend in the Screen.
Previously the CI would hang on the "Check manpages for completeness"
step on any utility that unveils the /tmp/portal/lookup file because
it was not created during the generate-manpages SystemMode.
This will allow utilities that resolve hostnames (e.g. netstat, arp) to
pass the export-argsparser-mangpages.sh check.
