Previously there was a situation where the autocomplete box would
appear to "jump" to the side. This was due to the following race
condition:
1. Start typing, thus triggering the autocomplete timer to start
2. Manually trigger autocomplete before the timer finishes
3. Continue typing
4. The autocomplete timer now fires
When the timer fires it causes the autocomplete box to show, which, if
it is already shown, has the effect of moving the box to the current
cursor position.
Previously the autocomplete box would always close after applying a
suggestion. This is the desired behavior in almost all cases, but there
are some situations (like autocompleting paths) where it would be nicer
to keep the autocomplete box open after applying the suggestion.
Moving the cursor to a different location, by any means, should
dismiss the autocomplete popup. This is the behavior of virtually
every editor/IDE out there, and it is really annoying (and
confusing) when our autocomplete doesn't behave like that.
Previously if there were no suggestions, we simply wouldn't show the
autocomplete popup at all. This is functional, but when there are no
resultes it does leave the user wondering if it actually worked.
Now, if the user requests autocomplete and we do have requests, it
behaves exactly as before, but if there' aren't any we now show a box
with the message "No suggestions" to show the user that we got the
request, there just isn't anything to suggest.
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.
