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.
set_current_menu() was indiscriminately closing all menus when the
current menu is not a submenu. We should only close menus not in lineage
to the one being closed.
We were forgetting to update the current menu when switching to a new
item.
We also rename the function from implying that only a redraw is
happening, as is actually not the case. It is now more correctly named:
update_for_new_hovered_item()
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.
m_current_menu was being set and then immediately cleared by
close_everyone(). Furthermore, since the menu being set can be a
nullptr, we now also make sure to handle that.
Finally, the logic can be simplified. close on the current menu is not
required, as that is also done by close_everyone().
We're gonna need to handle overflow better than this, but at least this
way we can see the top of the menu, even if we can't scroll down to see
the rest of it.
For #1043.
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 now pick up all the user's extra GIDs from /etc/group and make
sure those are set before exec'ing a service.
This means we finally get to enjoy being in more than one group. :^)
We were letting services inherit writable fds for /dev/tty0, as well as
having /dev/tty0 as their controlling terminal.
Lock this down by closing fds {0,1,2} when spawning a service. We also
detach from the controlling terminal. An exception is made for services
with an explicit StdIO setting. In those cases, we now switch the
controlling terminal to the specified path if possible.
Also make the sockets readable and writable only by that user.
This fixes a bug where anyone could connect to anyone else's services,
most obviously WindowServer.
Also add error checking and bail out if either call fails.
Doing it the wrong way around was causing us to retain GID=0 for all
processes (oops!)
Thanks to Chris Ball for reporting the bug. :^)
Previously we would be left with a menu stack containing nulled-out
WeakPtr's to menus in the now-disconnected clients.
This was tripping up an assertion when clicking anywhere after shutting
down a program while it had a menu open.
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.
