We now suggest classes even if the line does not start with an @.
After all, we now have fuzzy matching, so why *shouldn't* "color"
match @GUI::ColorInput as well as background_color?
A lot of the code in this area is duplicated, which is not great. In
fact this also fixes a bug where suggested partially matched props
would include read-only properties, since that check had only been
added to one of the two loops.
Previously this section of code would blindly add *anything* as a child
as long as it has been registered as an object. Since there is no
guarentee that those objects are, in fact, Widgets, this feels like a
logical fallacy.
For example, up until this change, this is perfectly valid GML:
```
@GUI::Widget {
layout: @GUI::VerticalBoxLayout {
}
@GUI::VerticalBoxLayout {
}
}
```
What exactly does it do? Who knows! It doesn't seem to *break*, but I
think we can all agree it shouldn't be valid.
Instead, we now actually verify that the registered class inherets from
GUI::Widget before adding it as a child. We also error if it's not,
which should hopefully help new GML writers from forgetting to write
'layout: ' before the layout definition and being confused as to why
it's not working.
There are only two layouts at the moment, but that could (and probably
will) change in the future. Why limit ourselves by hardcoding these
checks when we can do it dynamically instead?
This check was removed as it will now never trigger.
The completion has the suffix ': ' on it, and the key does not.
Therefore if the user has not yet typed the ':', it will not be equal,
and after they do the check on line 167 will fail so the entry won't be
in the list to begin with.
Previously we had a special case in order to auto-append quotes or
angle brackets to #include statements. After the previous commit this
is no longer necessary.
There are times when it is nice to display one suggestion but fill
something different. This lays the groundwork for allowing
GMLAutocompleteProvider to automatically add ': ' to the end of
suggested properties, while keeping the ': ' suffix from cluttering up
the suggestion UI.
The previous commit fixed the issue with layout classes not being
suggested at all, but there was still another issue. Once you started
typing the class name a different suggester would take over and only
show widgets. This commit makes it so it still only suggests layouts
in that situation.
This, combined with the last commit, makes autocompleting layouts way
more discoverable and user-friendly. :^)
Previously when the GMLAutocompleteProvider was invoked just after the
'layout:' tag it would suggest nothing. This is because Layouts do not
inherit from Widget, so the two checks would always eliminate every
suggestion from the list. This patch makes it always suggest any
(registered) object that inherits from GUI::Layout.
This should make layouts more discoverable and easier to quickly use.
This patch removes a hack that forced any pending repaints to happen
immediately whenever you moved the mouse over a window.
The purpose of that mechanism was to ensure that quick button presses
still show up visually, and since that is now accomplished via
Widget::repaint(), we no longer need this.
This ensures that rapidly clicking a button doesn't look like it's
"swallowing" some of the mouse events.
This already worked okay due to a hack in Window, but this will allow us
to get rid of that hack.
In most situations, Widget::update() is preferable, since that allows us
to coalesce repaints and avoid redundant work, reducing system load.
However, there are some cases where you really want a paint to happen
right away, to make sure that the user has a chance to see a short-lived
visual state.
Before this change, using the Tab key would cycle through all the
individual buttons in an exclusive group (e.g radio buttons.)
This felt wrong, since a group of exclusive buttons is really a single
logical input with a limited number of possible choices.
This patch makes such groups behave as a single focusable unit instead,
by dynamically updating the focus policies so that only the currently
checked button is focusable.
We also allow keyboard navigation within the button group via the arrow
keys. This had to be specialized in GUI::AbstractButton, since the
default behavior of arrow keys is to traverse the focus chain.
Showing the selection in non-focused text editors was not really useful,
since refocusing the widget would clear or change the selection
immediately anyway.
Note that TextEditors in inactive windows can still be the focused
widget within that window, and will still be painted with an "inactive"
looking selection.
The FilePicker has implemented its common locations tray as a composite
widget built from a GUI::Frame with a bunch of GUI::Button inside it.
The problem with that is that it creates a long and annoying chain of
keyboard-focusable widgets.
This patch adds GUI::Tray, which is a dedicated single widget that
implements the same UI element, but without child widgets.
Toolbar buttons are meant for quick mouse access to common actions,
while quick keyboard access is normally achieved via keyboard shortcuts
and underlined menu items.
This makes interfaces with many toolbar buttons (e.g GUI::FilePicker)
a lot nicer to navigate via keyboard.
Previously, you could get crashes when you tried to search for a font
size in the Font Picker or a screen resolution in Display Settings.
This is because their list models aren't made of strings
and Variant::as_string() only accepts strings.
d0fb511d75 set the maximized window value
in the File Manager before a window was created, which resulted in crash
everytime you tried to open the program that was closed while it was
maximized. ugh
Here we do more-or-less what GUI::Window::set_rect() does, except we
don't add it to the WindowServer::create_window() IPC call.
That's because the Window Server knows nothing about menus at this
point and just assumes they don't need to be visible.
So if we try to maximize the window then, it could be slightly taller
and a titlebar could be hidden.
So even though it looks how it looks like, it does work and it doesn't
show in the startup size, as described in the mentioned commit (the call
is put a few lines before the initial update()). :^)
There used to be the silly bug that when the cursor was already at the
end of a span (e.g. because the user just pressed Ctrl-Right), then
Ctrl-Right had no effect.
This bug does not appear with Ctrl-Left because due to the order in
which the spans are iterated, the effective result is always correct.
This patch also makes it more apparent that the algorithm is
unnecessarily inefficient.
Previously, the initial call to update_selection() was missing, so if no
text was already selected, then Ctrl-Shift-End would only move the
cursor to the document end, but not select any text.
