Layer::erase_selection used to erase the entire bounding box of the
selection. With the add/subtract merge modes for the selection tool it
is possible to create selections which are not rectangular. This leads
to deleting pixels that were not selected.
This change adjusts the erase behavior to walk the selection rect and
check if a pixel is selected or not before deleting.
Wand Selection tool uses similar logic to the Bucket Tool. Flood filling
and threshold calculations to determine the affected area just in this
case we do not set the pixels of the selected area, instead we use
those pixels to alter the selection mask.
In the future we can probably abstract out the shared flood logic so
both tools can share the code.
Before, the warning dialog would be opened after the NewProjectDialog,
leading to focus-fighting by the two windows. This fixes that and makes
the action more consistent with the standard serenity way of handling
unsaved changes by asking before the NewProjectDialog is brought up.
The way this is achieved avoids having to rewrite open_project as well.
This commit fixes a crash that would occur due to an unnamed file being
automatically saved via EditorWrapper::save(). Now, we throw up a
FilePicker::get_save_filepath.
Specializing point_position_to_preferred_cell for the
RectangleSelectTool as it selects a new cells with a rounding
behavior instead of a flooring behavior
This is done to allow querying the current active tool inside the
event_with_pan_and_scale_applied and event_adjusted_for_layer
functions without risking a null pointer dereference
This method is used to point a position at the preferred pixel of
the image. Certain tools may want to specify a different preferred
pixel for the same input position.
When the location currently displayed in FileManager is removed, find
the nearest existing parent path and open it in the window.
Without the fix, the FileManager window remained in the deleted
directory.
Changing the path in 'DirectoryView' object will automatically update
other components in the FileManager (breadcrumb bar, directory tree
view).
This commit fixes FileSystemModel behaviour when the root path of the
model has been deleted.
In this case, the model index resolved for the root path is invalid and
passing it to 'begin_delete_rows' would trigger assertion failure.
Instead of deleting all children rows one by one, we simply invalidate
the whole model.
And adjust some GML properties. Since a808cfa, splitters grow
opportunistically. Setting them to fixed sizes now quite literally
fixes them in place. Fixes immovable splitters missed in the
aforementioned commit.
Previously, for a regex such as /[a-sy-z]/i, we would incorrectly think
the character "u" fell into the range "a-s" because neither of the
conditions "u > s && U > s" or "u < a && U < a" would be true, resulting
in the lookup falling back to assuming the character is in the range.
Instead, first explicitly check if the character falls into the range,
rather than checking if it falls outside the range. If the explicit
checks fail, then we know the character is outside the range.
The Quake 3 port makes use of this extension to determine a more
efficient multitexturing strategy. Since LibSoftGPU supports it, let's
report the extension in LibGL. :^)
Instead of hardcoding all the property definitions in GlobalObject's
initialize() function, make it the standalone AO it is supposed to be
that can then be used by other global objects that don't inherit from
JS::GlobalObject.
This will later allow global objects not inheriting from the regular
JS::GlobalObject to pull in these functions without having to implement
them from scratch. The primary use case here is, again, a wrapper-less
HTML::Window in LibWeb :^)
Allocating these upfront now allows us to get rid of two hacks:
- The GlobalObject assigning Intrinsics private members after finishing
its initialization
- The GlobalObject defining the parseInt and parseFloat properties of
the NumberConstructor object, as they are supposed to be identical
with the global functions of the same name
This removes the requirement of having a global object that actually
inherits from JS::GlobalObject, which is now a perfectly valid scenario.
With the upcoming removal of wrapper objects in LibWeb, the HTML::Window
object will inherit from DOM::EventTarget, which means it cannot also
inherit from JS::GlobalObject.
The object is passed directly to NewObjectEnvironment, which has no
requirement for this being a JS::GlobalObject. This is needed for the
next change, which will make Realm store a plain Object as for the
global object as well.
