[Proof of Concept/WIP] Tmds to Avalonia.DBus migration#20799
[Proof of Concept/WIP] Tmds to Avalonia.DBus migration#20799
Conversation
Create DBusXml/Types.xml defining named structs (MenuLayout, MenuItemProperties, MenuEvent, IconPixmap, ToolTip, InputContextArg, FormattedPreeditSegment) and register it as an AdditionalFiles entry in the csproj so the source generator uses readable type names.
Add xmlns:av namespace, av:ImportTypes, and av:TypeDefinition annotations so the source generator produces named struct types instead of tuples: - com.canonical.dbusmenu.xml: MenuLayout, MenuItemProperties, MenuEvent - org.kde.StatusNotifierItem.xml: IconPixmap, ToolTip - org.fcitx.Fcitx.InputMethod1.xml: InputContextArg - org.fcitx.Fcitx.InputContext.xml: FormattedPreeditSegment - org.fcitx.Fcitx.InputContext1.xml: FormattedPreeditSegment
Replace auto-generated DbusStruct_* names with meaningful type names from the av:TypeDefinition annotations added to the DBus XML files: - DbusStruct_Riaesvavz -> MenuLayout - DbusStruct_Riaesvz -> MenuItemProperties - DbusStruct_Risvuz -> MenuEvent - DbusStruct_Riiayz -> IconPixmap - DbusStruct_Rsariiayzssz -> ToolTip - DbusStruct_Rssz -> InputContextArg - DbusStruct_Rsiz -> FormattedPreeditSegment Also update property accessors (.Item1/.Item2 -> named properties) in DBusMenuExporter.cs and FcitxX11TextInputMethod.cs.
Replace Tmds.DBus.Protocol/SourceGenerator with Avalonia.DBus across all FreeDesktop platform code: DBusHelper, system dialogs, platform settings, and IME implementations (IBus, Fcitx). Key changes: - Connection → DBusConnection - VariantValue → DBusVariant - ObjectPath → DBusObjectPath - Callback signatures simplified (removed Exception? first param) - Struct/Array helpers → DBusStruct/List<T>
|
You can test this PR using the following package version. |
|
Leaving this PR for future review/hold as trayicons/menus/dialogs seems to work |
|
You can test this PR using the following package version. |
|
We are planning to route dbus calls over other (non-socket) transports. |
|
Another problem we've faced was introspection that was poorly supported by existing roslyn generator. We didn't need it for previously used DBus APIs, but with AT-SPI2 it became a problem. We needed something that we could make to work properly with accessibility, so we've opted to try writing our own generator and to use libdbus as reference wire transport to make sure that we aren't losing anything in translation (like that time with convenience variant-in-variant wrapping). So right now we are using our in-house DBus binding for AT-SPI2 only. We'll be evaluating our options later this year. We investigate if our approaches could be somehow upstreamed. |
|
Basically the current thing used in production is in-house generator + libdbus wrapper. There is some code for managed wire transport, but it's currently experimental. |
Can you be more specific what "other (non-socket)" actually is? |
ok, I assume this is the libdbus wrapper. |
|
Non-socket = abstract message-based transport. Imagine incapsulating DBusMessage packets over some other protocol or even over something cursed like |
|
i. e. we have plans for using AT-SPI2 for non-dbus environments. |
|
Note that the whole thing is pretty much WIP, we are including the repo as a submodule and building it with a switch that makes types internal. Once we get it into a shape that covers our usage scenarios we'll make a better document on what's different. |
|
@kekekeks I don't think you have any issues with Tmds.DBus.Protocol. If you'd want to do the message-based transport with the library, we can explore that. For the generator, I'll be looking to (finally) add support for handler types to the generator that comes with the project. Thanks for your feedback! |
4 participants
Switching our dbus backend for Avalonia.FreeDesktop from Tmds to Avalonia.DBus.
Proof of concept for now to see if this is a viable migration path.