This is an upscaled (no interpolation) version of the 16x16 icon, which
looks pretty neat given the pixelated appearance of the "Fire" demo
application. :^)
This adds the ability to specify cursor attributes as part of their
file names, which allows us to remove hard coded values like the hot
spot from the code. The attributes can be specified between the last
two dots of the file name. Each attribute begins with a character,
followed by one or more digits that specify a uint value.
Supported attributes:
x: The x-coordinate of the cursor hotspot
y: The y-coordinate of the cursor hotspot
f: The number of animated frames horizontally in the image
t: The number of milliseconds per frame
For example, the filename wait.f14t100.png specifies that the image
contains 14 frames that should be cycled through at a rate of 100ms.
The hotspot is not specified, so it defaults to the center.
Instead of symlinks showing up with the "filetype-symlink" icon, we now
generate a new icon by taking the target file's icon and slapping a
small arrow emblem on top of it.
This looks rather nice. :^)
HackStudio no longer has dedicated project files, so let's get rid of
the *.hsp file concept. It'll eventually produce some files again,
but they won't be the same kind of "project" files.
This is definitely not fully-featured, but basically we now handle
the clear property by forcing the cleared box below the bottom-most
floated box on the relevant side.
This is a new "browse" permission that lets you open (and subsequently list
contents of) directories underneath the path, but not regular files or any other
types of files.
This moves file extension to icon mappings from compile time macros to an
INI config file (/etc/FileIconProvider.ini), so file icons can easily be
customized and extended :^)
I also switched the format from a static file extension (".foo") to
glob-like patterns ("*.foo", using StringUtils::matches()), which allows
us to assign icons to specific exactly matching file names, like many
IDEs do - e.g. "CMakeLists.txt" or ".prettierrc".
It's a thin userland wrapper around adjtime(2). It can be used
to view current pending time adjustments, and root can use it to
smoothly adjust the system time.
As far as I can tell, other systems don't have a userland utility
for this, but it seems useful. Useful enough that I'm adding it to
the lagom build so I can use it on my linux box too :)
Most systems (Linux, OpenBSD) adjust 0.5 ms per second, or 0.5 us per
1 ms tick. That is, the clock is sped up or slowed down by at most
0.05%. This means adjusting the clock by 1 s takes 2000 s, and the
clock an be adjusted by at most 1.8 s per hour.
FreeBSD adjusts 5 ms per second if the remaining time adjustment is
>= 1 s (0.5%) , else it adjusts by 0.5 ms as well. This allows adjusting
by (almost) 18 s per hour.
Since Serenity OS can lose more than 22 s per hour (#3429), this
picks an adjustment rate up to 1% for now. This allows us to
adjust up to 36s per hour, which should be sufficient to adjust
the clock fast enough to keep up with how much time the clock
currently loses. Once we have a fancier NTP implementation that can
adjust tick rate in addition to offset, we can think about reducing
this.
adjtime is a bit old-school and most current POSIX-y OSs instead
implement adjtimex/ntp_adjtime, but a) we have to start somewhere
b) ntp_adjtime() is a fairly gnarly API. OpenBSD's adjfreq looks
like it might provide similar functionality with a nicer API. But
before worrying about all this, it's probably a good idea to get
to a place where the kernel APIs are (barely) good enough so that
we can write an ntp service, and once we have that we should write
a way to automatically evaluate how well it keeps the time adjusted,
and only then should we add improvements ot the adjustment mechanism.
Now the functions can actually be demonstrated by small examples,
embedded right inside the documentation via:
spreadsheet://example/<page>#<example_name>
Also allows pages to link to each other via the same scheme:
spreadsheet://doc/<page>
