If we set selection before the IconView is laid out, it has no size.
So it can't correctly calculate where to scroll. Forcing scroll after
the first resize fixes that.
This makes drawing text with spans a lot faster.
The previous implentation went character by character and then
checked every span whether it contained the current character.
This implentation asumes that the spans are sorted and goes span by
span drawing all the characters contained at once.
Any spans that are out of order will be ignored!
Note: text wrapping is not (yet) supported
The Locator now keeps a cache of the declared symbol in a document.
The language client updates that cache whenever it gets an update from
the language server about declared symbols.
This allows searching for symbol declarations in the Locator, in
addition to file names.
Closes#5478
Having TextRange which is empty doesn't make any sense. So it confuses
the functions that rely on having valid range, and causes them to do
no action.
Fixes#5341
This patch provides the basic components needed for developers to create
consistent wizard interface experiences in their applications.
`WizardDialog` provides the dialog frame for the wizard, handling navigation
and presentation.
`AbstractWizardPage`s form the base class of Wizard pages, which are
pushed onto the `WizardDialog` page stack via `WizardDialog::push_page`.
`CoverWizardPage` and `WizardPage` are provided to ease the creation of
Wizard interfaces consistent with the Serenity visual language.
This is basically just for consistency, it's quite strange to see
multiple AK container types next to each other, some with and some
without the namespace prefix - we're 'using AK::Foo;' a lot and should
leverage that. :^)
Rather than invalidating the entire window, which is very expensive on
the transparent desktop widget, just invalidate the areas that actually
need updating.
It's possible that pending invalidation rectangles haven't been
flushed when processing a paint event. Handle them right away,
which avoids another round trip.
In line wrapping mode, the same column refers both to the end of a
visual line and the beginning of the subsequent visual line. This
meant that the cursor couldn't move to the beginning of a visual
line. Now, we only let the cursor go to the end of a physical line,
not the visual line.
Closes#4786
(...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED)
Since all of these checks are done in release builds as well,
let's rename them to VERIFY to prevent confusion, as everyone is
used to assertions being compiled out in release.
We can introduce a new ASSERT macro that is specifically for debug
checks, but I'm doing this wholesale conversion first since we've
accumulated thousands of these already, and it's not immediately
obvious which ones are suitable for ASSERT.
For example, navigating File Manager to a directory that contains a vaild BMP file that
uses a palette, this code would end up trying to create an indexed thumbnail.
However, Painter asserts that the thumbnail that we paint on is *not* indexed,
usually crashing File Manager.
Partially fixes#5299, as it now crashes somewhere else.
Route the ScrollBar's wheel event to the ScrollableWidget so it can
handle it itself. This allows it to handle it consistently (e.g.
speed) when the cursor is hovering the scroll bars rather than the
widget's contents.
Fixes#5419
Fixes hidable horizontal scrollbars remaining visible even after
collapsing their responsible nodes. Tree column width defaults to
column header width if wider than current content.
AbstractView doesn't actually do anything with them anyway, but they
would get swallowed by the cursor logic and not bubble up the widget
parent chain.
This makes the shortcuts actually work since unparented actions are
considered application-global, and we disable application-global
shortcuts while a modal dialog (like FilePicker) is up. This is pretty
counter-intuitive so I think there's room for API improvement here
but let's at least make Alt+Up work in FilePicker for now. :^)
By default, a Window has a minimum size of 50x50 - ComboBox lists aren't
always this tall. We now set the minimum height of the ComboBox Window
according to the height of three items, or the total height of all the
items in the list, whichever is smaller.
This means there is no longer any unpainted space in the list window
due to the shortfall between the ListBox widget and Window heights,
and the ComboBox list window always remains a comfortable height for
viewing. :^)
