Every tool that has a slider now registers the primary/secondary
sliders and now uses the same keyboard shortcuts to modify the
primary and secondary properties. `[` and `]` for the primary,
`{` and `}` for the secondary.
There are quite a few tools that might want to change certain values
based on consistent keyboard shortcuts. This commit allows tools to
hook up a "primary" and "secondary" slider with the base `Tool`
class, which can then handle updating those sliders with the common
shortcuts.
Note that any derived classes that want to override the `on_keydown`
function will manually need to call `Tool::on_keydown()`.
This new class will open and parse files (either images directly or .pp
project files) and one can get the parsed Image as well as other
information from it.
This patch removes a bunch of 'try_create_from..." methods from Image in
favor of using the ProjectLoader.
The only json_metadata that is available are Guides for now.
The ImageEditor knows more about the image than Image itself. So to save
a project with all the information known to the program about an image
it's logical that ImageEditor performs that task rather than the Image.
There isn't any additional data added yet, but now there's the
possibility to do so.
Our existing implementation did not check the element type of the other
pointer in the constructors and move assignment operators. This meant
that some operations that would require explicit casting on raw pointers
were done implicitly, such as:
- downcasting a base class to a derived class (e.g. `Kernel::Inode` =>
`Kernel::ProcFSDirectoryInode` in Kernel/ProcFS.cpp),
- casting to an unrelated type (e.g. `Promise<bool>` => `Promise<Empty>`
in LibIMAP/Client.cpp)
This, of course, allows gross violations of the type system, and makes
the need to type-check less obvious before downcasting. Luckily, while
adding the `static_ptr_cast`s, only two truly incorrect usages were
found; in the other instances, our casts just needed to be made
explicit.
And also try_create<T> => try_make_ref_counted<T>.
A global "create" was a bit much. The new name matches make<T> better,
which we've used for making single-owner objects since forever.
This also required adding a new hook to `ImageClient`, since there
wasn't a way of telling the ImageEditor that the full rect of the
image has changed (as when we rotate).
If we don't have enough layers to be able to scroll, the layers
are pushed to be at the top of the layer list. This doesn't make
much sense now that we are correctly drawing the layers in the
right order, so now we draw them justified towards the bottom.
Previously we were also clipping the bottom gadget slightly when
there were enough layers to scroll. Now, I'm adding some offset to
the total height to account for this and give equivalent spacing
from the top and bottom layers.
Previously the background layer was shown at the top, and layers
in front of it were shown below it. This was really unintuitive.
This patch fixes LayerListWidget to now properly differentiate
between the index of a gadget, and the index of a layer, since they
are essentially mirrored. I chose not to modify the order in which
layers are stored since back-to-front makes it really convenient
there.
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.
