| 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.
|
|
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! :^)
|
|
Allow everything to be built from the top level directory with just
'make', cleaned with 'make clean', and installed with 'make
install'. Also support these in any particular subdirectory.
Specifying 'make VERBOSE=1' will print each ld/g++/etc. command as
it runs.
Kernel and early host tools (IPCCompiler, etc.) are built as
object.host.o so that they don't conflict with other things built
with the cross-compiler.
|
|
This is primarily to make it possible to pass a GMenu* where a CObject*
is expected.
|
|
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 :^)
|
|
Now that CObject is fully ref-counted, just use RefPtr everywhere! :^)
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Use the same callback signature as GAction so we can just forward it
to GAction instead of chaining callbacks.
|
|
|
|
|
|
Move some of the "Game" menu into the app menu, and add a separate menu
for the difficulty setting.
|
|
|
|
We manage the checked state of these buttons manually in the code, and
we don't want the user to interfere with it, which would be possible if
we put them in checkable state.
|
|
Both on_square_clicked and flood_mark were very similar so I've
introduced the on_square_clicked_impl function which is now
called by on_square_clicked and flood_fill.
|
|
|
|
This change uses an iterative traversal to avoid stack overflows
in, the previously recursive, flood_fill.
|
|
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.
|
|
This behavior and API was extremely counter-intuitive since our default
behavior was for applications to never exit after you close all of their
windows.
Now that we exit the event loop by default when the very last GWindow is
deleted, we don't have to worry about this.
|
|
It was annoying to always write set_preferred_size({ width, height }). :^)
|
|
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. :^)
|
|
|
|
Instead of manually doing String::format("%d"/"%u") everywhere, let's have
a String API for this. It's just a wrapper around format() for now, but it
could be made more efficient in the future.
|
|
This makes more sense as it's where configuration writing happens.
|
|
This is how other Minesweeper games I've played usually behave.
Single-click chording can be disabled from the menu or config file.
|
|
|
|
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. :^)
|
|
|
|
|
|
|
|
|
|
Also run it across the whole tree to get everything using the One True Style.
We don't yet run this in an automated fashion as it's a little slow, but
there is a snippet to do so in makeall.sh.
|
|
Rather than having the first click hit a bomb, if the first click would
hit a bomb, instead, reset the game board.
This is a (sort of) feature of Windows minesweeper, and IMO makes
playing a bit more fun :-)
|
|
|
|
|
|
|
|
Use a number of techniques to avoid freezing the UI for too long.
- Keep reusing the same widgets for the squares once they've been created.
- Temporarily disable widget updates.
- Avoid some redundant work on each run of reset().
|
|
This is useful in the harder modes, for trying out different possibilities.
|
|
Someone was playing this game and suggested a number of improvements so here
we go trying to address them:
- Add "chording" support, where you can click a numbered square using both
mouse buttons simultaneously to sweep all non-flagged adjacent squares.
- Mis-flagged squares are now revealed as such on game over, with a special
"bad flag" icon.
- The game timer now shows tenths of seconds. It also doesn't start until
you click the first square.
- Add the three difficulty modes from the classic Windows version.
|
|
|
|
|
|
|
|
|
|
|
