This makes window modality a bit more discoverable by indicating to the
user that the modal window must be closed before mouse interaction is
possible in the clicked window.
When invalidating the frame we need to properly flag that so that
we trigger rendering the frame, even if "all" was flagged as being
invalidated. Otherwise it will only get rendered if anything else
happens to trigger it (such as focus change).
Fixes#3427
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
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.
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.
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.
Accessory windows are windows that, when activated, will activate
their parent and bring all other accessory windows of that parent
to the front of the window stack. Accessory windows can only be
active input windows. The accessory window's parent is always the
active window regardless of whether it is also the active input
window.
In order to route input correctly, input is now sent to the active
input window, which can be any accessory window or their parent,
or any regular window.
This allows marking a MenuItem as a default action, e.g. in a
context menu for an action that reflects what e.g. a double click
would perform.
Also enhance the window menu to mark the close action as the
default, and when double clicked perform that action.
Fixes#1289
IPC::ClientConnection now tracks the time since the last time we got
a message from the client and calls a virtual function on itself after
3 seconds: may_have_become_unresponsive().
Subclasses of ClientConnection can then react to this if they like.
We use this mechanism in WindowServer to send out a friendly Ping
message to the client. If he doesn't Pong within 1 second, we mark
the client as "unresponsive" and recompose all of his windows with
a darkened appearance and amended title until he Pongs us.
This is a little on the aggressive side and we should figure out a way
to wake up less often. Perhaps this could only be done to windows the
user is currently interacting with, for example.
Anyways, this is pretty cool! :^)
Instead, we now tell Windows to invalidate themselves. Window will then
pass on the requests to Compositor.
My basic idea here is that WindowManager should do window management,
dealing with incoming events, moving, resizing, etc. Compositor should
deal with painting the window stack in the right order with the least
amount of effort. :^)
It didn't feel right to have a "DHCPClient" in a "Servers" directory.
Rename this to Services to better reflect the type of programs we'll
be putting in there.
2020-05-08 21:57:44 +02:00
Renamed from Servers/WindowServer/WindowFrame.cpp (Browse further)
