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.
Fullscreen windows are rendered alone and above everything else when they
are active, and as part of the regular window stack order when something
else is active.
Currently windows cannot be made fullscreen after-the-fact, but must have
the fullscreen flag included in their CreateWindow message.
It should not possible to interact with the menu, taskbar or window frame
while the active window is fullscreened. :^)
