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! :^)
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 :^)
Separators can't have identifiers associated with them, so it's not
possible to react meaningfully to their activation. Don't send messages
about it to avoid confusing the clients.
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! :^)
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.
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!
Take some inspiration from the first release of Visual Studio .NET and
add a left-hand stripe to contain the icons. And various other tweaks.
This isn't quite perfect, but it's pretty neat! :^)
Any GAction that has an icon assigned will now show up with that icon
when added to a menu as well.
I made the menu items 2px taller to accomodate the icons. I think this
turned out quite nice as well :^)
Paint a little checkbox frame for checkable items to make it obvious
that they are indeed checkable. This looks quite nice :^)
We also now shift all menu items to the right if we have any checkable
items in the menu.
Now that the window used by a WSMenu is its child CObject, the menu also
receives CChildEvent's about the window, including CEvent::ChildAdded when
the window gets created. At this point, menu_window() still returns nullptr,
so stop unconditionally assuming that it doesn't. We should not care whether
or not we have a window for unrelated events anyway.
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. :^)
They show up as checkable GButtons in GToolBar, and with (or without) check
marks in menus.
There are a bunch of places to make use of this. This patch only takes
advantage of it in the FileManager for the view type actions.
To get truly atomic updates, add a mechanism for passing arbitrary amounts
of extra data along with WindowServer messages. This allows us to pass all
the rects in a single message.
This was pretty straightforward thanks to the work I did separating out
LibCore from LibGUI already. :^)
- WSMessageLoop now inherits from CEventLoop.
- WSMessage now inherits from CEvent.
- WSMessageReceiver goes away.
Now there is only one event loop in Serenity. Very nice!
The enabled state of a GAction now propagates both to any toolbar buttons
and any menu items linked to the action. Toolbar buttons are painted in
a grayed out style when disabled. Menu items are gray when disabled. :^)
