| 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.
|
|
Holding Shift key will constrain the LineTool's line angle to 15 degrees
increments. Many graphics editors have similar feature.
|
|
|
|
This is primarily to make it possible to pass a GMenu* where a CObject*
is expected.
|
|
Sometimes you change your mind mid-line, and just want to get out of
the situation. You can now do that :^)
|
|
This implements "preview" of the line by allowing tool subclasses to
hook the second_paint_event on the PaintableWidget.
Work towards #375.
|
|
Comes with a checkbox to turn it off if you dislike it.
|
|
GFilePicker
- Fixed GFilePicker to use new ref-counted construct method to stop crashing on open dialog.
- PaintBrush is still crashing on open dialog due to an unrelated issue.
PaintBrush
- Created 16x16 icon for PaintBrush
- Moved Open option into App menu.
- Changed help menu to make use of the standardized About dialog.
|
|
We no longer support creating CObjects on the stack. Use construct().
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Make use of this in PaintBrush and TextEditor. :^)
|
|
|
|
Use the same callback signature as GAction so we can just forward it
to GAction instead of chaining callbacks.
|
|
We had many context menus with names, simply because you were forced
to give them names.
|
|
Tools don't know what to do with the middle mouse button anyway,
so it's better if we just don't pass it along.
Fixes #546.
|
|
|
|
This macro goes at the top of every CObject-derived class like so:
class SomeClass : public CObject {
C_OBJECT(SomeClass)
public:
...
At the moment, all it does is create an override for the class_name() getter
but in the future this will be used to automatically insert member functions
into these classes.
|
|
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. :^)
|
|
Currently the two available input types are:
- GMessageBox::InputType::OK (default)
- GMessageBox::InputType::OKCancel
Based on your choice, GMessageBox::exec() will return ExecOK or ExecCancel.
|
|
This should make you think twice before trying to use the const char* from
a StringView as if it's a null-terminated string.
|
|
|
|
|
|
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. :^)
|
|
|
|
|
|
Further consolidation is of course possible, eg the Games/ programs
follow the same rules more or less.
|
|
Eventually I'd like to do some kind of bitmap layers, and we definitely want
alpha channel support then, so let's just not paint ourselves into an
uncomfortable corner early on. :^)
|
|
Obviously this only supports whatever PNG files that load_png() can decode
at the moment.
|
|
Painter gains the ability to draw lines with arbitrary thickness.
It's basically implemented by drawing filled rects for thickness>1.
In PaintBrush, Tool classes can now override on_contextmenu() to
provide a context menu for the toolbox button. :^)
|
|
|
|
|
|
|
|
|
|
|
|
Could do with some more tweaking no doubt, and it'd be nice to have a
circular spray, but this is better than nothing.
|
|
|
|
Maybe the ColorDialog class could be fashioned into something generally
usable in LibGUI, but for now it lives in the PaintBrush app. :^)
|
