Evolving the library + broken slack?

[SbiCA]

Hi @CANopenNode ,

I was wondering how active this library is and if there is still some discussion going on. How would you see the evolution of the library

• making it a nuget package to be consumed https://github.com/Dotnet-Boxed/Templates/blob/main/Docs/NuGet.md
• make the UI web based for instance with Blazor Wasm so that no installation specific OS anyone get run it in the browser of choice even offline 😃
• Making use of t4, source generators to allow generating other Artefacts e.g. c#

Cheers

[trojanobelix]

These are good ideas. But I am currently the only one actively working on the project. Unfortunately, I also have no experience with the components mentioned.

I would be happy about the implementation. Create a PR when you have implemented them. I would push them into a new branch so that we can test them.

[CANopenNode]

Currently this library is good enough for its main purpose. It could get many additional functionalities, but it may also become too big, too complex and unreliable. According to my opinion it may need some re-organization of the core code before further extensions. And personally I prefer smaller and simpler applications, not necessarily with GUI.

[SbiCA]

@CANopenNode @trojanobelix agree with both of your standpoints, I think it'd still benefit the library in the long run but for sure it's not easy endeavour since it requires extracting the core part (as @CANopenNode mentioned). IMHO it would still be preferable to not rely on a Windows/Desktop only scenario since .NET as become cross platform a few years ago.

[CANopenNode]

I don't use .NET very often and don't know all the abilities it offers. But that does not really matter.

Actually EDSEditor.exe runs perfectly from Linux and for now it is just fine form me. There is also a command line tool EDSSharp.exe for translating between formats. I'm not familiar with the .net terms you suggest, so may not give best answer.

What I actually miss inside CANopenEditor is one clear database, which would be generated inside it, when CANopen project is loaded. But there is also some mess with the CANopen standards, as you can see in #45.

But still, one of the good points of CANopenEditor is, it translates between different formats quite well. Which also makes it complex and problematic for (partial) changes.

My long term idea is: I think eds files with it's INI format is somehow outdated. And xdd files with XML format specified by standard seems to be too complex. But data for one CANopen device is actually not that complex. So first I would like to add new custom data format for project file. I personally prefer json data format with keywords as specified by xdd standard. json is just simple to use. So basically first we simpy add json importer and exporter into CANopenEditor.

Then I think, it is better approach to make a new application, either c# or python or whatever. With json for project file and internal database. It is then simple to generate eds file or to add some sort of user interface. As a Linux user I prefer smaller applications for simple tasks, but there are no rules about that.

[trojanobelix]

I love the possibility to translate between different formats. No matter what format you put in front of it, it imports and generates CANopenNode code. To make the object dictionary available to other controllers, you can export in any format. This is really a great advantage.

[trojanobelix]

I am closing it now due to lack of feedback. Can be reopened if someone wants to pursue the topic further.