| Age | Commit message (Collapse) | Author |
|---|
|
This is the final component that required LibProtocol as a dependency
of LibWeb. With this, we can now remove the dependency, and LibWeb no
longer requires IPC to work :^)
|
|
Much like the ImageDecoder change, this moves the underlying connection
of the Web::WebSockets class from LibWeb to LibWebView, removing the
need for LibProtocol in LibWeb for this specific use-case.
|
|
After this change, LibWeb now expects Web::ImageDecoding::Decoder to be
pre-initialized with a concrete implementation before using the webpage.
The previous implementation, based on the ImageDecoder service, has been
provided directly through an adapter in LibWebClient, and is now used as
the default value by WebContent.
|
|
This patch has no functional changes.
|
|
This patch has no functional changes.
|
|
This patch has no functional changes.
|
|
Also moves WebContentClient and the references to the generated IPC
descriptions, since they are all components of OutOfProcessWebView.
This patch has no functional changes.
|
|
Previously the option created by `make_help_action()` was unclear in its
meaning, by renaming the option to 'Manual' this should more
meaningfully represent the effect of the action.
|
|
Also skip the test for the `::Always` alpha test function in the hot
loop. This test function is very unlikely to be set, so leave that up
to `::test_alpha()`.
|
|
They were erroneously converted into `u64` by me in a previous commit,
causing the overdraw statistic to go haywire.
|
|
Previous check did not allow AltGr+letter to be used due to
AltGr being emulated as Ctrl+Alt. That caused .ctrl() to be true.
In the new code we check that ctrl() is not set or if it is set,
it is with altgr() and if so, we pass the character into the editor.
|
|
|
|
HTML, CSS, JS and text files (among other things) can all legitimately
be empty. Other types may be invalid, but that will be caught when
trying to parse it as a document, so this check can safely be removed.
|
|
|
|
Having to subclass GUI::Model for even the simplest type of hand-built
TreeView makes them a bit unpleasant to work with at the moment. :^)
This adds such a GUI::Model subclass that is specifically designed for
adding nodes to a TreeView manually, supporting text and an optional
icon by default, and allowing for further data when subclassing the Node
class.
|
|
menu"
This reverts commit 61dc48977832c7f705b9ccd29b74c9dd69ef5627.
This commit was causing FileManager to crash whenever you selected to
open a file using the context menu.
|
|
|
|
|
|
- Don't treat an empty `about:blank` resource as an error.
- Give `about:` urls a content-type so `FrameLoader::parse_document()`
won't reject them.
|
|
Upon DirectoryView selection change, check for write permission before
enabling delete and cut. This disallows attempting to delete/cut and
paste a file that you don't have write permission to by using keybinds.
Fixes #13983.
|
|
This patch has no functional changes, but prepares the CMake script to
be able to handle LibWeb on Lagom.
|
|
This has mainly performance benefits, so that we only need to call into
all processors once for every audio buffer segment. It requires
adjusting quite some logic in most processors and in Track, as we have
to consider a larger collection of notes and samples at each step.
There's some cautionary TODOs in the currently unused LibDSP tracks
because they don't do things properly yet.
|
|
This is what the old Transport in Piano had, but as everyone just
references Transport directly, there's no need for it anymore.
|
|
This was a leftover from the early days of Piano, and there's no reason
to leave it that way especially if we want to use more complex
collection APIs in the future.
|
|
|
|
* Don't inherit from Core::Object everywhere, that's overkill. Use
RefCounted instead.
* Change some constructor visibilites to facilitate the above.
* default-implement all virtual destructors if possible.
* Drive-by include hygiene.
|
|
Previously requestAnimationFrame() callbacks were registered with a
static global RequestAnimationFrameDriver shared between all windows.
This led to callbacks still running after navigating away from a page
(This could be seen with the WASM GoL demo).
This commit moves the RequestAnimationFrameDriver (now
AnimationFrameCallbackDriver) to be a member of the HTML::Window
object, then uses the 'active document' parameter of
run_animation_frame_callbacks() to run only the active callbacks.
|
|
This fixes the faulty bit check that misclassified ZIPs as having
data descriptors.
|
|
|
|
|
|
|
|
|
|
Most of the string.h and wchar.h functions are implemented quite naively
at the moment, and GCC's pattern recognition pass might realize what we
are trying to do, and transform them into libcalls. This is usually a
useful optimization, but not when we're implementing the functions
themselves :^)
Relevant discussion from the GCC Bugzilla:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102725
This prevents the infamous recursive `strlen`.
A more proper fix would be writing these functions in assembly. That
would likely give a small performance boost as well ;)
|
|
The compiler would complain about `__builtin_memcpy` in ByteBuffer::copy
writing out of bounds, as it isn't able to deduce the invariant that the
inline buffer is only used when the requested size is smaller than the
inline capacity.
The other change is more bizarre. If the destructor's declaration
exists, gcc complains about a `delete` operation causing an
out-of-bounds array access.
error: array subscript 'DHCPv4Client::__as_base [0]' is partly outside
array bounds of 'unsigned char [8]' [-Werror=array-bounds]
14 | ~DHCPv4Client() = default;
| ^
This looks like a compiler bug, and I'll report it if I find a suitable
reduced reproducer.
|
|
I'm not even sure why this worked. How would the compiler know which
type to destruct the FilterInfo object as?
Fixes this janky error from gcc 12:
AK/RefCounted.h:70:13: error: array subscript 0 is outside array bounds
of 'void [56]' [-Werror=array-bounds]
70 | delete static_cast<const T*>(this);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
|
|
|
|
|
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
bec2b3086c195e50f233e01f7ab935ba15ac843e. 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.
|
