We use this to automatically update the thumbnail in LayerListWidget
when you draw into a layer. We also use it to repaint the ImageEditor
when the image changes somehow. :^)
Instead of using a TableView to show the layer stack, let's build a new
custom widget for this purpose and give it some neat features!
This patch also introduces an ImageClient interface for Image to notify
interested parties about things happening. The LayerListWidget is the
first ImageClient and listens for "layer added" and "layer removed"
notifications. :^)
This patch uses the new JS::MarkupGenerator to stylize all of the
source code and runtime values printed in the console's output panel.
This also does away with the Console's global style sheet, as all
styling is handled by the MarkupGenerator and the System Palette.
The new JS::MarkupGenerator class can convert both a JS source string
and a JS Runtime Value into properly formatted HTML using the new
LibWeb System Palette css color values.
It makes more sense for this JS -> HTML process to occur in LibJS
so that it can be used elsewhere, namely Markdown code block syntax
highlighting. It also means the Browser can worry less about LibJS
implementation details.
This fixes a bunch of FIXME's in LibLine.
Also handles the case where read() would read zero bytes in vt_dsr() and
effectively block forever by erroring out.
Fixes#2370
This patch adds spans around most of the console's output, allowing
for a global document stylesheet to customize the highlighting of
the console's output. It also adds some basic styling for values
like strings, numbers, and arrays using the system Palette.
Note: This patch simply adds support for highlighting output values,
the lines of JS code printed to console are still unformatted.
Previously, once a console was opened for a tab, its interpreter
would never change, leaving it with a stale interpreter. Now, when
the tab's HtmlView loads a new document, the console will receive
that document's interpreter.
The JavaScript console can be opened with Control+I, or using
the menu option. The console is currently a text box with JS
syntax highlighting which will send commands to the document's
interpreter. All output is printed to an HTML view in the console.
The output is an HtmlView to easily allow complex output, such
as expandable views for JS Objects in the long run.
Previously, clicking on an anchor link (href="#section1")
would always scroll to it on the current page, even if control was
held or the target="_blank" attribute was set. This fixes that
behaviour, and the link will always open in a new tab if required.
ImageEditor now supports panning (Ctrl+MiddleMouse) and scaling (Wheel)
the image. This took a lot of unpleasant coordinate math, but now it
actually kinda works and feels awesome! :^)
Make sure that userspace is always referencing "system" headers in a way
that would build on target :). This means removing the explicit
include_directories of Libraries/LibC in favor of having it export its
headers as SYSTEM. Also remove a redundant include_directories of
Libraries in the 'serenity build' part of the build script. It's already
set at the top.
This causes issues for the Kernel, and for crt0.o. These special cases
are handled individually.
We will now actually use MIME types for clipboard. The default type is now
"text/plain" (instead of just "text").
This also fixes some issues in copy(1) and paste(1).
This commit moves the clipboard from WindowServer into a new Clipboard
service program. Clipboard runs as the unprivileged "clipboard" user
and with a much tighter pledge than WindowServer.
To keep things working as before, all GUI::Application users now make
a connection to Clipboard after making the connection to WindowServer.
It could be interesting to connect to Clipboard on demand, but right
now that would necessitate expanding every GUI app's pledge to include
"unix" and also unveiling the clipboard portal, which I prefer not to.
Tools can now have an in-image context menu which you get when right-
clicking inside the image editing area. Our first use of this is to
provide the ability to move layers to the back/front. :^)
If we don't go via the action, the tool button becomes checked which
can bypass the exclusivity mechanism. That should probably also be
fixed but it's far outside the scope of where I am right now. :^)
This feels very intuitive and nice, although maybe we need some way to
override this behavior for the scenario where you're intending to move
something currently behind something else.
