| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
These are now separate from the Window and WindowText colors.
|
|
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! :^)
|
|
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.
|
|
Also skip painting the titlebar stripes and/or title entirely if we
don't have enough space for them.
Fixes #524.
|
|
|
|
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. :^)
|
|
Someone suggested this a long time ago and I never got around to it.
So here we go, here's the warm gray! I have to admit I like it better. :^)
|
|
Taskbar now simply asks the WindowServer to popup a window menu when right
clicking on a taskbar button.
This patch also implements the "close" menu item, and furthermore makes the
window menu show up when you left-click a window's titlebar icon. :^)
|
|
|
|
We were only updating it in the WSButton callback, not when changing the
maximized state by calling WSWindow::set_maximized().
Fixes #119.
|
|
Add a subtle shadow to the titlebar text. Also make the titlebar one pixel
taller to fully accomodate the 90s "3D frame" effect. :^)
|
|
|
|
|
|
Also, Launcher now does not use titlebars.
Only check if titlebar should be shown if the window type works with that.
|
|
This is far from finished and the two classes are awkwardly grabbing at each
other's innards, but here's a first step in the right direction.
|
|
|
|
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. :^)
|
|
We were allowing initiation of resize from the bottom titlebar edge
since everything inside the window frame that's not either inside the
title bar, or inside the window content, is considered the border.
|
|
The minimize button can stay though, since it doesn't change the window
size, just the visibility. :^)
|
|
|
|
|
|
|
|
|
|
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 patch makes menus stand out a bit more from their background by using
the same kind of shading that Windows 2000 had.
|
|
Since I'm on a roll here, I'll just rename WSMessageFoo to WSEventFoo now
that these inherit from CEventFoo anyway.
|
|
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!
|
|
|
|
|
|
Any GWidget can have a tooltip and it will automatically pop up below the
center of the widget when hovered. GActions added to GToolBars will use
the action text() as their tooltip automagically. :^)
|
|
|
|
|
|
The window is simply ignored in the painting and hit testing traversal
when in minimized state, same as we do for invisible windows.
The WM_SetActiveWindow message (sent by Taskbar) brings it back into the
non-minimized state. :^)
|
|
Previously it would just close the window on MouseDown. Now we do the normal
thing where we require a MouseUp inside the button rect before committing.
|
|
This was a bit painful to get right. The code is a lot more pleasant to
deal with now that all coordinates are relative to their local system
instead of being absolute screen coordinates.
|
|
|
|
The window frame is an object that contains a window, its title bar and
window border. This way WSWindowManager doesn't have to know about all the
different types of window borders, titlebar rects, etc.
|
