Merge pull request #194 from reza0310/docs

[MIX][DOCS] Improving global documentation

Author: trojanobelix

.github/workflows/main.yml

@@ -0,0 +1,18 @@
+on: push
+
+jobs:
+    contrib-readme-job:
+        runs-on: ubuntu-latest
+        name: A job to automate contrib in readme
+        permissions:
+          contents: write
+          pull-requests: write
+        steps:
+            - name: Contribute List
+              uses: akhilmhdh/[email protected]
+              with:
+                use_username: true
+                commit_message: "[ROOT][DOCS] contrib-readme-action has updated readme"
+                pr_title_on_protected: "[ROOT][DOCS] contributors readme action update"
+              env:
+                  GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

CONTRIBUTING.md

@@ -0,0 +1,62 @@
+# CANopenEditor Contributing Guidelines
+
+Thank you for your interest in contributing to this project!<br>
+Being a well referenced EDS/DCF editor and the only one supporting CANopenNode, CANopenEditor let everyone manage CANopen files, completely free of charge!<br>
+CANopenEditor is maintained by a small team of volunteers from around the world. As such, those rules are meant for a better communication between everyone but, any help being very welcome, reviewers might approve PRs not respecting all of these rules as long as you tried. Project owners are above those rules as they might have specific needs.<br>
+Please note that by contributing to this project, you agree to have read this file and to the [Developer's Certificate of Origin 1.1](https://developercertificate.org/).
+
+## Discussions
+Discussions shall be done in respect to everyone and everyone's work.
+Any major change shall be first discussed in an issue. Do not worry: maintainers are quite active and will answer.
+
+## Code convention
+This project doesn't really follow any real code convention and doesn't have any linter for now BUT following [common C# code conventions](https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/coding-style/coding-conventions) is very welcome and might be asked of you if some parts of your code are too hard to read.
+If linting is ever needed, `dotnet format` will be our solution of choice.
+Even tho there is no hard-defined conventions, non-explicit names or lack of spacing might result in non-approval of a PR.
+
+## What might or might not be a PR
+A simple refactor of code without any real change won't ever be approved. This project relies quite a bit on git blame and as such you are only allowed to refactor code you change. Moreover, trying to enforce a code convention without approval of the main maintainers first might be seen as disrespectful.
+
+## Testing
+Any code change shall be tested. You can:
+- Add unit tests in the right directories
+- Describe any tests you did with the files you might have used
+
+Code that you didn't even try to compile won't be accepted.
+
+## Code comments
+- Complex algorithms MUST be explained with code comments.
+- Hardcoded values (e.g. specific numbers in the middle of nowhere) MUST be justified with code comments.
+- Non explicit data structures (e.g. an array of set size with every index having a meaning) MUST be explained with code comments.
+- Commented lines of code MUST be preceded by a comment line starting with either `//// DEBUG code:` or `//// TODO:`.
+- Comments SHALL have a space between the comment string (e.g. `//`) and the text content.
+- Functions and methods MIGHT have comments describing what they are doing, what are their inputs and/or outputs (if it's not explicit enough).
+- Loops and switches MIGHT have comments justifying why every case is taken into account (if it's not explicit enough).
+- Any more useful comment is welcome.
+
+## Names and descriptions
+### PR names
+They shall be composed of three sections:
+1) Which project is affected (MIX if multiple)
+2) What types of changes are made (e.g. FEAT, FIX, DOCUMENTATION/DOC, CORRECTION/CORR, SUGGESTION/SUGG, BUILD, ...)
+3) An explicit but less than 100 chars long summary of the changes
+
+Sections shall be clearly separated (e.g. with colons, parenthesis, ...).<br>
+Examples of valid and explicit PR names: `[MIX][DOC] Explaining explicit PR title rules`, `gui2: fix: Fixed bug where 1 = 2`.<br>
+If you have multiple unrelated changes (e.g. adding a feature and fixing another) to do, please do multiple PRs.
+
+### PR descriptions
+They shall:
+- Describe any change made
+- Explain why such changes are made
+- Explain any decision taken
+- Link any related issue / any related other PR
+- Describe any test made
+- The sentence "I have read the contributing guidelines, I agree to following them and I agree to the Developer's Certificate of Origin 1.1"
+
+### Commits
+Names shall be composed of:
+1) What types of changes are made (e.g. PR names sections 2)
+2) An explicit but less than 100 chars long summary of the changes
+
+Descriptions are entirely up to you.

