This patch removes the following WebContent IPC calls, which are no
longer used:
- `Server::js_console_initialize()`
- `Client::did_js_console_output()`
With this patch, we now initialize the `WebContentConsoleClient` as soon
as the Page has loaded, instead of waiting for the Console Window to be
shown. This finally lets us see log messages that happened before the
window was opened! :^)
However, it is not perfect. Waiting until the page has loaded means we
lose any messages that happen *during* page load. Ideally we would
initialize the WCCC when the page *starts* loading instead, but it
requires that the page has a document and interpreter assigned and
accessible. As far as I can tell with my limited knowledge, this is not
the case until the page has completed loading.
The `WebContentConsoleClient` now keeps a list of console messages it
has received, so these are not lost if the ConsoleWidget has not been
initialized yet.
This change does break JS console output, but only until the next
commit. :^)
This patch introduces three new IPC calls for WebContent:
- `Client::did_output_js_console_message(index)`:
Notifies the client that a new console message was logged.
- `Server::js_console_request_messages(start_index)`:
Ask the server for console messages starting at the given index.
- `Client::did_get_js_console_messages(start_index, types, messages)`:
Send the client the messages they requested.
This mechanism will replace the current
`Client::did_js_console_output()` call in the next few commits. This
will allow us to display messages in the console that happened before
the console was opened.
`$0` is a helpful variable in other browsers' JS consoles, which points
to whichever DOM Node is currently selected in the DOM Inspector. And
now we have it too! :^)
ConsoleGlobalObject is used as the global object when running javascript
from the Browser console. This lets us implement console-only functions
and variables (like `$0`) without exposing them to webpage content. It
passes other calls over to the usual WindowObject so any code that would
have worked in the webpage will still work in the console. :^)
I broke this when I made the protocol objects be wrapped by smart
pointers to appease static analysis.
The Protocol base class currently VERIFY's that it's never called.
So to have the best of both worlds until someone actually fixes
the code to do proper de-registration, just call `exit(..)` so the
smart pointers never go out of scope.
There are a few places in the system where this could be useful,
such as PixelPaint and the MandelBrot demo. It seems general enough
that it is probably useful to have it as a system-wide cursor rather
than loading it manually each time.
This can be used immediately in PixelPaint (separate commit), but
I am adding this as a system-wide cursor since it may also be useful
for other applications that want to use it.
This is the IPC version of `Document::set_inspected_node()`, using a
node ID.
We return the inspected node's style properties as JSON, so that the DOM
Inspector can immediately display them.
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.
Applets and windows would like to be able to know when the applet
area has been resized. For example, this happens asynchronously after
an applet has been resized, so we cannot then rely on the applet area
position synchronously after resizing. This adds a new message
applet_area_rect_changed and associated Event AppletAreaRectChange,
and the appropriate virtual functions.
Previously, when `screen_index` was not provided when calling
`ClientConnection::get_screen_bitmap`, the bitmap that was created
was always the size of the bounding rect of the screen. The actual
screen bitmap was being cropped, but the bitmap being returned was
of the original size with just black pixels everywhere else.
We were only notifying clients about the change, but didn't actually
update the internal cache in ConfigServer itself.
Thanks to "The Grey One" for pointing this out. :^)
After opening a domain configuration and putting into our configuration
cache, we now monitor the underlying file for changes and send out
notifications to monitoring clients as needed.
This patch has three FIXME's:
- We create a new Core::FileWatcher for each domain.
- We don't yet detect removed keys.
- We don't know the type of key, so we assume everything is a string.
There are a number of ways we can solve those problems but let's not
hold up this patch while we wait for solutions. :^)
This patch adds a Config::Listener abstract class that anyone can
inherit from and receive notifications when configuration values change.
We don't yet monitor file system changes, so these only work for changes
made by ConfigServer itself.
In order to receive these notifications, clients must monitor the domain
by calling monitor_domain(). Only pledged domains can be monitored.
Note that the client initiating the change does not get notified.
This API lets applications specify which configuration domains they
will be accessing throughout their lifetime. It works similarly in
spirit to the kernel's pledge().
You cannot pledge_domains() more than once, and once you have used it,
it's no longer possible to access any other configuration domain.
This is obviously just a first cut of this mechanism, and we may need
to tweak it further as we go.
ConfigServer is an IPC service that provides access to application
configuration and settings. The idea is to replace all uses of
Core::ConfigFile with IPC requests to ConfigServer.
This first cut of the API is pretty similar to Core::ConfigFile.
The old:
auto config = Core::ConfigFile::open_for_app("App");
auto value = config->read_entry("Group", "Key");
The new:
auto value = Config::read_string("App", "Group", "Key");
ConfigServer uses the ~/.config directory as its backing store
and all the files remain human-editable. :^)
This patch adds OutOfProcessWebView::run_javascript(StringView).
This can be used by the OOPWV embedder to execute arbitrary JavaScript
in the top-level browsing context on the WebContent process side.
Now you can specify a CursorTheme key in /etc/WindowServer.ini. The
cursors are loaded from /res/cursor-themes/<name> directory. This
directory contains a Config.ini file with format similar to previous
Cursor section, except it uses relative paths.
This commit adds also Default theme, which uses cursors being
previously in /res/cursors.
The WidgetGallery is updated to match the new cursor path format.
In the DatabaseConnection constructor, there's a deferred_invoke
callback that references the client_id. But depending on when the
callback occurs, the reference of the client_id can change. This created
a problem when connecting to SQLServer using the SQL utility because
depending on when the callback was invoked, the client_id could change.
m_client_id is set in the constructor and that reference will not change
depending on when the callback is invoked.
This patch provides very basic, bare bones implementations of the
INSERT and SELECT statements. They are *very* limited:
- The only variant of the INSERT statement that currently works is
SELECT INTO schema.table (column1, column2, ....) VALUES
(value11, value21, ...), (value12, value22, ...), ...
where the values are literals.
- The SELECT statement is even more limited, and is only provided to
allow verification of the INSERT statement. The only form implemented
is: SELECT * FROM schema.table
These statements required a bit of change in the Statement::execute
API. Originally execute only received a Database object as parameter.
This is not enough; we now pass an ExecutionContext object which
contains the Database, the current result set, and the last Tuple read
from the database. This object will undoubtedly evolve over time.
This API change dragged SQLServer::SQLStatement into the patch.
Another API addition is Expression::evaluate. This method is,
unsurprisingly, used to evaluate expressions, like the values in the
INSERT statement.
Finally, a new test file is added: TestSqlStatementExecution, which
tests the currently implemented statements. As the number and flavour of
implemented statements grows, this test file will probably have to be
restructured.
Otherwise, we emit a menu_item_left to the WindowServer client even
though the mouse never left the menu item (as is the case when a
disabled menu item is clicked).
This allows for typing [8] instead of [8, 8, 8, 8] to specify the same
margin on all edges, for example. The constructors follow CSS' style of
specifying margins. The added constructors are:
- Margins(int all): Sets the same margin on all edges.
- Margins(int vertical, int horizontal): Sets the first argument to top
and bottom margins, and the second argument to left and right margins.
- Margins(int top, int vertical, int bottom): Sets the first argument to
the top margin, the second argument to the left and right margins,
and the third argument to the bottom margin.
Previously the argument order for Margins was (left, top, right,
bottom). To make it more familiar and closer to how CSS does it, the
argument order is now (top, right, bottom, left).
AudioServer loads its settings, currently volume and mute state, from a
user config file "Audio.ini". Additionally, the current settings are
stored every ten seconds, if necessary. This allows for persistent audio
settings in between boots.
Instead of neatly searching for all framebuffer device nodes and
changing ownership of them, let's generalize this function so we can
apply the same pattern on tty nodes.
WindowServer was not able to utilize any other framebuffer device in the
/dev directory due to wrong group ownership of other framebuffer
devices. Therefore we need to ensure that when SystemServer starts,
it checks all directory entries in /dev, searching for framebuffer
devices, and then apply the correct ownership for them.
With this change, LaunchServer will always return an empty list of file
handlers for special files e.g. sockets and devices. Before this change,
TextEditor was always returned as a default handler for these files.
Deleting a symlink via "FileOperation Delete" should not recursively
delete whatever the symlink is pointing to. Same basic idea applies to
the Copy and Move operations.
