We need to update all button rectangles when the layout changed.
We also need to clear the taskbar button rectangle when we
remove a modal window button, so that WindowServer uses the
parent's taskbar button rectangle for the minimize animation.
If a modal window is being minimized, it may not have its own
taskbar rectangle. In that case, try finding a parent in the
modal window stack that does have one, and use that for the
animation.
Rather than blitting and rendering each window every time, only
render what actually changed. And while doing so, only render
the portions that are visible on the screen. This avoids flickering
because flipping framebuffers isn't always perfectly in sync with
the code, so it's possible that the flip happens slightly delayed
and we can briefly see the next iteration having partially completed.
Also, avoid touching the mouse cursor unless it is in an area that
needs updating. This reduces flickering unless it is over an area
that is updated often. And because we no longer render the entire
screen, we'll save the contents below the cursor so that we can
hide it before touching that area.
Fixes#2981
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. :^)