EDSEditorGUI/README.md

@@ -0,0 +1,52 @@
+GUI
+=============
+* Open multiple devices
+* Open EDS/DCF/XDC files
+* Save EDS/DCF/XDC files
+* View OD Entries and explore the Object Dictionary
+* Add new OD entries
+* Delete exisiting OD entries
+* Create new Devices
+* Add default profiles
+* Create profiles that can be added to any project (just save the device xml file to the profiles/ directory, only include the minimum number of objects that you want to auto insert); This will auto add to insert menu
+* Edit Device and File Info sections
+* Set RX/TX PDO mappings easily from dropdown lists of available objects
+* Add and remove new PDO entries (communication paramaters and mapping) with a single button's push
+* Save groups of EDS/XML files as a network object with ability to set concrete node IDs
+* View report of all configured PDOs across the network
+* View modules and module details present within EDS files
+* View/edit actual object values for device configuring/DCF files
+* Support for loading XDD files (CanOpen offical XML)
+* Support for saving XDD files (CanOpen offical XML)
+* Some module info is displayed in GUI showing available modules (eds) and configured modules (dcf) and what OD entries they reference.
+  Full details such as subobj extension and fixed subobj are not currently displayed and unless there is demand probably will not ever be.
+
+[Available formats' list can be found here](https://github.com/CANopenNode/CANopenEditor?tab=readme-ov-file#available-formats).
+
+Pictures
+-------------
+For those pictures, the file shown is: https://www.hbm.com/fileadmin/mediapool/support/download/weighing/pad/PAD4000_P80_113_01_COS.EDS
+
+### General informations
+![General informations tab](../Images/General%20infos.png)
+
+### OD manipulation
+![OD when you select an object](../Images/OD%20selected%20object.png)
+![OD's communication specific parameters](../Images/OD%20comm%20specific%20param.png)
+
+### PDO manipulation
+TPDO:<br>
+![TPDO tab](../Images/TPDO.png)
+RPDO:<br>
+![RPDO tab](../Images/RPDO.png)
+PDO editing:<br>
+![PDO edition](../Images/Edit%20PDO.png)
+
+### Modules
+![Modules tab](../Images/Modules.png)
+
+### Profiles
+Available profiles:<br>
+![Profiles option](../Images/Profiles.png)
+Applying a profile:<br>
+![Profiles application](../Images/Applying%20profile.png)

EDSEditorGUI2/README.md

@@ -0,0 +1,5 @@
+GUI2
+=============
+This GUI is meant to be cross-platform, meant to replace the old GUI and is made using Avalonia. It is not yet ready.
+<br>
+[Available formats' list can be found here](https://github.com/CANopenNode/CANopenEditor?tab=readme-ov-file#available-formats).

EDSSharp/README.md

@@ -0,0 +1,24 @@
+EDSSharp
+=============
+
+A C# CanOpen EDS (Electronic Data Sheet) library, CLI convertor and GUI editor.
+
+This application is designed to load/save/edit and create EDS/DCF/XDC file for CANopen and also to generate the object dictionary for CANopenNode (V1.3 and newer) to aid development of CANopenNode devices.
+
+EDS (Electronic Data Sheet) files are text files that define CANopen devices.
+DCF (Device Configuration File) files are text files that define configured CANopen devices.
+XDD files are an XML version of EDS files.
+
+EDS/DCF are fully defined in the DSP306 standard by the CANopen standards body: CiA.
+
+The EDS editor on its own is useful without the CANopenNode specific export and, as of the 0.6-XDD-alpha version, the editor can also load/save XDD files.
+The GUI also shows PDO mappings and can generate reports of multiple devices that are loaded into the software.
+
+The core library can be used without the GUI to implement eds/xdd loading/saving and parsing etc in other projects.
+
+Please consider this code experimental and beta quality.
+It is a work in progress and is rapidly changing.
+
+Every attempt has been made to comply with the relevant DSP306 and other standards and EDS files from multiple sources have been tested for loading/saving and as been (at times) validated for errors using EDS conformance tools.
+
+[Available exporters' list can be found here](https://github.com/CANopenNode/CANopenEditor?tab=readme-ov-file#available-formats).

GUITests/README.md

@@ -0,0 +1,3 @@
+GUITests
+=============
+This directory contains unit tests for the avalonia (new) GUI. All tests shall be written in C# and run on all supported OS.