I was a bit confused by the fact that a method named `build_system_menu()`
first enumerates a directory. Moving the app/category discovery to a dedicated
function that returns the GUI-relevant information makes this process a bit
less surprising.
As an added bonus, `g_app_category_menus` was actually only a temporary mapping,
and didn't need to be global. In theory, SystemMenu should use a handful fewer
of bytes now.
It doesn't make sense for a top-level menu to have an icon, however
we do not have dedicated classes to distinguish these.
Furthermore, the only other place to store an icon is MenuItem.
Storing it there would be highly confusing, as MenuItem-with-Action
then would have two icons: one in Action and one in MenuItem.
And because we need to be able to replace the icon during realization,
this would need to write-through to Action somehow.
That's why I went with Menu, not MenuItem.
This factors out icon realization into its own function, making it possible to
use the same code with other classes that have icon() and set_icon() methods.
Moves ProcessChooser and RunningProcessesModel to LibGUI and
generalizes their construction for use by other apps. Updates
Profiler to reflect the change and use its new icons.
We were accidentally calling memset() on "addr" (the input char*), not
"dst_addr" (the target struct sockaddr_in), which was causing a simple
"nc localhost 8000" to crash.
Fixes#2908.
"0" was interpreted as a base-8 prefix, and the parse pointer was then
unconditionally advanced, causing us to consume zero characters.
This unbreaks the git port. :^)
(We should really have tests for LibC..)
This being inline somehow broke the binutils autoconf scripts. It used
to work, so I suspect that some other change to LibC has caused those
autoconf scripts to go down a new path.
Regardless, this seems perfectly sensible.
I accidently wrote `Span<RemoveConst<T>>` when I meant
`Span<RemoveConst<T>::Type>`.
Changing that wouldn't be enough though, this constructor can only be
defined if T is not const, otherwise it would redefine the copy
constructor. This can be avoided by overloading the cast operator.
Use Core::guess_mime_type_based_on_filename() for this. It's obviously
not perfect, but it works better than just sending "text/html" for
everything no matter what. :^)
Note that these aren't full implementations of the bindings. This
mostly implements the low hanging fruit (namely, basic reflections)
There are some attributes that should be USVString instead of
DOMString. However, USVString is a slightly different definition
of DOMString, so it should suffice for now.
This virtual syscall works by exec'ing the UserspaceEmulator itself,
with the emulated program's provided arguments as the arguments to the
new UserspaceEmulator instance.
This means that we "follow" exec'ed programs and emulate them as well.
In the future we might want to make this an opt-in (or opt-out, idk)
behavior, but for now it's what we do.
This is really quite cool, I think! :^)
