Various applications were using the same slightly verbose code to center
themselves on the screen/desktop:
Gfx::IntRect window_rect { 0, 0, width, height };
window_rect.center_within(GUI::Desktop::the().rect());
window->set_rect(window_rect);
Which now becomes:
window->resize(width, height);
window->center_on_screen();
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 :^)
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.
When maximizing a window that is blocked by a modal window, only
maximize the top window in the stack. However, if the stack is
minimized, restore all of them in addition.
Fixes#3074
This patch introduces the ClassicWindowTheme, which is our default
theme implemented as a Gfx::WindowTheme subclass.
In this initial cut, we move normal window frame painting and title
bar metrics helpers out of WindowServer and into LibGfx.
This will eventually allow us much greater flexibility with theming
windows, and also makes it easier to build applications that want to
render a window with a specific style for some reason. :^)
When clicking on a window's frame that is blocked by a modal
window, we want to bring the entire window stack to the front
regardless of where the user clicked in the frame (not just the
icon).
Change #2811 made window title stripes and window title shadow themable,
but it used the same stripe and shadow color for all window modes.
This is fine for the new 'basalt' theme which uses the same color
in all four window modes, but it changed the default theme so that
background windows had brown stripes and a brown shadow.
Instead, make the title stripe and title shadow themable per window mode,
and change the default theme to restore the colors it had before
change #2811: The title stripe color is the same as Border1 for all
window modes, and the title shadow is the same as the title stripe
darkened by 0.6.
This prevents windows from being opened directly on top of eachother,
and provides default behavior for when window position is not specified.
The new behavior is as follows:
- Windows that have been created without a set position are assigned one
by WindowServer.
- The assigned position is either offset from the last window that is
still in an assigned position, or a default position if no such window
is available.
Custom buttons can now be set using TitleButtonIcons under the
Paths group in themes. WindowFrame recognizes window-close.png,
window-minimize.png, window-maximize.png and window-restore.png
filenames.
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.
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. :^)
With this, System Monitor has "System Monitor" instead of
"SystemMonitor" as tooltip, matching the app's title bar
and menu bar title.
Same for File Manager and Text Editor.
If we add "(Not responding)" to the title of an unresponsive window,
the title rect needs to be wider or we'll have text-on-stripes.
Thanks to @SharpOB for reporting this bug!
The theming system can now control title bar height, title button
size, title stripe color and the title text shadow color.
The implemented theme metrics system could be later extended to LibGUI
to allow themes to change widget padding, border width, etc.
When walking the modal window stack upwards, we need to check if
the top modal window is still a descendant of the window that
the parent is blocked by. Fixes not all windows being brought to
the front when trying to active a parent in the middle of the
modal window stack.
* The parent information is necessary by the Taskbar to be able to
determine a modal window's parent
* Minimize and maximize modal window stacks together
