If there is a current menu, we now redirect all key events from window
manager to the menu manager. This allows us to properly navigate a menu
even when there is a current menu open.
Menu key navigation is now a lot more pleasant to use :^)
The action of pressing escape to close a menu has also been moved to its
proper home in menu manager in this commit.
The system menu can now be opened by pressing the window key even while
in a focused window. The current menu can also now be closed by pressing
escape.
We still cannot navigate a menu using arrow keys while there is an
active window, but this is another step towards that.
This allows you to click on the menu, then use the menu keys to browse
the menu. Beforehand, you would click the window, release the button,
and the menu would close :(
Add event handling for key presses for navigating a menu. The currently
hovered menu item is tracked through an index which is either
incremented or decremented on up or down arrow key presses, changing the
hovered item.
Whenever there is a mouse move event, we ensure that the current index
matches the currently hovered item so that the mouse and keyboard do not
get out of sync.
If the right key is pressed, and we are on a submenu menu item, we
'enter' that submenu. While we are currently in a submenu, we forward
all keypress events to that submenu for handling. This allows us to
traverse the heirachy of a menu. While in a submenu, if the left key is
pressed, we leave that submenu and start handling the keypresses
ourselves again.
There is currently a small issue where the mouse hover and key hover can
get out of sync. The mouse can be traversing a submenu, but the parent
menu has no idea that the mouse has 'entered' a submenu, so will handle
the key presses itself, instead of forwarding them to the submenu. One
potential fix for this is for a menu to tell its menu parent that the
submenu is being traversed.
The clock menu applet was causing pixel ghosting at some seemingly
arbitrary location on the desktop because the background paint logic
tries to avoid painting any part of the background that's covered by
an opaque window.
Since the code was using any_opaque_window_contains_rect() to check
this, we were not considering the window's *type*. (Menu applets are
still windows, but they are of the special type "MenuApplet" and do
not participate in normal compositing.)
The fix is to use for_each_visible_window_from_back_to_front() instead
of for_each_window() :^)
Fixes#1022.
Menus are now owned by menu manager instead of being split between the
window manager and menu manager. If the window server wants to change
a menu, or call menu related functionality, this will need to be done
through the menu manager.
Further refactoring is likely needed, but this seems like a good start
for seperating menu logic from window logic.
We were not sending the ID of the window that was listening for window
management (WM) events along with the WM messages. They only included
the "target" window's ID.
Since the taskbar's single window had the first window ID for its own
connection to the WindowServer, it meant that it would only receive
WM events for the first window ID in other processes as well.
This broke when I ported WindowServer to LibIPC.
Fix this by including the WM listener ID in all WM messages, and since
we're here anyway, get rid of a bunch of unnecessary indirection where
we were passing WM events through the WindowServer event loop before
sending them to the listener.
This is done here rather than pick_new_active_window() so that when
there are no other windows to focus but the previous window hasn't
been removed (just minimized), the menu bar remains on that client.
Also make sure we send out the WM event for window deactivations.
This fixes an issue where the taskbar button for a window would appear
depressed, even after the window was deactivated.
When the currently active (foreground) window is owned by a client,
we now apply a +10 priority boost to the client's main thread.
You normally want the window you're interacting with to be responsive,
so this little boost allows it to run a bit sooner and more often. :^)
Palette is now a value wrapper around a NonnullRefPtr<PaletteImpl>.
A new function, set_color(ColorRole, Color) implements a simple
copy-on-write mechanism so that we're sharing the PaletteImpl in the
common case, but allowing you to create custom palettes if you like,
by getting a GWidget's palette, modifying it, and then assigning the
modified palette to the widget via GWidget::set_palette().
Use this to make PaintBrush show its palette colors once again.
Fixes#943.
WindowServer now tracks whether windows are occluded (meaning that
they are completely covered by one or more opaque windows sitting above
them.) This state is communicated to the windows via WindowStateChanged
messages, which then allow GWindow to mark its backing store volatile.
This reduces the effective memory impact of windows that are not at all
visible to the user. Very cool. :^)
WindowServer will now send out a WindowStateChanged message to clients
when one of their windows is minimized.
This is then forwarded to the GWindow, which will try to mark its
underlying window backing store as volatile.
This allows the kernel to steal the memory used by minimized windows
in case it starts running low. Very cool! :^)
GApplication now has a palette. This palette contains all the system
theme colors by default, and is inherited by a new top-level GWidget.
New child widgets inherit their parents palette.
It is possible to override the GApplication palette, and the palette
of any GWidget.
The Palette object contains a bunch of colors, each corresponding to
a ColorRole. Each role has a convenience getter as well.
Each GWidget now has a background_role() and foreground_role(), which
are then looked up in their current palette when painting. This means
that you no longer alter the background color of a widget by setting
it directly, rather you alter either its background role, or the
widget's palette.
Color themes are loaded from .ini files in /res/themes/
The theme can be switched from the "Themes" section in the system menu.
The basic mechanism is that WindowServer broadcasts a SharedBuffer with
all of the color values of the current theme. Clients receive this with
the response to their initial WindowServer::Greet handshake.
When the theme is changed, WindowServer tells everyone by sending out
an UpdateSystemTheme message with a new SharedBuffer to use.
This does feel somewhat bloated somehow, but I'm sure we can iterate on
it over time and improve things.
To get one of the theme colors, use the Color(SystemColor) constructor:
painter.fill_rect(rect, SystemColor::HoverHighlight);
Some things don't work 100% right without a reboot. Specifically, when
constructing a GWidget, it will set its own background and foreground
colors based on the current SystemColor::Window and SystemColor::Text.
The widget is then stuck with these values, and they don't update on
system theme change, only on app restart.
All in all though, this is pretty cool. Merry Christmas! :^)
When we're in a drag, we're no longer concerned with streaming mouse
events to the window that initiated the drag, so just clear the active
input window pointer.
This fixes an issue where you'd have to click once after drag and drop
in order to "release" the mouse from the active input window.
These fields are intended to carry the real meat of a drag operation,
and the "text" is just for what we show on screen (alongside the cursor
during the actual drag.)
The data field is just a String for now, but in the future we should
make it something more flexible.
This patch introduces the second MenuApplet: Audio. To make this work,
menu applet windows now also receive mouse events.
There's still some problem with mute/unmute via clicking not actually
working, but the call goes from the applet program over IPC to the
AudioServer, where something goes wrong with the state change message.
Need to look at that separately.
Anyways, it's pretty cool to have more applets running in their own
separate processes. :^)
Instead of implementing menu applets as their own thing, they are now
WSWindows of WSWindowType::MenuApplet.
This makes it much easier to work with them on the client side, since
you can just create a GWindow with the right type and you're in the
menubar doing applet stuff :^)
Windows that are being moved around by the user are now called "moving"
windows instead of "dragging" windows, to avoid confusion with the
drag and drop stuff.
This bitmap is displayed alongside the dragged text underneath the
mouse cursor while dragging.
This will be a perfect fit for dragging e.g files around. :^)
This patch enables basic drag&drop between applications.
You initiate a drag by creating a GDragOperation object and calling
exec() on it. This creates a nested event loop in the calling program
that only returns once the drag operation has ended.
On the receiving side, you get a call to GWidget::drop_event() with
a GDropEvent containing information about the dropped data.
The only data passed right now is a piece of text that's also used
to visually indicate that a drag is happening (by showing the text in
a little box that follows the mouse cursor around.)
There are things to fix here, but we're off to a nice start. :^)
Currently menu applets are laid out relative to the "audio rect" which
is the rect of the little audio muted state icon thingy.
There was an issue where applets would be placed at a negative X coord
if they were added to the WindowServer before the first time drawing
the menubar.
This patch introduces code generation for the WindowServer IPC with
its clients. The client/server endpoints are defined by the two .ipc
files in Servers/WindowServer/: WindowServer.ipc and WindowClient.ipc
It now becomes significantly easier to add features and capabilities
to WindowServer since you don't have to know nearly as much about all
the intricate paths that IPC messages take between LibGUI and WSWindow.
The new system also uses significantly less IPC bandwidth since we're
now doing packed serialization instead of passing fixed-sized structs
of ~600 bytes for each message.
Some repaint coalescing optimizations are lost in this conversion and
we'll need to look at how to implement those in the new world.
The old CoreIPC::Client::Connection and CoreIPC::Server::Connection
classes are removed by this patch and replaced by use of ConnectionNG,
which will be renamed eventually.
Goodbye, old WindowServer IPC. You served us well :^)
When a window is being resized, its size may differ from the size of its backing
store. In this case, peek at the direction the window is being resized in, and
render the backing store at the same place as it was previously.
https://github.com/SerenityOS/serenity/issues/52
When a window is being interactively resized, there are several rules
beyond the actual mouse movement that can impact the new size of the
window, such as its size increments and minimum size limit.
Move the placement logic after applying all the sizing logic, so that
whatever final size the window ends up with, the sides of the window
that do move are the ones that the user is dragging.
https://github.com/SerenityOS/serenity/issues/52
Let the global menu bar be either "open" or "closed". Clicking on one
of the menus in the menu bar toggles the state.
This ends up simpler and more intuitive than what we had before.
This patch moves a whole lot of the menu logic from WSWindowManager to
its proper home in WSMenuManager.
We also get rid of the "close_current_menu()" concept which was easily
confused in the presence of submenus. All operations should now be
aware of the menu stack instead. (The concept of a single, current menu
made a lot more sense when there were no nested menus.)
If the .af file for an app contains the App/Category key, we'll now put
it in a submenu of the system menu, together with all the other apps in
that same category. This is pretty neat! :^)
The new system directory /res/apps now contains ".af" files describing
applications (name, category, executable path, and icon.)
These are used to populate the system menu with application shortcuts.
This will replace the Launcher app. :^)
