* Use an alias for the signature of the property data notifier
* Replace the onQueryText interface from the editor and instead provide
an object with the property data notifier. That way no second connection
between editor and properties widget needs to be established,
everything is provided in the one callback.
(This could also be simply a closure, instead of an interface implementation)
A recent commit introduced delayed press event, but the position of the
event was relative to the parent of the Flickable instead of relative to
the Flickable itself.
Fixes the printerdemo not expanding the element in the printer queue
- Use Node.js as the name, as that's also what's on the website
- Link to the websites of the dependencies
- Move the Node.js API prerequisites below the C++ section, in order of priority
- Create a Node.js Tests section, similar to C++, just for running the tests
- Change the remaining Node.js API build section, similar to C++, to
explain what's needed to build it from git and how to use it.
- In order to -> To
- Use title case for section titles
- Elaborate in the indvidual sentences about testing and building what the
prerequisites are, what the provided command lines accomplish and where
the output can be found.
Commit 0767a70f9e removed the online editor from the existing multi-path
artefact. The multi-path artefact
preserved the leading paths, which is why after extraction the online editor build
could be find at tools/online_editor/dist.
After the commit, the online editor is in its own archive single-path archive, which is when GH
strips the leading path and we end up with just the contents of dist/ directory in the archive.
At end of text, take the right edge of the glyph cluster; otherwise the left edge
of what's to the right of the cursor.
For empty text inputs, just return the height of the text to be.
cc #1480
Instead of a for loop that awaits ten times one second to see if the lsp
started up (within a microtask that nobody awaits for), resolve the
promise that the editor is ready precisely when we receive the message
from the lsp. In the window's onload handler we can then remove the
loader screen when the editor is ready (as connected microtask).
This means that the other widgets are attached to the DOM in the
meantime and even the preview can being doing its work. To avoid the
loader screen affecting the position of the widgets, place it in a layer
above everything else.
If render() is called before the widget is attached, we end up with a
panic in the GL renderer as we cannot extract a gl context out of the
Canvas element. The element has been created (good), but it's not
hooked into the window's body yet.
Therefore instruction Slint to only render after we've been attached.
In the future this could be generalized to also support detaching.
Turns out that was not actually doing anything locally :-/
So force the compiler to run, add some types that went missing and
disable checking of the webworkers -- there is a type conflict in there
that needs to be fixed upstream (Issue is:
https://github.com/DefinitelyTyped/DefinitelyTyped/issues/60868).
We can store the promise that wasm bindgen generates to initialize glue
code and simply await on it as needed. Calling then() on a fullfilled
promise will just resolve to the promise result.
A resize of the HTML canvas element would trigger our own resize
handler, which tried to do a special dance to trigger a redraw.
As it turns out, this breaks with current winit as the event loop target
is gone, so calling with_window_target() panics.
See also commit 8b728df021
Instead, this patch reverts to the simpler method of calling
invoke_from_event_loop, has workarounds for how to properly wake up the
event loop and return poll. In there we can just call request_redraw()
on the winit window directly to trigger a draw.
in the funciton `visit_layout_items_dependencies` we were passing a
NamedReference for a property that could have been in the base
component type of an element, instead of in one of the element within
the current visited component. This would result in wrong computation
done later to find out the "element path" of the property.
We then need to tell the visitor that the named reference is in a sub
component. To do that, we need to visit a PropertyPath instead of just a
NamedReference
Issue 1659 was showing one of the symptoms of this, which was an assert.
But it could also result in wrong analysis (binding loop not detected
when it should or vice versa)
Fixes#1659
