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.
I've used the shortcuts from GIMP for the most part, since that's what
I'm used to. We can definitely iterate on these to find better options
as the app develops. :^)
You can now see what you're drawing before committing to it. This works
by passing the second_paint_event from the ImageEditor to the tool.
We also pass the active layer which makes it easier for the tool to
keep his logic in layer-relative coordinates even while drawing preview
states directly into the ImageEditor backing bitmap.
Tool mouse event handlers now receive both a layer-relative mouse event
and the original event. This is needed for the move tool since it moves
the layer and thereby changes the origin of future events every time it
moves.
These two have the same semantics as GUI::Widget. The rect() is always
at location { 0, 0 }, while the relative_rect()'s location is relative
to the "parent", which in this case is the Layer's Image.
The main editing widget is now the new ImageEditor widget, which works
on an Image object, which internally has a stack of Layer objects.
Layers are composited back-to-front when painting the Image inside an
ImageEditor.
This was looking a bit too whimsical and didn't really fit with the
overall look of the window anymore. The actions are available via
the context menu still.
Moves DirectoryServices out of LibCore (because we need to link with
LibIPC), renames it Desktop::Launcher (because Desktop::DesktopServices
doesn't scan right) and ports it to use the LaunchServer which is now
responsible for starting programs for a file.
It didn't feel right to have a "DHCPClient" in a "Servers" directory.
Rename this to Services to better reflect the type of programs we'll
be putting in there.
If a button is checkable, its "checked" state is inversed in
Button::click. It's not needed for taskbar buttons - their checked
state is updated in TaskbarWindow::wm_event, based on the
current state of their window.
Fixes: #1878.
We now allow you to download files by right-clicking a link and then
choosing "Download".
All files are currently saved to the standard downloads location that
we get from Core::StandardPaths::downloads_directory().
In the future, we'll probably want to come up with a more restrictive
way of doing the "write to disk" portion of this.
We should also improve the ProtocolServer to allow streaming of data
instead of writing everything in one big go.
At the moment, I'm just pretty happy with this GUI. :^)
We're starting with a very basic decoding API and only ISO-8859-1 and
UTF-8 decoding (and UTF-8 decoding is really a no-op since String is
expected to be UTF-8.)
Running 'pape' without arguments (or just editing the WindowServer.ini by hand)
can confuse DisplaySettings. Specifically, if the 'Wallpaper' is set to
'/res/wallpapers/', then DisplaySettings used to crash because 'name_parts'
wouldn't contain any trailing element.
It's hard to define desired behavior, but this is better than crashing
and confusing the user.
