Previously the widget used a very rough estimate for visible glyphs
based on viewport and glyph areas. Now it simply figures rows times
columns with a two row overdraw to accommodate fractional glyphs
on either end of visible content. For KaticaRegular10, this ends up
reducing unnecessary glyph iterations during painting by about 30%.
Fixes a slightly oversized content rect and erroneous glyph outer
rect values. Increases glyph rect padding to guarantee at least 1px
between the focus rect and glyph.
Fixes crashing on invalid code points when creating selections
with the keyboard and applying actions to them.
Also adds Home/End key support for selections. Ctrl+Shift+{Home,End}
now extends the selection to the beginning or end of the active range,
respectively. Shift+{Home,End} extends the selection to the start or
end of the row. Alt+{Home,End} resets the selection and moves the
active glyph to the beginning or end of the active range.
Previously selection reset was ignored on active glyph change if the
old glyph equaled the new one. This was an intentional behavior that
allowed selections to resize by dragging the focused glyph, but has
proved more counterintuitive than useful.
Now the widget behaves like other text selection controls: selections
can be reset by clicking anywhere in them or shift can be held to
grow the selection.
This is a bogus size as the map must always have at least 1 glyph
selected, and it was causing occasional desync between selection
contents and the focused glyph when manipulating selections with
the keyboard.
This just corrects an oversight in EditingEngine where we do not
properly signal "we handled this event" for Key_Up and Key_Down like we
do for the other keys
This patch adds a new add_tab() function in GUI::TabWidget that takes
an already created NonnullRefPtr<Widget> object. This allows us to
handle errors while creating the Tab object and then pass it to this
function to actually add the object to the TabWidget.
This patch adds a new add_tab() function in GUI::SettingsWindow that
takes an already created NonnullRefPtr<Tab> object. This allows us to
handle errors while creating the Tab object and then pass it to this
function to actually add the object to the SettingsWindow.
This patch allows returning an `Error` from the `on_complete` callback
in `BackgroundAction`.
It also adds a custom callback to manage errors returned during its
execution.
This patch introduces error propagation to Gfx::SystemTheme to remove
instances of release_value_but_fixme_should_propagate_errors().
Userland applications that have been affected by this change have been
updated to utilise this propagation and as a result 4 such instances of
the aforementioned method have been removed.
Note that this still keeps the old behaviour of putting things in std by
default on serenity so the tools can be happy, but if USING_AK_GLOBALLY
is unset, AK behaves like a good citizen and doesn't try to put things
in the ::std namespace.
std::nothrow_t and its friends get to stay because I'm being told that
compilers assume things about them and I can't yeet them into a
different namespace...for now.
This adds shortcut for inserting a new empty indented line
above/below current cursor position.
- <Ctrl-Return> for inserting line below.
- <Ctrl-Shift-Return> for inserting line above.
This patch adds a visibility state to GUI::Action. All actions default
to being visible. When invisible, they do not show up in toolbars on
menus (and importantly, they don't occupy any space).
This can be used to hide/show context-sensitive actions dynamically
without rebuilding menus and toolbars.
Thanks to Tim Slater for assuming that action visibility was a thing,
which gave me a reason to implement it! :^)
When you select a text area in "bottom-up" way (e.g. from line 10
to line 5), then type the shortcut, the text editor will not
comment those text for you.
Normalize the text range can easily fix this minor bug.
The getters passed to REGISTER_STRING_PROPERTY are never invoked. But if
they were, they would errantly incur an implicit pointer-to-boolean cast
when their return type (Gfx::Bitmap*) is used to construct a JsonValue.
Widget's name are the current way to retrieve them when using GML.
Presently, there is no way to differentiate two items that share the
same name.
`IncrementalSearchBanner` uses common names as "close_button" or
"next_button", prepend them with `incremental_search_banner_` avoid
collisions.
This fixes a bug where the close button of `CrashReporter` was confused
with the one of the search banner.
However, This solution isn't perfect, down the road, we should probably
find a way to warn about equal names and introduce something like
namespace to avoid huge prefixes.
This will make it easier to support both string types at the same time
while we convert code, and tracking down remaining uses.
One big exception is Value::to_string() in LibJS, where the name is
dictated by the ToString AO.
We have a new, improved string type coming up in AK (OOM aware, no null
state), and while it's going to use UTF-8, the name UTF8String is a
mouthful - so let's free up the String name by renaming the existing
class.
Making the old one have an annoying name will hopefully also help with
quick adoption :^)
Compared to traditional modal search, incremental search begins
matching as soon as the user starts typing, highlighting results
immediately. This refactors Itamar's work for HackStudio into a
common LibGUI widget to be used in all multi-line TextEditors.
Banners are abstract widgets which can house additional controls
and information on a temporary basis, popping in from the top of
their parent when needed.
Some buttons control how their text is set in unique ways. For example,
GUI::ToolbarButton will set only its tooltip instead of its text if it
has an icon. So when the text changes, ToolbarButton will want to change
its tooltip instead.
This reverts commit e20756f9f7.
Some buttons, e.g. GUI::ToolbarButton, set text to be used only as a
tooltip instead of text on the button itself. This commit forced those
buttons to have text on them when their action became set. For most
toolbars, this was an invisible side effect; the button icons covered
the whole button rect. But the toolbar for EmojiInputDialog has slightly
smaller icons, causing an ellipsis to be displayed next to the icon.
