Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Avalonia 12.0 cleanup list #12276

Open
kekekeks opened this issue Jul 21, 2023 · 11 comments
Open

Avalonia 12.0 cleanup list #12276

kekekeks opened this issue Jul 21, 2023 · 11 comments
Milestone

Comments

@kekekeks
Copy link
Member

kekekeks commented Jul 21, 2023

Tracking issue for API changes in the distant future, can be safely ignored until mid-2024

@MrJul
Copy link
Member

MrJul commented Aug 23, 2023

  • Change Inline.TextDecorations from a StyledProperty to an AttachedProperty

@robloo
Copy link
Contributor

robloo commented Oct 14, 2023

This is a possibility

cc @workgroupengineering

@maxkatz6
Copy link
Member

Shape.StrokeDashArray should be of IList type, instead of AvaloniaList.
This way we could reduce compositor subscriptions count by checking if stroke dash array implements INotifyCollectionChanged or not.

Right now, having AvaloniaList, code like `StrokeDashArray="10 5" will always require us to subscribe to the list changes.

@workgroupengineering
Copy link
Contributor

Make DevToolsOptions a record and change the property setter in init.

@maxkatz6 maxkatz6 changed the title V12 cleanup list Avalonia 12.0 cleanup list Apr 12, 2024
@maxkatz6
Copy link
Member

Ideally, this #4443 should be revisited as well.
Even better if ContextMenu was removed from the main assembly.

@robloo
Copy link
Contributor

robloo commented Sep 18, 2024

protected virtual string? GetHelpTextCore();
should be
protected abstract string? GetHelpTextCore();

See: #17030 (comment)

@maxkatz6
Copy link
Member

Revisiting PasswordChar to support complex emoji is something worth doing, imo. See #17554. This property should be a string type, not a char type.

@workgroupengineering
Copy link
Contributor

Revisiting PasswordChar to support complex emoji is something worth doing, imo. See #17554. This property should be a string type, not a char type.

I think it should be a rune type

@Gillibald
Copy link
Contributor

Revisiting PasswordChar to support complex emoji is something worth doing, imo. See #17554. This property should be a string type, not a char type.

I think it should be a rune type

Not all emojis can be represented by a single rune (codepoint)

@rabbitism
Copy link
Contributor

Revisiting PasswordChar to support complex emoji is something worth doing, imo. See #17554. This property should be a string type, not a char type.

I think it should be a rune type

should be but its not supported by standard2.0 sadly.

@MrJul
Copy link
Member

MrJul commented Nov 19, 2024

Also consider changing AccessText.AccessKey from char to string.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants