This is making me question the usefulness of application-global
shortcuts, but for now let's just prevent them from triggering while
you're looking at a modal message box..
...instead of maybe bitmap + a single mime type and its corresponding data.
This allows drag&drop operations to hold multiple different kinds of
data, and the views/applications to choose between those.
For instance, Spreadsheet can keep the structure of the dragged cells,
and still provide text-only data to be passed to different unrelated editors.
* 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
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.
During app teardown, the Application object may be destroyed before
something else, and so having Application::the() return a reference was
obscuring the truth about its lifetime.
This patch makes the API more honest by returning a pointer. While
this makes call sites look a bit more sketchy, do note that the global
Application pointer only becomes null during app teardown.
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"
Widgets can now opt in to emoji input via set_accepts_emoji_input().
If the focused widget accepts emoji input, we'll pop up a simple dialog
with all the available emojis as clickable buttons.
You can press escape if you change your mind and don't want an emoji.
This UI layout definitely will not scale as we add more emojis, but it
works for the moment, and we can adapt it as we go. Pretty cool! :^)
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.
We were iterating the ancestor chain of the focused widget when looking
for a matching keyboard shortcut, but we didn't actually look at the
ancestors at each step.
With this fix, we now correctly activate actions found in the ancestor
chain of the focused widgets. :^)
Instead of only looking in the focused widget, we now also look in the
ancestor chain of that widget for any ancestor with a registered action
for the given shortcut.
This makes it possible for parent widgets to capture action activations
while one of their children is focused.
The original implementation only sent out notifications when there was
something being drawn on screen. If nothing was going on, we'd get too
lazy and just not notify display links.
This obviously break requestAnimationFrame(), so now we just drive the
DisplayLinks at 60 fps no matter what. :^)
This patch adds GUI::DisplayLink, a mechanism for registering callbacks
that will fire at the display refresh rate.
Note that we don't actually know the screen refresh rate, but this is
instead completely driven by WindowServer's compositing timer. For all
current intents and purposes it does the job well enough. :^)
This feels a lot more consistent and Unixy:
create_shared_buffer() => shbuf_create()
share_buffer_with() => shbuf_allow_pid()
share_buffer_globally() => shbuf_allow_all()
get_shared_buffer() => shbuf_get()
release_shared_buffer() => shbuf_release()
seal_shared_buffer() => shbuf_seal()
get_shared_buffer_size() => shbuf_get_size()
Also, "shared_buffer_id" is shortened to "shbuf_id" all around.
This allows windows/widgets to learn when something is being dragged
over them. They can then repaint themselves somehow to indicate that
they are willing to accept a drop.
Currently this is piggybacking somewhat on the mouse event mechanism
in WindowServer. I'm not sure that's the best design but it seemed
easier to do it this way right now.
