First, this patch renames the function
`propagate_shortcuts_up_to_application` to `propagate_shortcuts`.
Handling those levels, will allow us to differentiate shortcuts at
`Window` level and `Application` level. Which will be convenient to
handle dialog-specific shortcuts.
A 1px drop shadow from the track was peeking out behind the knob when
at rightmost or lowest position. That made it look like it was possible
to drag the knob even further right or down. Painting the track 1px
shorter seems like a good compromise to avoid the problem.
When clicking the value slider bar, the knob was not positioned as
close to the mouse as expected. When moving the mouse right, the knob
would lag a bit behind, and the cursor would eventually be outside the
knob.
The bug was due to knob_rect() taking knob_thickness into account to
prevent the knob from protruding outside the bar. The value_at(pos)
calculated the relative position based on the entire width of the bar.
This discrepancy is fixed by taking knob_thickness into account in
value_at(position).
When dragging value slider left, the handle would snap to lower value
with the slightest move of the mouse. When dragging to the right
however, it would take a lot more movement to cause a change in value.
This asymmetry made it feel awkward to drag the mouse around. It was
caused by always rounding down using a cast to int. By rounding to the
nearest integer first, we ensure symmetric behavior.
When dragging the slider handle left/down, the handle would
snap to lower value with the slightest move of the mouse. When dragging
to the right/up however, it would take a lot more movement to cause
a change in value. This asymmetry made it feel really awkward to drag
the slider. It was caused by always rounding down using a cast to int.
By rounding to the nearest integer first, we ensure symmetric behavior.
As the user might want to have interactions with LibGUI while handling
errors, this code should be executed in the original `EventLoop`.
Similarly to what is done with the error-free path.
I had to add a set_title(String) helper function for ImageEditor because
TabWidget requires it. This is a temporary fix and will be handled in
subsequent commit.
Rather than creating a TextStyle struct, and then copying its fields
over to a TextAttributes, let's just create a TextAttributes to start
with. This also simplifies the syntax highlighting code by letting us
define underlines along with the other text styling.
Similar to POSIX read, the basic read and write functions of AK::Stream
do not have a lower limit of how much data they read or write (apart
from "none at all").
Rename the functions to "read some [data]" and "write some [data]" (with
"data" being omitted, since everything here is reading and writing data)
to make them sufficiently distinct from the functions that ensure to
use the entire buffer (which should be the go-to function for most
usages).
No functional changes, just a lot of new FIXMEs.
With the new canceled background actions, some thumbnail generation
callbacks are not executed if the user closes the window with a
FileSystemModel quickly enough. Therefore, we remember which thumbnails
we started to generate and consider the associated promises if we're
looking up a thumbnail. Since the thumbnail generation itself continues
running and the cache is application-global, instead of never displaying
thumbnails for images that were "interrupted" generating thumbnails the
first time, we can now fetch their images immediately and reliably.
This class had slightly confusing semantics and the added weirdness
doesn't seem worth it just so we can say "." instead of "->" when
iterating over a vector of NNRPs.
This patch replaces NonnullRefPtrVector<T> with Vector<NNRP<T>>.
This also removes DirIterator::error_string(), since the same strerror()
string will be included when you print the Error itself. Except in `ls`
which is still using fprintf() for now.
This widget originally used text, but at the time we did not support
painting multi-code point emoji as text at all. So it was changed to
paint emoji with their bitmaps in commit 8190120f95.
Now that we can paint text with multi-code point emoji, revert this
widget to use text again. This has the added benefit that the dialog has
a what-you-see-is-what-you-get effect; any emoji with text presentation
in the font (e.g. U+00A9 Copyright) will be displayed as such in the
dialog, which is how the text would be painted when selected anyways.
Note that to accommodate some emoji sizes, this also had to bump the
button sizes a bit, otherwise they would be displayed with an ellipsis.
The EmojiInputDialog, for example, will want its toolbar buttons to have
a tooltip which differs from its text. If no tooltip override has been
provided, we fall back to the button text still.
For vector fonts in particular, we need to take care to compute offsets
using floating point math. For example, with Berkeley Mono at font size
16, with syntax highlighting enabled, we are currently truncating these
offsets to integers. This results in a leftward-drift when we paint the
text.
This changes the rect in which we paint syntax-highlighted text spans to
a float rect. As we traverse the spans, we now no longer truncate any of
the text offsets, and we draw the text in the correct positions.
This is likely not a complete solution. TextEditor blindly casts ints to
floats all over, and we will want to make all of these (hundred+) float-
aware. But this should be a step in the right direction and makes vector
fonts immediately more comfortable to use.
