Previously, if you opened MouseSettings, set the cursor theme to Dark,
and then click "Defaults", the cursors list would not update.
ComboBox::set_text() does not call the on_change callback, so we have
to run the steps manually.
I've also made `m_theme_name` into a local variable, since it can be.
When user code requests the current cursor theme name with
`GUI::ConnectionToWindowServer::the().get_cursor_theme()`, that reads
the name from the config file. If we don't write that out when it's
changed, then users get given an outdated cursor theme instead of the
current one.
In particular, changing the theme in MouseSettings, saving and closing
it, then reopening MouseSettings, would show the wrong theme selected.
So, that's fixed now. :^)
SettingsWindow now notices if the window is marked as modified, and
shows a confirmation pop-up to check if the user wants to apply or
discard their changes. It automatically marks the window as unmodified
after restoring defaults or applying the changes, but each Tab subclass
needs to call `set_modified(true)` when the user modifies things.
The "Apply" button is automatically disabled when there are no unsaved
changes to be applied.
This is the only Widget that ran its callback in deferred_invoke(). It
seems to be a holdover from when syntax-highlighting ran whenever the
text changed, but that has not been true since
bec2b3086c. Running the callback
immediately has no obvious downsides, but does make it a lot easier to
reason about. (I might have spent an hour confused as to why things
were happening in the wrong order...)
This commit implements glClipPlane and its supporting calls, backed
by new support for user-defined clip planes in the software GPU clipper.
This fixes some visual bugs seen in the Quake III port, in which mirrors
would only reflect correctly from close distances.
Now, when windows flash, the "active" color of the window title frame's
flash is the highlight color instead of the standard window color. The
"inactive" color of the flash is still the disabled color as before.
Reasoning behind this change in aesthetics: There are four [1] window
title frame colors with specific UI purposes:
1. "Active" for the normal active window, obvious purpose.
2. "Moving" for the window that is being dragged or resized by the user.
Responsible for acting as a visual click feedback as a kind of
subdued button.
3. "Inactive" for any inactive windows, obvious purpose.
4. "Highlight".
The purpose of "Highlight" is in the name, though it's non-obvious what
that exactly entails. Before, only alt-tab selecting windows would use
the highlight color for showing the current target window. In my opinion
this points to the purpose of "highlight" being to move the user's focus
to another window when the simple active state is not enough. Then it
makes sense to have the window flashing use the highlight color. The
entire purpose of window flashing is to shift the user's focus to a
dialog window that might not be close to the window they just clicked.
Using the highlight color enables an even stronger emphasis than before.
It enables a cleaner separation between the purpose of the two frame
colors, as well as making the "Highlight" frame more common.
[1] Technically there are eight, as the title frame has a gradient by
default. We can count the gradient as one color for this purpose.
According to the OpenGL spec, we're expected to clamp the fragment
depth values to the range `0.f - 1.f` for all polygons.
This fixes Z-fighting issues with the sky in Quake 3.
- Delete the part about removing `[Exposed=Window]` since that's not
necessary and we may want that information there to generate the
Window object.
- Mention adding `#import`s.
- Outline the requirements for the implementation class.
- Mention the non-Event wrapper factories that need to know about
certain types.
I tend to refer to this document every time I add an IDL type so it's
helpful if it's comprehensive.
Both of these are supposed to be set when the CSSRule is created. The
spec is silent on setting it when a CSSRule is added to a parent. So,
this is a bit ad-hoc.
The parent rule gets set whenever a rule is added to a new parent. The
parent stylesheet gets set whenever the rule or one of its ancestors is
added to a different stylesheet. There may be some nuance there that
I'm missing, but I'm sure we'll find out quickly once we have WPT
running!
The spec is a little bizarre here. One caller of this
(`CSSStyleSheet::insert_rule()`) wants to give it a parsed CSSRule, but
the spec itself wants it to take a string. (As will be used by
`CSSGroupingRule::insert_rule()`) Using a Variant isn't pretty but it's
the best solution I've come to - having two overloads was worse, whether
one called the other or they just duplicated the logic. This seems the
least bad.
This implements the depth offset factor that you can set through e.g.
OpenGL's `glPolygonOffset`. Without it, triangles might start to Z-
fight amongst each other.
This fixes the floor decals in Quake 3.
If an icon exists and the horizontal scroll value is larger than 0,
translate the TextEditor painter by the icon size and padding.
The text would scroll over the icon when the text was long enough to
trigger a horizontal scroll.
Fixes#13669.
Implement (anti)aliased point drawing and anti-aliased line drawing.
Supported through LibGL's `GL_POINTS`, `GL_LINES`, `GL_LINE_LOOP` and
`GL_LINE_STRIP`.
In order to support this, `LibSoftGPU`s rasterization logic was
reworked. Now, any primitive can be drawn by invoking `rasterize()`
which takes care of the quad loop and fragment testing logic. Three
callbacks need to be passed:
* `set_coverage_mask`: the primitive needs to provide initial coverage
mask information so fragments can be discarded early.
* `set_quad_depth`: fragments survived stencil testing, so depth values
need to be set so depth testing can take place.
* `set_quad_attributes`: fragments survived depth testing, so fragment
shading is going to take place. All attributes like color, tex coords
and fog depth need to be set so alpha testing and eventually,
fragment rasterization can take place.
As of this commit, there are four instantiations of this function:
* Triangle rasterization
* Points - aliased
* Points - anti-aliased
* Lines - anti-aliased
In order to standardize vertex processing for all primitive types,
things like vertex transformation, lighting and tex coord generation
are now taking place before clipping.
Previously `git am` could fail on patches with Windows line endings
(CRLF). By supplying `--keep-cr`, we prevent git from stripping the CR
from our patches.
Instead of storing the current Processor into a core local register, we
currently just store it into a global, since we don't support SMP for
aarch64 anyway. This simplifies the initial implementation.
