We use a ModelTranslator to expose a DOMTreeModel from LibWebView :^)
It allows you to select the currently inspected node, which causes
the engine to render a little box model overlay above the web content.
This will allow us to share code with LibWebView from SerenityOS.
(This would otherwise not work, since its "WebView" namespace collides
with our "WebView" class.)
Also, we should eventually move towards a more sophisticated
multi-process WebView like OOPWV.
There are a lot of unsupported mouse click events that the engine
cannot handle. It such event (0) reaches the web engine - it will
assert.
Don't even propagate them - this is the safe way. As of today!
I also added back/forward buttons to the translation.
Should fix#27
This commit changes how we set the back and forward button key bindings
to use platform-specific standard key sequences.
For example, in Mac OS X, the back action will be now triggered via
Cmd+← and Cmd+[, whereas previously the action was mapped to Alt+←,
which is not standard in Mac OS X.
This setup should allow the package maintainers who are looking to
distribute ladybird on their distributions to use CMake to install
ladybird using cmake install rules rather than having to write their own
Reorganize the logic for initializing s_serenity_resource_root.
Now, we initialize it in platform_init(), and move platform_init to the
top of initialize_web_engine.
Add a branch at the end of the function to check
``QApplication::applicationDirPath()`` for the location of the
executable, and base the location of resources on that.
In an installed configuration, this will be /some/path/bin, with the
resource root set to /some/path/share/, looking for files in
/some/path/share/res/resource-type.
This matches up with some upcoming CMake changes to install resources in
CMAKE_INSTALL_DATADIR.
In the future, ladybird should probably use a QOpenGLWidget or similar
platform plugin to use the native GL implementation instead of the one
in serenity.
This allows requests like dumping the DOM tree to be forwarded to the
correct tab. Otherwise, the event would be forwarded to the most
recently created tab.
This patch removes the dual-event-loop setup, leaving only the Qt event
loop. We teach LibWeb how to drive Qt by installing an EventLoopPlugin.
This removes the 50ms latency on all UI interactions (and network
requests, etc.)
