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. :^)
Full-screen mode is pleasantly exclusive, so we only need to send the
incoming mouse events to the active full-screen window.
This fixes an issue where clicking on the area normally covered by
the menubar while in full-screen mode would not send mouse events to
the full-screen window.
Normally we walk the window stack to see if a given dirty rect is
covered by an opaque window. When the active window is full-screened,
we can skip this check and just unconditionally paint the window.
This fixes an issue where windows with higher inherent z-order (like
the taskbar and menu windows) would get cursor ghosting in them while
a normal window was full-screened.
Fixes#2289.
It's a little sad having two diferent versions of this function, but I
don't know of any better way to do it. This also gets rid of some const
casts down the line.
You can now mark String message parameters with the [UTF8] attribute.
This will cause the generated decoder to perform UTF-8 validation and
reject the message if the given parameter is not a valid UTF-8 string.
This frees up the receiving side from having to do this validation at
a higher level.
This commit moves the clipboard from WindowServer into a new Clipboard
service program. Clipboard runs as the unprivileged "clipboard" user
and with a much tighter pledge than WindowServer.
To keep things working as before, all GUI::Application users now make
a connection to Clipboard after making the connection to WindowServer.
It could be interesting to connect to Clipboard on demand, but right
now that would necessitate expanding every GUI app's pledge to include
"unix" and also unveiling the clipboard portal, which I prefer not to.
Perform a case insensitive search through the current menu. Jump to the
first item matching all keys in the current search. Backspace can clear
the current search, and the search will timeout after 3 seconds.
The menu manager will now send events directly to the current menu.
Previously if a menu was opened it would always be set as the current
menu. Now when opening a menu you can optionally say that you do not
want to have it as the current menu.
One scenerio when this happens is when a menu is popped up as part of a
preview, for example, when hovering over a menu item that is a submenu.
Sending the event to the current menu simplifies things and solves a few
inconsistencies in bevhaviour (such as hovering over a submenu, but key
events not being sent to the submenu).
When the user opens a context menu by right-clicking on something,
we now immediately stop sending mouse events to whoever was doing
active input window tracking before.
There are probably more situations where we should do this, and maybe
there's also a more generic way to express it, but this works for now.
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.
