Initial avalonia GUI

[nimrof]

Now that we have .net8 in master i can add this.
I have been playing a little bit with the cross platform avalonia gui and this is the branch.
Hopping this can replace the windows-only gui.

Its not in any way ready to merge, for me it is useful to find flaws in the protobuffer and supporting code and testing out avalonia when i feel like fiddling with gui and not code.

There are a loot that is missing so it is way easier to list the things that work:

• file->new
• partial device info (without a save button)
• very basic copy of device view

Working my way from left to right in the device view....very slowly

Just a disclaimer:

• I am i no way Avaloia expert
• Currently just copying the gui 1:1 with minor changes
  Not saying that is how it should be, but it does require less brain so that how i do it now.

Feel free to comment and commit

Update 13. January:

Want a break so pushing what i got now.
The dictionary part is almost done.

In the future i want to make it easier to change values in the subindex datagrid, not it does string to enumname and gives a warning if its a mismatch, so a dropdown or something would be great

knownbugs in the OD:

• In the object context menu only Add work.
• When you get the add dialog be very careful to only type in valid hex number all the time, if not it will crash.
• The add dialog remember its value from last time and the suggested index is not suggested
• Denotation should be alias and not implemented.
• The colors in the subobject view is temporary colored for my own sanity (yellow is from object, red is from subobject, black is removed (

Screen.Recording.2025-01-13.220854.mp4

[CANopenNode]

Nice. Works on Linux without problem:

sudo apt install dotnet-sdk-8.0
dotnet EDSEditorGUI2.dll

[CANopenNode]

Actually Linux also compiles it, if there are no binaries:

cd EDSEditorGUI2
dotnet run

[trojanobelix]

Nice and clean GUI

[CANopenNode]

Maybe at this point we could add some conversation about license. I don't have special interests, but anyway.

Current license of CANopenEditor (forked from https://github.com/robincornelius/libedssharp) is GPL v3. According to my experience with CANopenNode, people had problems with that license, if they tried to use the library in commercial products.

For commercial products more permissive licenses like MIT or Apache are more popular. If this project will grow, people may integrate it into own commercial products in the future.

If there is an interest, then we may add new code (Avalonia, protobuffer, new protobuffer-EDS converter, ...) under the MIT license. @nimrof ? Also important is the opinion of the original author @robincornelius ?

[nimrof]

I was waiting for @robincornelius to pinch in.

Maybe at this point we could add some conversation about license. I don't have special interests, but anyway.

Just to mention it again, i have interests.

Current license of CANopenEditor (forked from https://github.com/robincornelius/libedssharp) is GPL v3. According to my experience with CANopenNode, people had problems with that license, if they tried to use the library in commercial products.

For commercial products more permissive licenses like MIT or Apache are more popular. If this project will grow, people may integrate it into own commercial products in the future.

If there is an interest, then we may add new code (Avalonia, protobuffer, new protobuffer-EDS converter, ...) under the MIT license. @nimrof ? Also important is the opinion of the original author @robincornelius ?

Not sure if there is any interest in the GUI as it is today, but i definitely think we should use a permissive licenses on the protobuffer definition.
No problem using LGPT on the avalonia code and new protobuffer EDS, but it would not change anything as it needs GPL code in this project.

Not sure why people would like MIT/apache over LGPL on linux/windows/mac, but on embedded system where dynamic linking is non-existing i very much understand it.

[nimrof]

Hi,
@trojanobelix & @CANopenNode

Not sure what you think, but i think it would be beneficial to move it into master branch now.
Its not usable yet, but it might be better to check out the changes in smaller parts.

Alternatively i can make pr. into this branch

[CANopenNode]

As I understand, it does not interfere with the rest. So I agree moving it into the main branch.

Great job so far!