We parse hex colors as per CSS, including the #RRGGBBAA variant, as per
https://www.w3.org/TR/css-color-4/#hex-notation . This is now documented
and the JS conversion also generates that instead of #AARRGGBB.
When converting from object literal to object literal, we would check
recursively if the individual fields can be converted and then generate
code to convert each field.
For a conversion frmo object literal to a struct, we would a per-field
can_convert check as well, but there would not be any code (Expression)
generated for the conversion, instead it would be a straight cast. That
was fine so far in our tests and example code, because the fields never
required a conversion. With commit
071ab9fda1 the percentage number literals
used in the printer demo however would now require a conversion
(multiplication by 0.01) before the assignment to the float level field.
This patch adds the missing conversion by matching the Object -> Struct
conversion case, generating an intermediate Object type based on the
struct's properties, call maybe_convert recursively and *then* cast the
result to a struct.
Typically `some_length_prop: 40%` produces an error, but if there's a
matching property in the parent, then it will be allowed and interpreted
as relative value and creates a dynamically updated binding.
The logical pixels are now just called "px" and the less frequently
used physical pixels have the "phx" suffix.
The existing markup was adapted using the syntax updater and the
following patch:
+ if node.kind() == SyntaxKind::NumberLiteral {
+ if node.text().ends_with("lx") {
+ return write!(
+ file,
+ "{}px",
+ node.text().as_str().split_at(node.text().as_str().len() - 2).0
+ );
+ }
+ if node.text().ends_with("px") {
+ return write!(
+ file,
+ "{}phx",
+ node.text().as_str().split_at(node.text().as_str().len() - 2).0
+ );
+ }
+ }
Fixes#49
Similar to the mouse_grabber, we use a VisitChildrenResult field to
track the focus item within a component. Unlike the mouse grabber
however, it is set/cleared using dedicated focus events.
The key event now routes the key event directly to the focus item.
The focus can be requested via set_focus_item on a window, which the
TextItem does.
When selecting to the left, the anchor remains to the right of the cursor.
When deleting such a selection, we fetch the cursor and anchor using a helper
method, which ensures that the anchor is to the left of the cursor.
Finally when setting the cursor then to the anchor, we need to also
set the anchor, since both were swapped.
This also add an automated test for this scenario.
Unfortunately something is wrong with the Qt style, it looks like the Qt style
does not respect the rect given for the sub components
Also Input is not handled yet.
