This resets the DOM Inspector to a default state when re-opening it,
instead of it displaying the previous selection and properties, which
may be outdated. This is closer to how Chrome and Firefox behave.
Eventually, it probably makes sense to copy their behavior of selecting
the `<body>` element by default.
The direct-Document-access DOMTreeModel is no longer used, since the DOM
Inspector has to access the Document remotely over IPC. This commit
removes it, and renames DOMTreeJSONModel to take its place, since it no
longer has to differentiate itself from the non-JSON one.
In case that didn't make sense:
- Delete DOMTreeModel
- Rename DOMTreeJSONModel -> DOMTreeModel
Also simplify the logic by removing `Tab::view_dom_tree()`, and making
the Tab keep a pointer to the InspectorWidget instead of its Window,
since that's more often what we want to access.
We use TextEditor::on_modified_change() to update the modified window
flag, which it also works on file saves, so we don't have to unset
it there anymore!
It isn't really what the FIXME note asked about -- GUI::TextDocument
only sends us notifications about the changes, but overall I don't
think it's that bad, given that the whole window update logic is now
in one function. :^)
Previously it would only change the color of the ColorWidget itself,
but not make it the primary/secondary color. I think it feels nicer
this way, if I'm adding a color to the palette I likely want to use
it.
If you *really* need to only change the color of the palette, you
can just Ctrl+Middle click.
Previously, if you wanted to use a custom color, the only way to
do so was to first Ctrl+click on one of the pallette colors, which
would just change that palette item. Then, you would need to
manually click on that color.
Now, you can just click on the preview of the primary/secondary
color to open up the picker and only temporarily use the new color
without affecting the palette at all.
Only one place used this argument and it was to hold on to a strong ref
for the object. Since we already do that now, there's no need to keep
this argument around since this can be easily captured.
This commit contains no changes.
Without this, any resize of the GLContextWidget might leave the label
somewhere it shouldn't be. Toggling fullscreen is a single example of
that behavior.
The breadcrumbbar in here serves exactly the same purpose as the one in
File Manager. Given that, I believe it's worth to keep these two
visually consistent.
Removed the old custom checkbox selection code in the Visualization
menu and replaced them with GUI::ActionGroup with set_exclusive
enabled instead :^)
This way we can feed it the values if we wanted to change an existing
Guide and handle the default as before.
That we have to pass a String here is a bit ugly.
The height of the bottom color container was cut off at the bottom.
This adjusts the heights and also the primary/secondary color
widget so that it's in line.
Add a new Color category to the Filter menu. Add the Grayscale
filter under Filter->Color to turn the selected layer to grey colors.
Created GrayscaleFilter.h. Modify Filter.h to allow filters
without parameters.
The prior commits add the `DrawMode` enum to keep track of where
the shape is being drawn from. With this addition, the prior `Mode`
enum name is confusing, so this commit renames it to `FillMode` to
be more explicit :^)
Essentially the same logic as the prior commit, but now for the
`RectangleTool` class. Pressing `alt` lets you draw the rectangle
with the starting position as the center.
Like other common image editing applications, now if you press
`alt` while drawing an ellipse, it uses the starting position as
the center of the ellipse as opposed to one of the corners of the
bounding rect.
The EllipseTool class now keeps track of a `DrawMode`, which is
either `DrawMode::FromCorner` (default), or `DrawMode::FromCenter`
(the option added by this commit).
The `draw_using()` function was modified to now take in the start
and end positions and construct the `ellipse_intersecting_rect`
itself, since we need to construct it differently based on the
drawing mode.
This change removes the manually created model class
in order to use a generic GUI::ItemListModel.
Besides from code reusability, it also makes the list
searchable as you type.
This is the first step in transitioning Piano to a full LibDSP backend.
For now, the delay effect is replaced with a (mostly identical)
implementation in LibDSP.
The new ProcessorParameterSlider attaches to a LibDSP::Processor's
range parameter (LibDSP::ProcessorRangeParameter) and changes it
automatically. It also has the ability to update an external GUI::Label.
This is used for the three delay parameters and it will become useful
for auto-generating UI for Processors.
As Piano will later move to the RollNote defintions of LibDSP, it's a
good idea to already insert velocity and pitch support, even though it's
currently not used.
The default action (shown in bold) indicates what would you get
by double-clicking on file. Since it's a default option, I think it
deserves to be on top (together with alternative launch options). :^)
Also they're not task actions like "Extract .zip here" or "Add to
bookmarks".
No previous model index will be invalidated afterwards, so avoid
invalidating them.
Also fixes an issue where committing to an edit with the inline cell
editor makes the focused cell switch to A0.
Fixes#9677.
