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. :^)
The menubar bar wasn't being resized correctly, as the underlying Window
was never being resized when `DisplayProperties` was chaning the
resolution while the system was running. `m_window` now gets the
correct window size when it's been updated, so a reboot isn't required.
Okay, I've spent a whole day on this now, and it finally kinda works!
With this patch, CObject and all of its derived classes are reference
counted instead of tree-owned.
The previous, Qt-like model was nice and familiar, but ultimately also
outdated and difficult to reason about.
CObject-derived types should now be stored in RefPtr/NonnullRefPtr and
each class can be constructed using the forwarding construct() helper:
auto widget = GWidget::construct(parent_widget);
Note that construct() simply forwards all arguments to an existing
constructor. It is inserted into each class by the C_OBJECT macro,
see CObject.h to understand how that works.
CObject::delete_later() disappears in this patch, as there is no longer
a single logical owner of a CObject.
With this patch, CEvents no longer stop at the target object, but will
bubble up the ancestor chain as long as CEvent::is_accepted() is false.
To the set accepted flag, call CEvent::accept().
To clear the accepted flag, call CEvent::ignore().
Events start out in the accepted state, so if you want them to bubble
up, you have to call ignore() on them.
Using this mechanism, we now ignore non-tabbing keydown events in
GWidget, causing them to bubble up through the widget's ancestors. :^)
We now require that the two clicks that make up a double-click be no
more than 4px apart.
This fixes the annoying behavior where you'd often get incorrect
double-click events on GUI widgets.
It's now possible to add a GMenu as a submenu of another GMenu.
Simply use the GMenu::add_submenu(NonnullOwnPtr<GMenu>) API :^)
The WindowServer now keeps track of a stack of open menus rather than
just one "current menu". This code needs a bit more work, but the basic
functionality is now here!
This fixes an issue where we'd send a "cursor has left the window"
message incorrectly to the client after a button was clicked and the
user moved the cursor a little without releasing the button.
The issue was that we didn't update the 'hovered_window' out param
in mouse event processing in the case where we had an active input
window set.
Now that we can set icons directly "by bitmap", there's no need for passing
around the icon paths anymore, so get rid of all the IPC and API related
to that. :^)
Now that we support more than 2 clients per shared buffer, we can use them
for window icons. I didn't do that previously since it would have made the
Taskbar process unable to access the icons.
This opens up some nice possibilities for programmatically generated icons.
Instead of LibGUI and WindowServer building their own copies of the drawing
and graphics code, let's it in a separate LibDraw library.
This avoids building the code twice, and will encourage better separation
of concerns. :^)
The only reason for the inheritance was to add FDs to the select set.
Since CNotifier is available (and now also quite useful), we can make use of it
instead, and remove the inheritance.
We were sometimes delivering the same mouse event twice to the active input
window. This happened because we had already delivered it via the automatic
cursor tracking mechanism.
This is effectively a mouse grab except that we don't require any client
coordination to request it (which is probably OK, and certainly a lot
simpler to implement).
This prevents e.g. dragging the mouse cursor out of paint and over the
terminal from selecting text unexpectedly.
Previously we were rendering the whole menubar on every compose(),
even if nothing changed about it. Now it's in its own window and can
be invalidated and painted separately.
