Previously the text would be up close to the left / right border
depending on the alignment.
This patch increases the padding on either side from one to four pixels.
The color slider on the ColorPicker widget's "Custom Color" page will
now update when changing the color with the individual channel
spinboxes and the larger color field box.
Fixes#14425
This prevents us from needing a sv suffix, and potentially reduces the
need to run generic code for a single character (as contains,
starts_with, ends_with etc. for a char will be just a length and
equality check).
No functional changes.
Each of these strings would previously rely on StringView's char const*
constructor overload, which would call __builtin_strlen on the string.
Since we now have operator ""sv, we can replace these with much simpler
versions. This opens the door to being able to remove
StringView(char const*).
No functional changes.
Error::from_string_literal now takes direct char const*s, while
Error::from_string_view does what Error::from_string_literal used to do:
taking StringViews. This change will remove the need to insert `sv`
after error strings when returning string literal errors once
StringView(char const*) is removed.
No functional changes.
This commit moves the length calculations out to be directly on the
StringView users. This is an important step towards the goal of removing
StringView(char const*), as it moves the responsibility of calculating
the size of the string to the user of the StringView (which will prevent
naive uses causing OOB access).
These are mostly minor mistakes I've encountered while working on the
removal of StringView(char const*). The usage of builder.put_string over
Format<FormatString>::format is preferrable as it will avoid the
indirection altogether when there's no formatting to be done. Similarly,
there is no need to do format(builder, "{}", number) when
builder.put_u64(number) works equally well.
Additionally a few Strings where only constant strings were used are
replaced with StringViews.
Since 00f51d42d2aeb44ec4813ca13be787c2f5ca55ff we would not allow the
deletion for a selection by typing if it would match the conditions to
indent on pressing tab.
As any single line TextEditor would always match the indent conditions,
it was impossible to replace selected text by typing in a TextBox,
PasswordBox or UrlBox.
A missing return, as pointed out in https://github.com/SerenityOS/serenity/pull/13269#discussion_r900866416
was the cause for the additional checks in
TextEditor::insert_at_cursor_or_replace_selection, described in https://github.com/SerenityOS/serenity/pull/13269#discussion_r901009457
With the early return in place the additional checks are not aiding with
the indented behavior but cause the regression described above.
This patch removes the unnecessary conditions.
If selected text is less than a whole line, usual delete/replace takes
place. Otherwise, if the selected text is a whole line or spans
multiple lines, the selection will be indented.
The new min_content_size value is to be set by the subclasses, it is
then used to determine if the scrollbars should be shown after a
resize, but before the content size will be calculated by the following
layout pass.
This function is intended to propagate layout changes upwards in the
widget hierarchy. Widgets that can know what to do with this
information without causing a full layout invalidation (i.e. just
because one of their child widgets changed layout/size, doesn't
necessairily mean that they have to change their layout/size) can
override this and prevent a full relayout and redraw.
The default size for label is always a compromise, no matter what value
is chosen, some layouts will require local manual overrides.
Having the preferred size be opportunistic_grow in both directions seems
like it's currently the option that works without modification in most
cases.
Before this, the spacers were handled as just another child widget, and
as such could take away space from real widgets when growing.
This also fixes the problem of effectively 0 sized spacers, that doubled
the spacing between the widgets they were placed between.
Effective sizes are the ones that are actually to be used for layout.
They are just their respective propertys value, or the value returned
by the calculated_<min/preferred>_size, when the respective property
is set to shrink or fit.
The "calculated" values in turn are specific to the widget. Container
widgets for example can calculate their values depending on their
layout and child widget requirement.
Simple widgets like labels and buttons can for example calculate their
values based upon their current text.
