Bump DBus stack take 2

[affederaffe]

What does the pull request do?

Bump Tmds.DBus.Protocol and Tmds.DBus.SourceGenerator.
This uses the "official" Variant system instead of the SourceGenerator provided one (which was removed).
Accept the explicit ignoration of the DBus spec and assume collapsed variants.

What is the current behavior?

What is the updated/expected behavior with this PR?

How was the solution implemented (if it's not obvious)?

Tmds.DBus.SourceGenerator.PropertyChanges`1 was made internal by Tmds.DBus.SourceGenerator

Checklist

• Added unit tests (if possible)?
• Added XML documentation to any related classes?
• Consider submitting a PR to https://github.com/AvaloniaUI/avalonia-docs with user documentation

Breaking changes

Obsoletions / Deprecations

None

Fixed issues

#15655

[avaloniaui-bot]

You can test this PR using the following package version. 11.2.999-cibuild0048326-alpha. (feed url: https://nuget-feed-all.avaloniaui.net/v3/index.json) [PRBUILDID]

[maxkatz6]

@affederaffe since this PR has breaking changes, you need to run nuke ValidateApiDiff command locally (nuke tool needs to be installed, alternatively, you can run _build project with the same command directly).
As it looks like, some autogenerated dbus files were made internal, as they should be.

[affederaffe]

Only the PropertyChanges type was made internal as it should be, it was a mistake to make it public at first.
It is safe to make it internal as it is unusable by itself, all members that use this type (i.e. proxies with WatchPropertyChangedAsync) are already internal, so there cannot be any users of this api anyway.

[jmacato]

@affederaffe we still need to run the API validation regardless as it's a hard requirement for making stable builds at the moment

[affederaffe]

Avalonia.FreeDesktop.nupkg.xml

<?xml version="1.0" encoding="utf-8"?>
<!-- https://learn.microsoft.com/en-us/dotnet/fundamentals/package-validation/diagnostic-ids -->
<Suppressions xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <Suppression>
    <DiagnosticId>CP0001</DiagnosticId>
    <Target>T:Tmds.DBus.SourceGenerator.PropertyChanges`1</Target>
    <Left>baseline/netstandard2.0/Avalonia.FreeDesktop.dll</Left>
    <Right>target/netstandard2.0/Avalonia.FreeDesktop.dll</Right>
  </Suppression>
</Suppressions>

[maxkatz6]

@affederaffe @jmacato just updated api baseline by running "nuke" tool in the solution root.
@affederaffe you can just push these nupkg.xml file changes, when it is expected to break public API.

[avaloniaui-bot]

You can test this PR using the following package version. 11.2.999-cibuild0050468-alpha. (feed url: https://nuget-feed-all.avaloniaui.net/v3/index.json) [PRBUILDID]

[avaloniaui-bot]

You can test this PR using the following package version. 11.2.999-cibuild0050553-alpha. (feed url: https://nuget-feed-all.avaloniaui.net/v3/index.json) [PRBUILDID]

[kekekeks]

Sorry, missed the PR, will test tomorrow.

[kekekeks]

As of the public API, can we have source-generated classes to be private?

[affederaffe]

As of the public API, can we have source-generated classes to be private?

How could they be private?
The private modifier only makes sense for nested classes, but for that we'd need an explicit entrypoint (e.g. marker attribute) on a class. Which is only possible for proxies, and even then, when using the proxy multiple times, each would have its own private class.

[maxkatz6]

@affederaffe private for external consumer. I.e. internal is fine.

[affederaffe]

That makes more sense.
In this case, every source-generated class is already internal and thus inaccessible for users.

[kekekeks]

Why do we need

    <DiagnosticId>CP0001</DiagnosticId>
    <Target>T:Tmds.DBus.SourceGenerator.PropertyChanges`1</Target>
    <Left>baseline/netstandard2.0/Avalonia.FreeDesktop.dll</Left>
    <Right>target/netstandard2.0/Avalonia.FreeDesktop.dll</Right>
  </Suppression>

then?

[maxkatz6]

@kekekeks it wasn't internal before this PR

[avaloniaui-bot]

You can test this PR using the following package version. 11.2.999-cibuild0051285-alpha. (feed url: https://nuget-feed-all.avaloniaui.net/v3/index.json) [PRBUILDID]

[affederaffe]

Sorry, missed the PR, will test tomorrow.

@kekekeks Any updates on this?

[avaloniaui-bot]

You can test this PR using the following package version. 11.2.999-cibuild0051341-alpha. (feed url: https://nuget-feed-all.avaloniaui.net/v3/index.json) [PRBUILDID]

[kekekeks]

DBus menu works now with KDE without crashes, yes

[kekekeks]

I think at some point we might want to switch to using libdbus by adapting your generators. It wont be a 100% managed solution, but at least libdbus is pretty much guaranteed to follow the spec.

[tmds]

I think at some point we might want to switch to using libdbus by adapting your generators. It wont be a 100% managed solution, but at least libdbus is pretty much guaranteed to follow the spec.

My 2 cents.

VariantValue isn't meant to be a match with wire-representation of a variant. It is a convenience type that is meant for reading variant values. When you are reading those values, the UX is nicer if the variants are unwrapped.

I think that VariantValue probably works very well for your use-cases, but that you got caught/surprised by the difference in behavior with what you had before.

If you prefer a different behavior, you can still use the lower-level APIs and build your own Variant representation as the SourceGenerator was doing before.

[kekekeks]

Some DBus protocols require variants to be wrapped into variants. If it's not possible to represent such thing via the API, we'd need to switch the transport layer to a spec-conformant one for future-proofing.

[kekekeks]

The current problem was caused by misrepresentation of variants on receiver side, which is an inconvenience, but it's not possible to send such messages, which would outright prevent us from being able to implement protocols.

[tmds]

but it's not possible to send such messages, which would outright prevent us from being able to implement protocols.

For sending, VariantValue isn't used. There's a different type called Variant. Currently, it doesn't allow putting a Variant in a Variant. That's not intentional, it is an oversight.

And even then, the lower-level APIs enable you to take full control of serialization.