This is really just a workaround to keep SystemMonitor's process table
working right wrt selection retention during resorts (while also doing
full index invalidation on things like ProfileViewer inversion.)
It's starting to feel like the model abstraction is not super great
and we'll need a better approach if we want to actually build some more
dynamic functionality into our views.
ColorInput is a new GUI component for selecting color using ColorPicker dialog.
It is simplify usage of ColorPicker dialog and more elegant view of current selected color.
This is a stop-gap patch solution for the annoying problem of models
being bad at updating. At least the process table will retain your
selection in SystemMonitor now.
This allows us to construct menus in a more natural way:
auto& file_menu = menubar->add_menu("File");
file_menu.add_action(...);
Instead of the old way:
auto file_menu = GUI::Menu::construct();
file_menu->add_action(...);
menubar->add_menu(file_menu);
This patch adds a specialized window type for notifications. They now
have a title bar on the right-hand side, with a close button.
This removes the need for the "Done" button in notifications, giving us
a bit more horizontal space overall.
Design based on a mock-up from @xTibor :^)
With this patch, it's now possible to pass a Gfx::ShareableBitmap in an
IPC message. As long as the message itself is synchronous, the bitmap
will be adopted by the receiving end, and disowned by the sender nicely
without any accounting effort like we've had to do in the past.
Use this in NotificationServer to allow sending arbitrary bitmaps as
icons instead of paths-to-icons.
We currently use icon paths for this because I didn't want to deal with
implementing icon bitmap sharing right now. In the future it would be
better to post a bitmap somehow instead of a path.
Since NotificationServer is a spawn-on-demand + die-when-not-used type
of service, we can't expect a singleton connection to it to remain open
and useful.
We solve this for now by making a new IPC connection for every new
notification sent. Maybe there's a better solution for this.
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. :^)
Remember the override cursor in GUI::Window and avoid sending a message
to WindowServer when possible.
This removes a lot of synchronous IPC between Browser and WindowServer,
which noticeably improves DOM event responsiveness. :^)
