Previously we would return a 0xdeadc0de frame for every kernel frame
in the real kernel stack when an non super-user issued the request.
This isn't useful, and just produces visual clutter in tools which
attempt to symbolize stacks.
This ignores unhandled mouse clicks for the window buttons. Right now
right-clicking on the window buttons animates them as if some action
were to occur when the mouse button is released.
Recent changes in the button painting code made this unnecessary. For
the case of value() == max(), the scrubber button would overlap the
increment button.
Fixes#6838.
Add a Discord badge to the top of the README.md file. It will show
the number of online users in the Discord server. If clicked it will
redirect you to the invite page.
Most of the IPC that happens between clients and WindowServer when
creating and configuring windows can be asynchronous. This further
reduces the amount of ping-ponging played during application startup.
Creating a menu/menubar needs to be synchronous because we need the
ID from the response, but adding stuff *to* menus (and adding menus
to menubars, and menubars to windows) can all be asynchronous.
This dramatically reduces the amount of IPC ping-pong played by
each GUI application during startup.
I measured how long it takes TextEditor to enter the main event loop
and it's over 10% faster here. (Down from ~86ms to ~74ms)
This changes client methods so that they return the IPC response's
return value directly - instead of the response struct - for IPC
methods which only have a single return value.
This enables support for automatically generating client methods.
With this added the user gets code completion support for all
IPC methods which are available on a connection object.
When attempting to fix the dirent code I also changed
this to use strlcpy instead of the custom string copy
loop that was there before. Looking over strlcpy it
looked like it should work when using a non null terminated
string, I obviously misinterpreted the implementation
as it will read till it finds a null terminator.
Manually null terminate the string to address this.
Gunnar found this after he fixed UserspaceEmulator.
I reproduced it locally using his branch, and also
found the memory leak I had in the unit test for the
scandir that I added, so lets fix that as well.
Reported-by: Gunnar Beutner <gbeutner@serenityos.org>
This patches fixes a crash of the Userland/TextEditor where it would
crash when deleting a range spanning two lines. This was because the
TextEditor would delete the range and modify the cursor position
before clearing the selection. This would trigger a status bar update
with the invalid selection.
math.cpp: In function 'int64_t __moddi3(int64_t, int64_t)':
math.cpp:168:13: error: 'r' may be used uninitialized
[-Werror=maybe-uninitialized]
168 | return ((int64_t)r ^ s) - s; // negate if s == -1
| ^~~~~~~~~~
Adding -fno-semantic-interposition to the GCC command
line caused this new warning.
I don't see how output.data() could be uninitialized here. Also,
commenting out the ensure_capacity() call for the Vector
also gets rid of this warning.
Ordinarily this would force the compiler to not inline certain
symbols and call them via the PLT instead. To counteract this
I've also added -fno-semantic-interposition which disables
ELF symbol interposition. Our dynamic loader doesn't support
this anyway and we might even consider not implementing this
at all.
Even though this is a toolchain change this doesn't require
rebuilding the toolchain unless you're planning to build
for the x86_64 arch.
This commit adds a draw_physical_line method, which is the exact same
as draw_line, except it's parameters are already transformed and
scaled. This is used by both draw_line and draw_rect, as a slight
optimization to save some work. It also fixed draw_rect not checking
whether it should draw the lines before drawing them.
If the user tries to exit HackStudio, or build the project, when there
are unsaved changes in some of the editors, A Yes/No/Cancel dialog will
be shown.
It had the following FIXME:
// FIXME: This doesn't seem compatible with multiple split editors
In practice this member was used to get the filename of the currently
active edtior. So we now get it directly from the currently active
EditorWrapper.
