In D10331#202789, @rizzitello wrote:

• Remove Use of gcodecommands
• Remove GcodeCommands

why ??

In D10331#203355, @patrickelectric wrote:

In D10331#202789, @rizzitello wrote:

• Remove Use of gcodecommands
• Remove GcodeCommands

why ??

• Less code to maintain
• Lots of code for little gain
• Code is slightly more readabe in atcore with only QStringLiteral("G28") instead of GCode::toCommand(GCode::G28));
• GCode::toString was used 5 times. Strings returned by this might not be accurate for your firmware. This class contained lots of strings for the translators that we never used.

Maybe this could be used in atelier to help users make gcodes ? ?

In D10331#203357, @rizzitello wrote:

In D10331#203355, @patrickelectric wrote:

In D10331#202789, @rizzitello wrote:

• Remove Use of gcodecommands
• Remove GcodeCommands

why ??

• Less code to maintain
• Lots of code for little gain
• Code is slightly more readabe in atcore with only QStringLiteral("G28") instead of GCode::toCommand(GCode::G28));
• GCode::toString was used 5 times. Strings returned by this might not be accurate for your firmware. This class contained lots of strings for the translators that we never used. Maybe this could be used in atelier to help users make gcodes ? ?

I disagree, this is a abstraction for the commands and dialects, reverting this class will reflect in a big problem on the future. That's my point of view.

In D10331#203391, @patrickelectric wrote:

I disagree, this is a abstraction for the commands and dialects, reverting this class will reflect in a big problem on the future. That's my point of view.

There is no dialect stuff here thats all in the firmware plugins. I thought about some of the cases where we can have options with things like 'I' and other args that are not standard for most codes. We can if/when we support those options we can have a more dynamic way to add the arguments for the few gcodes that could require them.

The best thing is to replace the gcode class to more generic classes. But
remove this abstraction is a kickback, we can use this class to provide a
lot of important information to the graphic interface, gcode editor, gcode
information and etc.. besides that, isn't hard to maintain what is standard
protocol, only small things change between this main class.
If the gcode class isn't helpfully we need to reformulate it and no remove.

In D10331#203394, @patrickelectric wrote:

we can use this class to provide a
lot of important information to the graphic interface, gcode editor, gcode
information and etc..

This is why i suggested it would be more useful to a client of atcore. I don't think it belongs in atcore or is needed for any of the opperations that atcore does now or will be doing.

I feel the same way as patrick on this one - I understand that you want less code but I feel that missing the debug information as missing parameters for a command to be a good thing

Ok I'll go back to my previous version of this diff isn't tereany opps