Method calls! You can now do dbus method calls in the TUI!

[Troels51]

When hitting Enter on a method in the tree a popup will show. You can then enter each argument in text fields in this popup the arguments are then parsed into dbus types that are sent with the method call The return value is then put into the output text box.

To do this a parser for a human readable format for dbus types was created parsers are created for a given type signature, and the then input is validated against that The parser is written using chumsky with subparsers for each dbus type.

A couple of notes on things I want to improve.

• The output format is generated by zbus, and doesn't match the input format.
• Documentation of the input language in the UI itself
• The number of modes a user can be in has gotten too big for the current way of handling input, some refactoring is needed there

[zeenix]

@Troels51 Hey. Just FYI zbus 5.0 was release 2 weeks ago. It's probably a good idea to rebase this and merge it (if it works).

[Troels51]

@Troels51 Hey. Just FYI zbus 5.0 was release 2 weeks ago. It's probably a good idea to rebase this and merge it (if it works).

Yep. I actually tried to do that yesterday and the update from git to 5.1 didn't go through cleanly. So I'll need to do a bit more work

[zeenix]

@Troels51 Hey. Just FYI zbus 5.0 was release 2 weeks ago. It's probably a good idea to rebase this and merge it (if it works).

Yep. I actually tried to do that yesterday and the update from git to 5.1 didn't go through cleanly. So I'll need to do a bit more work

True but I'm sure it won't be a lot of work. The release notes should guide you:

https://github.com/dbus2/zbus/releases/tag/zbus-5.0.0
https://github.com/dbus2/zbus/releases/tag/zvariant-5.0.0

I think mainly it's that zvariant::parsed::Signature is now just zvariant::Signature since now we only have parsed form of signature everywhere.

[Troels51]

@Troels51 Hey. Just FYI zbus 5.0 was release 2 weeks ago. It's probably a good idea to rebase this and merge it (if it works).

Yep. I actually tried to do that yesterday and the update from git to 5.1 didn't go through cleanly. So I'll need to do a bit more work

True but I'm sure it won't be a lot of work. The release notes should guide you:

https://github.com/dbus2/zbus/releases/tag/zbus-5.0.0
https://github.com/dbus2/zbus/releases/tag/zvariant-5.0.0

I think mainly it's that zvariant::parsed::Signature is now just zvariant::Signature since now we only have parsed form of signature everywhere.

Makes sense.

While I have you. Now I am just using the zbus variant Display methods when showing method call outputs, but it doesn't line up with my input format. The main problem being the way zbus prints type information in some variant. Would you be open for a change to that?
If you need more specific info, I can send that later :)

[zeenix]

If you need more specific info, I can send that later :)

Yes please. Some example would help me understand what you're talking about. :) BTW, you don't need to rely on our Display impl. While in general, I'm open to suggestions on changes to the impls, IIRC some impls are kept exactly the same as that glib API for compatibility. But let's see an example, and I'll know if that's what you mean.

[Troels51]

I updated to zbus 5.1 now, if you want to see what an update looks like

With regards to the Display impl, the picture attached shows an example. ObjectPath is being displayed with "objectpath" as a prefix.
This comes down to the type for Value being displayed by default (https://github.com/dbus2/zbus/blob/538c9742973c0a8345a5cbd641ee17d6b5cac0b2/zvariant/src/value.rs#L477)
It would be nice if the default would be to not display the type, or make 'value_display_fmt' public, so that i set the type annotation myself.
Maybe i will just copy value_display_fmt, that might be easier for me :)

[zeenix]

With regards to the Display impl, the picture attached shows an example. ObjectPath is being displayed with "objectpath" as a prefix.
This comes down to the type for Value being displayed by default (https://github.com/dbus2/zbus/blob/538c9742973c0a8345a5cbd641ee17d6b5cac0b2/zvariant/src/value.rs#L477)
It would be nice if the default would be to not display the type, or make 'value_display_fmt' public, so that i set the type annotation myself.
Maybe i will just copy value_display_fmt, that might be easier for me :)

Right, thanks. So as you can see from the comment below that line, the impl is meant to resemble that of gvariant. The discussion is here about why this format was chosen: dbus2/zbus#366 . However, reading it again, I think the benefit of compatibility with gvariant doesn't seem very appealing to me anymore, especially given that I've mostly lost interest in gvariant format support in zbus.

So yeah, we can reconsider this but first, can't you use ObjectPath::as_str method to display it as just a string?

[Troels51]

So yeah, we can reconsider this but first, can't you use ObjectPath::as_str method to display it as just a string?

Where i use it i just have a generic Value, not the specific ObjectPath type.
I will just copy the 'value_display_fmt' function and then call it without the type information, then i can also control it myself if i want to change the format.

[zeenix]

So yeah, we can reconsider this but first, can't you use ObjectPath::as_str method to display it as just a string?

Where i use it i just have a generic Value, not the specific ObjectPath type

Ah ok.

I will just copy the 'value_display_fmt' function and then call it without the type information, then i can also control it myself if i want to change the format.

works. I mean, all you've to do is match the Value enum and then do whatever you need to do for each variant.