This finally makes tooltips on menu applets the same as everywhere else!
Here's what went wrong:
WindowManager::process_mouse_event() receives a Window*&, determines the
hovered window and sets it accordingly. However there's a branch that
tests for menubar_rect().contains(event.position()) and returns early -
which resulted in hovered_window never being set to any MenuApplet
window, even hovered ones.
The hovered_window result is being used in WindowManager::event() and
passed to WindowManager::set_hovered_window(), which is responsible for
creating WindowLeft and WindowEntered events when the hovered window
changes, as a result of the mentioned chain of events this also never
happens for MenuApplet windows.
The WindowLeft event would the cause Window::handle_left_event() in
LibGUI to be called, which unsets the window's hovered widget, which
is necessary for the widget to receive a subsequent Enter event -
again, all of this never happened.
Now it's working as expected though, so we can start using tooltips on
menu applets :^)
This was using window()->position(), which is unset for windows with
WindowType::MenuApplet. Now it checks the window type and then uses
rect_in_menubar() for MenuApplet windows and rect() for everything else.
This makes tooltips show up for MenuApplet windows, previously they were
positioned off-screen :^)
Cuts time needed for `disasm /bin/id` from 2.5s to 1s -- identical
to the time it needs when not doing the random adjustment at all.
The downside is that it's now very easy to get the random offsets
with out-of-bounds reads, so it does make this mitigation less
effective.
If the space cannot be allocated, the original memory block shall remain
unchanged and the function should return nullptr.
Also add a function attribute and some null checks.
This change aims to add support for obscure IPv4 address notations, such as 1.1 (which should be equal to 1.0.0.1), or the hypothetical address 1 (which is equal to 0.0.0.1). This is supported on other platforms as well, such as Linux, Windows, *BSD, and even Haiku.
Previously the ColorPicker would get the custom color directly from the
window, this was changed in d7d5788469 to
get the color from the underlying bitmap instead - without taking the
bitmap's scaling into effect though, so resulting colors were off by
quite a bit.
Fixes#3113.
Subtracting 128 from the desktop rect's height was far to much and
and leading to weird rendering issues - now it's calculated exactly from
taskbar and menubar heights as well as a little additional offset to
make it fit perfectly.
Fixes#3115.
In the case of an ongoing window drag/move/resize action
WindowManager::process_mouse_event() would return early, even before
delivering mouse events to windows with global cursor tracking enabled.
They would only continue to receive new mouse events once those actions
were completed.
Fixes#3116.
This fixes an issue where transparent pixels in GIF animation frames
have their alpha values incorrectly set to zero, allowing the
background behind the GIF to show through, instead of the previous
animation frame.
Additionally, transparent pixels are now correctly identified based on
their index matching the image transparency index, instead of their
color values.
We should stop accessing the FileSystemModel outside DirectoryView.
This whole app is pretty badly factored, due to LibGUI being in its
infancy while it first developed.
This adds a new header <sys/internals.h>, which provides access to LibC internals.
This is in the interest of type-checking LibC itself, as well as enabling less-hacky
access for uses like LinkDemo.
And, of course, this progresses LibC towards building cleanly with -Wmissing-declarations.
I'm not sure how else to handle this. Curiously, I can't find the string '_start'
anywhere else in the project. Could it be that we haven't NIH'd this yet?
And that we actually rely on magic from the compiler to call _start for us?
This makes DynamicLink, and in fact all Demos, build cleanly with -Wmissing-declarations.
Note that this won't be necessary for 'normal' dynamic shared objects, as those
usually already declare their symbols in a header file.
With this, if a future module misses the 'extern "C"' or uses a wrong type,
they get a nice compiler error instead of runtime errors or weird behavior.
Also, this works towards getting the Kernel ready for -Wmissing-declarations.
This enables a nice warning in case a function becomes dead code.
For example with the unused function malloc_good_size() :^)
I found these places by using -Wmissing-declarations.
The Kernel still shows these issues, which I think are false-positives,
but don't want to touch:
- Libraries/LibC/crt0.cpp:41:5: int _start(int, char**, char**)
Not sure how to handle this.
- Libraries/LibC/cxxabi.cpp:48:5: int __cxa_atexit(AtExitFunction, void*, void*)
- Libraries/LibC/cxxabi.cpp:58:6: void __cxa_finalize(void*)
Not sure how to tell the compiler that the compiler is already using them.
- Libraries/LibC/libcinit.cpp:36:6: void __libc_init()
- Libraries/LibC/libcinit.cpp:55:19: void __stack_chk_fail()
- Libraries/LibC/malloc.cpp:430:6: void __malloc_init()
- Libraries/LibC/stdio.cpp:562:6: void __stdio_init()
These are ninja-imported by other LibC functions.
Maybe we should have some kind of "internals.h" header.
This enables a nice warning in case a function becomes dead code. Also, in the
case of {Event,Node}WrapperFactory.cpp, the corresponding header was forgotten.
This would cause an issue later when we enable -Wmissing-declarations.
Is my clang-format misconfigured? Why is the diff for NodeWrapperFactory.cpp
so large?
