| Age | Commit message (Collapse) | Author |
|---|
|
|
|
You can now pass --gui-focus-debug to any GUI::Application and it will
draw a cyan rectangle around the currently focused widget.
|
|
|
|
Before notifying our window that a child was removed, we should first
check that we actually have a window! :^)
|
|
|
|
Instead of a solid color, we now paint the track/gutter of scrollbars
using a 2-color dither pattern for a pleasant millennium feel. :^)
|
|
|
|
It didn't feel right to have a "DHCPClient" in a "Servers" directory.
Rename this to Services to better reflect the type of programs we'll
be putting in there.
|
|
This is consistent what we do for regular Buttons and gives a pleasant
visual cue when you're over a clickable area.
|
|
This simplifies building composite widgets by not having to worry about
updating widget subtrees.
|
|
|
|
In the TreeView, the background of the selected line (or any background,
really) was only drawn until the frame's width. When the text was larger
than the frame's width, this caused the end of the text to be displayed
without background, making it unreadable if it was white (which is the
default text color for selected lines).
To compute the background width, we have a choice between :
- The inner frame width (the current behaviour which causes the issue)
- The total width of all columns (which causes the background to end
early if the columns don't cover the full width)
The new algorithm uses the biggest of the above values, which gives us
exactly what we want in all cases :^)
Fixes #2134
|
|
|
|
StringView::to_string() was added in 917ccb1 but not actually used
anywhere yet.
|
|
|
|
|
|
|
|
Adds fully functioning template literals. Because template literals
contain expressions, most of the work has to be done in the Lexer rather
than the Parser. And because of the complexity of template literals
(expressions, nesting, escapes, etc), the Lexer needs to have some
template-related state.
When entering a new template literal, a TemplateLiteralStart token is
emitted. When inside a literal, all text will be parsed up until a '${'
or '`' (or EOF, but that's a syntax error) is seen, and then a
TemplateLiteralExprStart token is emitted. At this point, the Lexer
proceeds as normal, however it keeps track of the number of opening
and closing curly braces it has seen in order to determine the close
of the expression. Once it finds a matching curly brace for the '${',
a TemplateLiteralExprEnd token is emitted and the state is updated
accordingly.
When the Lexer is inside of a template literal, but not an expression,
and sees a '`', this must be the closing grave: a TemplateLiteralEnd
token is emitted.
The state required to correctly parse template strings consists of a
vector (for nesting) of two pieces of information: whether or not we
are in a template expression (as opposed to a template string); and
the count of the number of unmatched open curly braces we have seen
(only applicable if the Lexer is currently in a template expression).
TODO: Add support for template literal newlines in the JS REPL (this will
cause a syntax error currently):
> `foo
> bar`
'foo
bar'
|
|
We'll call the "Back" and "Forward" since that's what they are normally
mapped to in some other systems.
|
|
I just spotted this while I saw you writing this code :-)
|
|
Well, technically the initial sort order is 'ascending inode'.
However, that is unpredictable for the user.
In the rare case it is desired, it can be re-enabled by revealing the
inode column, and then sorting by it, in the TableView.
|
|
This was most notable in the widgets TextBox and TextEditor (and
therefore also ComboBox and ColorInput), because there the cursor
regularly landed just one pixel outside the visible region when
going to the right.
|
|
|
|
|
|
|
|
|
|
Until now, hidden columns were displayed as visible in the context menu.
An easy way to reproduce this is:
- Open the TextEditor
- Ctrl-O to open the file selector
- Switch to table view
- Right-click the header
Expected behavior:
Hidden columns like 'Owner' and 'Group' should not have a checkmark,
because they are hidden.
Actual behavior: They did have a checkmark. Clicking on it to 'hide'
the already hidden column removed the checkmark, but was a no-op to the
table view.
This commit fixes this behavior, by correctly initializing the context menu,
and properly updating the context menu if external code calls
'set_column_hidden' later.
|
|
|
|
Frameless windows don't need to show up in the taskbar or the switcher.
|
|
|
|
If a window has child windows when it's destroyed, WindowServer will
now automatically tear down all of its children as well.
This is communicated to the client program through a vector of window
ID's included with the response to WindowServer::DestroyWindow.
This does feel a little bit awkward, but managing it on the client side
also seems a bit awkward.
|
|
This is much better than the hack we had of making them Tooltip windows
since frameless windows end up at the right layer in the window stack
automatically, and always get yanked above the parent window simply by
being child windows.
|
|
This allows you to create windows with no title bar or window frame.
|
|
Nobody was using this flag, so let's stop maintaining it. It's easy to
add it back if we ever want the behavior.
|
|
If a window has another window in its Core::Object ancestor chain,
we now communicate that relationship to WindowServer so that it can
act with awareness of parent/child windows.
|
|
|
|
|
|
|
|
|
|
In TabWidgets with the "uniform tabs" mode on, we will now scale tabs
between a minimum and maximum size, distributing the available space.
Partially addresses #1971.
|
|
Fixes #2022.
|
|
|
|
|
|
This looks a lot nicer than just a plain widget. :^)
|
|
It's not always safe to access pixel data of a window's backing store
since the kernel may decide to purge it at his leisure. Fix this by
instead picking colors from the color spectrum bitmap directly instead.
Also fix up mouse event logic while we're here so it only cares about
the left mouse button
Fixes #1657.
|
|
It feels natural that if I double click a color button, the dialog
closes successfully and "returns" that color.
|
|
We never deliver mouse events to disabled widgets, so there's no need
to check is_enabled() in these event handlers.
|
|
Let's not open the ColorPicker on mousedown, that was too jarring.
|
|
|
|
|
