This now shows the shortcut to enable mouse pointer highlighting below
the preview. The GML has also been updated to take advantage of the new
layout features rather than using fixed heights.
Previously we would always select the left most column when selecting a
range of rows.
This patch fixes this issue by always applying a selection to the column
in which the selection ends.
AbstractView currently assumes a certain layout of rows and colums to
perform a range selection on.
This patch moves the implementation into a helper that can be overriden
by other views.
We should actually start counting from the parent directory and not from
the symbolic link as it will represent a wrong count of hops from the
actual mountpoint.
The symlinks in /sys/dev/block and /sys/dev/char worked only by luck,
because I have set it to the wrong parent directory which is the
/sys/dev directory, so with the symlink it was 3 hops to /sys, together
with the root directory, therefore, everything seemed to work.
Now that the device symlinks in /sys/dev/block and /sys/dev/char are set
to the right parent directory and we start measure hops from root
directory with the parent directory of a symlink, everything seem to
work correctly now.
All of these conditions should make du just not report the file size
individually, but it should still count them into the grand total.
In the case of the `--threshold` option, this was actually implemented
incorrectly before, as it would report size 0 for files that did not
match the threshold.
We may very well dip into files larger than 4G at some point, so 32-bit
values are not enough, and the 64-bit sized `off_t` doesn't fully make
sense either, as it features negative values.
Instead, switch to the explicit type of `u64` everywhere, which is the
same size on all platforms and is unsigned. The exception to this is
the threshold, which needs to be signed instead of unsigned.
The `--max-depth` option only controls until which depth individual file
sizes are printed, it does not stop the utility from traversing that
branch further (as the file sizes would be wrong otherwise).
Restructure the program to track the current depth, and return early if
the current depth is higher than the maximum allowed depth, which skips
all parts of the logic that are concerned with user output.
This makes them look a bit more like a progress bar, especially
on white backgrounds (for the default theme) where you otherwise
cannot see the unfilled part of the bar.
Now that the infrastructure of the Graphics subsystem is quite stable,
it is time to try to fix a long-standing problem, which is the lack of
locking on display connector devices. Reading and writing from multiple
processes to a framebuffer controlled by the display connector is not a
huge problem - it could be solved with POSIX locking.
The real problem is some program that will try to do ioctl operations on
a display connector without the WindowServer being aware of that which
can lead to very bad situations, for example - assuming a framebuffer is
encoded at a known resolution and certain display timings, but another
process changed the ModeSetting of the display connector, leading to
inconsistency on the properties of the current ModeSetting.
To solve this, there's a new "master" ioctl to take "ownership" and
another one to release that ownership of a display connector device. To
ensure we will not hold a Process object forever just because it has an
ownership over a display connector, we hold it with a weak reference,
and if the process is gone, someone else can take an ownership.
This header file represents the entire interface between the kernel and
userland, and as such, no longer should be called FB.h but something
that represents the whole graphics subsystem.
This style is the same as what is used in WebKit/Blink, it is a bit
ugly, but you're expected to override it. Adding more than a
background color here could cause some issues, as sites don't
expect to have to unset the styles.
This disables this system progress bar, and instead creates one
out of pseudo elements, that can be selected and styled with the
::-webkit-progress-bar/value selectors.
These will be needed for styling progress bars, sadly this can
only be done with these non-standard selectors. These are, hovever,
in use on real sites such as https://rpcs3.net/compatibility.
This isn't called out in TR-35, but before ICU even looks at CLDR data,
it adds a hard-coded set of default patterns to each locale's calendar.
It has done this since 2006 when its DateTimeFormat feature was first
created. Several test262 tests depend on this, which under ECMA-402,
falls into "implementation defined" behavior. For compatibility, we
can do the same in LibUnicode.
This is a minor refactor of XHR::extract_body() letting it return
ErrorOr<...> instead of just Fetch::Infrastructure::BodyWithType.
This also updates the one place extract_body() is used.
This is a minor refactor of IDL::get_buffer_source_copy() letting it
return ErrorOr<ByteBuffer> instead of Optional<ByteBuffer>.
This also updates all places that use IDL::get_buffer_source_copy().
This patch implements man pages opened using the help url protocol
properly getting added to the navigation history as well as enabling
the back and forward buttons in such cases.
This patch makes the picker applet react instantly to a click on a
workspace or scroll on the widget, instead of waiting for an event from
WindowServer and as such until the switching animation has ended. This
synchronises the switching with the overlay shown.
Note that WindowServer events will still get handled in case the
workspace were to be updated from somewhere else.
The audio enqueuer thread goes to sleep when there is no more audio data
present, and through normal Core::EventLoop events it can be woken up.
However, that waking up only happens when the thread is not currently
running, so that the wake-up events don't queue up and cause weirdness.
The atomic variable responsible for keeping track of whether the thread
is active can lead to a racy deadlock however, where the audio enqueuer
thread will never wake up again despite there being audio data to
enqueue. Consider this scenario:
- Main thread calls into async_enqueue. It detects that according to the
atomic variable, the other thread is still running, skipping the event
queue wake.
- Enqueuer thread has just finished playing the last chunk of audio and
detects that there is no audio left. It enters the if block with the
dbgln "Reached end of provided audio data..."
- Main thread enqueues audio, making the user sample queue non-empty.
- Enqueuer thread does not check this condition again, instead setting
the atomic variable to indicate that it is not running. It exits into
an event loop sleep.
- Main thread exits async_enqueue. The calling audio enqueuing system
(see e.g. Piano, but all of them function similarly) will wait until
the enqueuer thread has played enough samples before async_enqueue is
called again. However, since the enqueuer thread will never play any
audio, this condition is never fulfilled and audio playback deadlocks
This commit fixes that by allowing the event loop to not enqueue an
event that already exists, therefore overloading the audio enqueuer
event loop by at maximum one message in weird situations. We entirely
get rid of the atomic variable and the race condition is prevented.
This will conflict with apps that don't use this thread and it also
creates unnecessary overhead for non-enqueuing clients like AudioApplet.
Use the new Thread is_started info to start the thread only if necessary
(on first call to async_enqueue).
Users can now determine whether a thread has been started or not. A
started thread might also have already terminated.
Implementation note: We *could* detect this with pthread APIs maybe, but
this is much simpler.
