Repository navigation
Wayland : Add AppId in WaylandPlatformOptions and WaylandProperties - #22209
Conversation
|
This looks similar to #21982, but that one doesn't add |
|
|
You can test this PR using the following package version. |
|
I would assume AppId per app (not per window) is much more common use case. I understand one might need to have different windows behave as different applications (quick google suggests viewer/editor split might be reasonable here). I wonder if we can provide wayland interop points instead for these cases. cc @kekekeks |
e8e14fe to
ba10cde
Compare
Indeed I didn't saw this one |
Yes, I think there are some cases where 2 windows could have different AppId, or setting it dynamically in the window using a binding to a view model |
…ndProperties to overload the app id if the executable name don't match the app name of the .desktop file
ba10cde to
5fee5ae
Compare
@cla-avalonia agree |
|
You can test this PR using the following package version. |
|
I tested the package 12.2.999-cibuild0069813-alpha in my app without issue |
|
What is the next step for this change (or the other one #21982 ) ? |
We're going to discuss whether we want the extra attached property; it shouldn't take long.
Yes |
|
Notes from the API review meeting:
|
- Centralize default AppId definition in WaylandGlobals - Use fallback to `Globals.AppId` where applicable. - Add detailed documentation for the `WaylandProperties.AppId` attached property.
|
@MrJul I pushed a rework with all the requested changes |
NuGet packagesThe packages for this pull request have been published (workflow run):
|
MrJul
left a comment
There was a problem hiding this comment.
Tested, works as expected.
LGTM!
|
Should I create a branch of 12.1.x for the backport with the fix ? |
No, we'll handle that automatically. |
…valoniaUI#22209) * Wayland : Add the AppId in WaylandPlatformOptions or in Windows WaylandProperties to overload the app id if the executable name don't match the app name of the .desktop file * Rework AppId handling in Wayland backend: - Centralize default AppId definition in WaylandGlobals - Use fallback to `Globals.AppId` where applicable. - Add detailed documentation for the `WaylandProperties.AppId` attached property. * Make WaylandProperties static --------- Co-authored-by: Julien Lebosquain <julien@lebosquain.net>
…22209) * Wayland : Add the AppId in WaylandPlatformOptions or in Windows WaylandProperties to overload the app id if the executable name don't match the app name of the .desktop file * Rework AppId handling in Wayland backend: - Centralize default AppId definition in WaylandGlobals - Use fallback to `Globals.AppId` where applicable. - Add detailed documentation for the `WaylandProperties.AppId` attached property. * Make WaylandProperties static --------- Co-authored-by: Julien Lebosquain <julien@lebosquain.net>
What does the pull request do?
In Wayland, an app in a "Alt+Tab" should have the name and the icon of the .desktop
Added a property AppId in WaylandPlatformOptions and WaylandProperties to overload the app id if the executable name don't match the app name of the .desktop file. By default it will take the name of the executable if it is not set.
What is the current behavior?
For now, the icon is the default system one and the name is unknow.
What is the updated/expected behavior with this PR?
A new property AppId in WaylandPlatformOptions or set WaylandProperties.AppId in a Window
How was the solution implemented (if it's not obvious)?
I copied the SetTitle in Wayland and add the possibility to set the property AppId in WaylandPlatformOptions or in Windows.WaylandProperties
Checklist
Breaking changes
None
Obsoletions / Deprecations
None