Params are not available in qml handlers

[vchekan]

There is a demonstration of how rust object signal can be connected to qml object, but there is no demo of how parameter is passed even though signal is defined with one param fn pageDownloaded(response: String). https://github.com/White-Oak/qml-rust/blob/master/examples/threaded.qml#L28

If I try to modify handler to onPageDownloaded: console.log("Page Downloaded "+ response); then I get error at runtime: threaded.qml:28: ReferenceError: response is not defined

[White-Oak]

@vchekan thanks for the issue! Unfortunately, at the moment attributes' names are erased on signal registration, we will try to see if there is a way to preserve them.

Currently, there are two possible workarounds:

1. Use arguments:

onPageDownloaded: console.log("Page downloaded " + arguments[0]);

Remember, that in JS you can always check what are the arguments of the function (see this answer on SO)

2. Connect signal to function in qml like this

  Component.onCompleted: {
    visible = true;
    logic.pageDownloaded.connect(jsPageDownloaded);
  }

  function jsPageDownloaded(response) {
    console.log("Page downloaded " + response);
  }
  // ...

[White-Oak]

Edit2: Note, that the following is just an explanation of why named attributes are missing and should not be used, as it is soon to be fixed.

You can also access attributes by using argi, where i is the number of attribute. That is so, because underlying bindings don't preserve the names of attributes just yet. Instead, every attribute is assigned with a name in cycle.

onPageDownloaded: console.log("Page downloaded " + arg0);

Edit: note that this is the consequence of erasing attributes' names, not how JS in QML works.

[rustonaut]

it might be better not to use argX given that the including of attribute names could, maybe, at some time, be added to rust-qml which then would break the code. On the other side, rust-qml is still on a version bellow 0.1 so I would guess you don't have any stability guarantees anyway ;=)

[White-Oak]

@dathinab yes, preserving attributes' names is soon to be added, totally shouldn't have advised that, I'll fix my comment right away.

And yes, there's still so much to reconsider about, especially about macros -- they are made to work on stable rust, but, in result are monstrous and inflexible. I've been thinking about using macros 1.1, but these are just 'custom derives', so making qtobjects out of rust's structures can turn tedious: #10.

Edit: grammar fixes.

[filcuc]

This is not blocked anymore