Almost every JS prototype class defines a static "typed_this" helper to
return the current "this" value as the analogous object type. This adds
a PrototypeObject class to be inserted between the prototype object and
the base Object class to define these methods on the prototype's behalf.
Note that the generated "display_name" method must be defined static
because the callers of typed_this are also static.
Because of the way rulers are implemented in the ImageEditor
currently, the `Fit Image To View` action doesn't work correctly
with them enabled. This patch makes them adjust to the effective
viewport area and account for the rulers.
This is a bit of a hack, but the correct way to deal with this would
be to put the rulers in a new widget so they don't interfere with
the actual viewport rect (which is being used all over).
After transitioning to FileSystemAccessServer, some of the methods
in `MainWidget` and `ProjectLoader` for opening files directly with
a filename as opposed to with a file descriptor are unused. This
commit removes them.
Use the newly added API in FileSystemAccessServer to get read-only
access to a file specified on the commandline. We no longer need to
unveil any image / .pp files on the filesystem :^)
Depending on the size / scaling of the UI, someone might want to
change what the threshold is to show the pixel grid. For instance
if you are working on a 50x50 image, and want to see the grid while
still fitting the whole image in the editor.
Since there's no UI for settings in PixelPaint right now, this
commit just uses LibConfig to read the following entry:
("PixelPaint", "PixelGrid", "Threshold")
which is then used when drawing the grid.
Currently, we have NotA and NotAn, to be used dependent on whether the
following word begins with a vowel or not. To avoid this, change the
wording on NotA to be independent of this context.
This removes the awkward String::replace API which was the only String
API which mutated the String and replaces it with a new immutable
version that returns a new String with the replacements applied. This
also fixes a couple of UAFs that were caused by the use of this API.
As an optimization an equivalent StringView::replace API was also added
to remove an unnecessary String allocations in the format of:
`String { view }.replace(...);`
This was needlessly copying StringView arguments, and was also using
strstr internally, which meant it was doing a bunch of unnecessary
strlen calls on it. This also moves the implementation to StringUtils
to allow API consistency between String and StringView.
In many cases we can lean on the name of a menu to reduce verbosity.
"View"->"Visualize/Show/Turn on/etc" is a bit redundant and clutters
the menu. It's a little thing, but it makes the system feel more
tightly integrated if we stick to the same word patterns across apps.
This commit adds a `ColorSelectOverlay` class, and uses it to
allow the user to pick a color from the screen. The API for
`ColorSelectOverlay` is inspired from the `SelectableOverlay`
in `Utilities/shot.cpp`. In particular, it opens up it's own
window, so that we can have control over the cursor over the
whole screen.
There's one thing notably different: In addition to returning the
final selected color from the `exec()` function, it also provides
an `on_color_changed()` hook, which can be used to (optionally)
get live updated as the mouse is moving around.
This is a bit odd, but allows us to use the preview widget of the
color picker to see the current color under the mouse (which will
be selected upon clicking). When trying to select the color from
text / other small elements, this is very useful.
This allows any client to ask the WindowServer to give it the color
of the screen bitmap under the cursor.
There's currently no way to get the screen bitmap *without* the
cursor already drawn on it, so for now we just take a pixel
beside the actual cursor position to avoid just getting the cursors
color.
These interfaces are broken for about 9 months, maybe longer than that.
At this point, this is just a dead code nobody tests or tries to use, so
let's remove it instead of keeping a stale code just for the sake of
keeping it and hoping someone will fix it.
To better justify this, I read that OpenBSD removed loadable kernel
modules in 5.7 release (2014), mainly for the same reason we do -
nobody used it so they had no good reason to maintain it.
Still, OpenBSD had LKMs being effectively working, which is not the
current state in our project for a long time.
An arguably better approach to minimize the Kernel image size is to
allow dropping drivers and features while compiling a new image.
