| Age | Commit message (Collapse) | Author |
|---|
|
|
|
The sample Wizard subclasses WizardDialog and demonstrates a front and
back cover, as well as extracting user input from a Wizard page to
display in the interface which spawned the Wizard.
|
|
This patch provides the basic components needed for developers to create
consistent wizard interface experiences in their applications.
`WizardDialog` provides the dialog frame for the wizard, handling navigation
and presentation.
`AbstractWizardPage`s form the base class of Wizard pages, which are
pushed onto the `WizardDialog` page stack via `WizardDialog::push_page`.
`CoverWizardPage` and `WizardPage` are provided to ease the creation of
Wizard interfaces consistent with the Serenity visual language.
|
|
This is basically just for consistency, it's quite strange to see
multiple AK container types next to each other, some with and some
without the namespace prefix - we're 'using AK::Foo;' a lot and should
leverage that. :^)
|
|
(...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED)
Since all of these checks are done in release builds as well,
let's rename them to VERIFY to prevent confusion, as everyone is
used to assertions being compiled out in release.
We can introduce a new ASSERT macro that is specifically for debug
checks, but I'm doing this wholesale conversion first since we've
accumulated thousands of these already, and it's not immediately
obvious which ones are suitable for ASSERT.
|
|
Because re-evaluation of the hovered window may trigger sending a
MouseMove event to a window we should only wake it if the mouse
position actually has changed.
|
|
|
|
This is now consistent with the other dialog classes.
|
|
|
|
|
|
...and functions implemented in terms of it: blit_brightened(),
blit_dimmed(), blit_disabled().
In theory, this should stop the window server from asserting when
an application becomes unresponsive, but that feature seems to be
broken for unrelated reasons atm (#5111).
|
|
If the source image had no alpha channel we'd ignore opacity < 1.0 and
blit the image as if it was fully opaque.
With this fix, adjusting the opacity of windows with mousewheel while
holding super works in hidpi mode.
|
|
Now we no longer crash on mousewheel over Terminal while holding the
super key. The terminal window doesn't yet correctly become transparent
in hidpi mode (needs more investigation), but it works in LibGfxScaleDemo,
so maybe that's a problem elsewhere.
Also add a FIXME for a pre-existing bug.
|
|
mode 'simple'
blit() calls draw_scaled_bitmap() behind the scenes in scaled contexts,
and that doesn't like src_rect to be outside of the source bitmap's
bounds. Implicitly clip with the source rect, like the non-scaled
codepath already does.
Fixes #5017 even more.
|
|
|
|
Consider
draw_scaled_bitmap({0, 0, 10, 10}, source, {0, 0, 5, 5}).
Imagine wanting to split that up into two calls, like e.g. the
compositor when redrawing the background with damage rects. You really
want to be able to say
draw_scaled_bitmap({0, 0, 5, 10}, source, {0, 0, 2.5, 5})
but up to now you couldn't. Now you can.
This makes painting very low-res images (such as tile.png) in mode
"stretch" work much better.
|
|
Application.h includes Widget.h which includes Application.h. I'm not entirely
sure what the semantics are in this case, but avoiding this seems to be the
safer approach. In this case, Widget does not actually use Application, so let's
just remove the unused include.
|
|
draw_scaled_bitmap() has a clearer API (just source and dest rects --
blit_scaled() took those and scale factors and then ignored width and
height on the source rect and it was less clear what it was supposed to
do), and they do mostly the same thing.
The draw_scaled_bitmap() API takes an IntRect as source rect, so it's
currently not always possible to split a big draw_scaled_bitmap() into
two (or more) smaller draw_scaled_bitmap() calls that do the same thing
-- that'd require FloatRects. The compositor kind of wants this to be
possible, but there's already a FIXME about this not looking quite right
with the previous approach either.
draw_scaled_bitmap() handles transparent sources, so after this change
wallpapers with transparency will be blended instead of copied. But that
seems fine, and if not, the Right Fix for that is to remove the alpha
channel from wallpapers after loading them anyways.
As an added bonus, draw_scaled_bitmap() already handles display scale,
so this fixes window server asserts for background images that are shown
as "stretch" (#5017). The window server still asserts for "tile" and
"offset" for now though.
Calling draw_scaled_bitmap() here exposed a bug in it fixed by #5041.
Before that is merged, this change here will cause smearing on the
background image when moving windows around.
|
|
The do_draw_integer_scaled_bitmap() fastpath already handled this
correctly, but the arbitrary scale path did not.
|
|
|
|
Gfx::Bitmap can now store its scale factor. Normally it's 1, but
in high dpi mode it can be 2.
If a Bitmap with a scale factor of 2 is blitted to a Painter with
scale factor of 2, the pixels can be copied over without any resampling.
(When blitting a Bitmap with a scale factor of 1 to a Painter with scale
factor of 2, the Bitmap is painted at twice its width and height at
paint time. Blitting a Bitmap with a scale factor of 2 to a Painter with
scale factor 1 is not supported.)
A Bitmap with scale factor of 2 reports the same width() and height() as
one with scale factor 1. That's important because many places in the
codebase use a bitmap's width() and height() to layout Widgets, and all
widget coordinates are in logical coordinates as well, per
Documentation/HighDPI.md.
Bitmap grows physical_width() / physical_height() to access the actual
pixel size. Update a few callers that work with pixels to call this
instead.
Make Painter's constructor take its scale factor from the target bitmap
that's passed in, and update its various blit() methods to handle
blitting a 2x bitmap to a 2x painter. This allows removing some gnarly
code in Compositor. (In return, put some new gnarly code in
LibGfxScaleDemo to preserve behavior there.)
No intended behavior change.
|
|
I want to give Bitmap an intrinsic scale factor and this is a step
in that direction.
No behavior change.
|
|
Now that WindowServer broadcasts the system theme using an anonymous
file, we need clients to pledge "recvfd" so they can receive it.
Some programs keep the "shared_buffer" pledge since it's still used for
a handful of things.
|
|
|
|
I thought this wouldn't work yet, but it already does.
|
|
Needed for the window server minimize animation.
draw_rect() can't just call draw_line() because that isn't
draw_op()-aware. The draw_op()-awareness in Painter looks a bit ad-hoc,
but that's for another day.
|
|
|
|
This is needed for the new way we transfer window backing stores.
|
|
This adds a scale factor to Painter, which will be used for HighDPI
support. It's also a step towards general affine transforms on Painters.
All of Painter's public API takes logical coordinates, while some
internals deal with physical coordinates now. If scale == 1, logical
and physical coordinates are the same. For scale == 2, a 200x100 bitmap
would be covered by a logical {0, 0, 100, 50} rect, while its physical
size would be {0, 0, 200, 100}.
Most of Painter's functions just assert that scale() == 1 is for now,
but most functions called by WindowServer are updated to handle
arbitrary (integer) scale.
Also add a new Demo "LibGfxScaleDemo" that covers the converted
functions and that can be used to iteratively add scaling support
to more functions.
To make Painter's interface deal with logical coordinates only,
make translation() and clip_rect() non-public.
|
|
|
|
|
