I saw this assertion fire once and I don't know how I made it happen,
but it seems fine for client-less windows to become active, they just
don't have a menubar to install.
fixes#2575
The extra ResizeEvent would be handled after on_rect_change, and would
reset the size of main_widget to what it was before the resize.
Bonus: Less unnecessary events.
Instead of always running the responsiveness timer for IPC clients,
we now only start it after sending a message. This avoids waking up
otherwise idle clients to do ping/pong busywork.
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! :^)
Each window now has an associated progress integer that can be updated
via the SetWindowProgress IPC call.
This can be used by clients to indicate the progress of ongoing tasks.
Any number in the range 0 through 100 indicate a progress percentage.
Any other number means "no progress"
And move canonicalized_path() to a static method on LexicalPath.
This is to make it clear that FileSystemPath/canonicalized_path() only
perform *lexical* canonicalization.
* In some cases, we can first call sigaction()/signal(), then *not* pledge
sigaction.
* In other cases, we pledge sigaction at first, call sigaction()/signal()
second, then pledge again, this time without sigaction.
* In yet other cases, we keep the sigaction pledge. I suppose these could all be
migrated to drop it or not pledge it at all, if somebody is interested in
doing that.
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.
