I probably would've done INI config removal in another commit, but it
fit well here because I didn't want to pledge wpath for SystemMenu if I
didn't need to.
Frankly, that's something that I think should be done: allow ConfigFile
to be used read-only.
This patch adds the following convenience helper:
auto tab_widget = GUI::TabWidget::construct();
auto my_widget = tab_widget->add_tab<GUI::Widget>("My tab", ...);
The above is equivalent to:
auto tab_widget = GUI::TabWidget::construct();
auto my_widget = GUI::Widget::construct(...);
tab_widget->add_widget("My tab", my_widget);
Consider the old pattern for creating a Core::Object parent and child:
auto parent = Core::Object::construct(...);
auto child = Core::Object::construct(..., parent);
The above was an artifact of the pre-reference-counting Object era.
Now that objects have less esoteric lifetime management, we can replace
the old pattern with something more expressive:
auto parent = Core::Object::construct(...);
auto child = parent->add<Core::Object>(...);
This reads a lot more naturally, and it also means we can get rid of
all the parent pointer arguments to Core::Object subclass constructors.
This does not work with shell completion yet, but the basics of being
able a cd being able to expand "~" to the current user's home directory,
and "~foo" to the home directory of user "foo" is added in this commit
Work towards: #115
The Size column in the "File systems" tab of SystemMonitor
had a rendering artifact where the bounding box outline would
be drawn in the same location as the text. This makes the text
look strange and hard to read.
Pad the size with a signle space character on either side to
give the text a gap on each side.
Each allocation header was tracking its index into the chunk bitmap,
but that index can be computed from the allocation address anyway.
Removing this means that each allocation gets 4 more bytes of memory
and this avoids allocating an extra chunk in many cases. :^)
When committing to a new executable, disown any shared buffers that the
process was previously co-owning.
Otherwise accessing the same shared buffer ID from the new program
would cause the kernel to find a cached (and stale!) reference to the
previous program's VM region corresponding to that shared buffer,
leading to a Region* use-after-free.
Fixes#1270.
