Gmoccapy - remove AUTOMATIC_G43

[zz912]

Gmoccapy had automatic activation of tool offsets using the G43 command after a tool change. The automatic G43 caused "race condition problems" in some configurations. That's why it was removed. Automatic G43 should be implemented by LCNC remap functionality not GUI.

This PR fix many bugs:
#2489
#2613
#2453
......

Here rmu75 explain why automatic_G43 is not good in GUI:
#2841 (comment)

Here Norbert allow me remove automatic_G43 from Gmoccapy:
#2841 (comment)

Sorry that this PR contains a lot of commits. I can only use Github in a web browser.

Unfortunately, this patch produced, or rather pointed out, more bugs:

1. bug:
   using M61 disable MDI window [SOLVED - this bug is not related with this PR]
2. bug:
   remap broke these configurations: lathe_macros.ini, xyzac-trt.ini [SOLVED]

I would like ask for help.

[Sigma1912]

Since the bug with M61 disabling MDI mode is not related to this PR I would suggest to remove this particular issue from the description of this pull request and file it in the 'Issues' list.
Thanks for working on this.

[Sigma1912]

as for the broken configs, try these modifications:

in 'configs/sim/gmoccapy/lathe_configs/lathe_macros.ini'

replace this line:
SUBROUTINE_PATH = macros:./
with this:
SUBROUTINE_PATH = ../macros:./

in configs/sim/gmoccapy/non_trivial_kinematics/table-rotary-tilting/xyzac-trt.ini
remove these two lines:
SUBROUTINE_PATH = ./examples
SUBROUTINE_PATH = ../../macros
and replace with this:
SUBROUTINE_PATH = ./examples:../../macros

[Sigma1912]

Could you edit the initial comment with the bug description and remove everything regarding the M61 bug and move that over to the issue you opened about this #3120

This way it would be much clearer that the two are not related.

[zz912]

After solving the bugs I will mark them [SOLVED]. I'll test your solution suggestions tonight. I hope it's clearer now.

[Sigma1912]

My apologies, I was under the impression that the m61 bug was not related to your changes to the ini file.
Now I made a mess, I'm sorry.

[edit]
Actually it seems that the M61 bug is indeed unrelated to this PR

[Sigma1912]

Testing 'configs/sim/gmoccapy/lathe_configs/lathe_macros.ini' with my suggested SUBROUTINE_PATH = ../macros:./

I actually get errors:

[Gmoccapy][ERROR]  g-file-error-quark: Failed to open file “/home/user/git/linuxcnc-zz/configs/sim/gmoccapy/lathe_configs/macros/images/i_am_lost.png”: No such file or directory (4) (gmoccapy:803)
[Gmoccapy][ERROR]  could not resolve the image path '/home/user/git/linuxcnc-zz/configs/sim/gmoccapy/lathe_configs/macros/images/i_am_lost.png' given for button 'macro_0' (gmoccapy:805)
[Gmoccapy][ERROR]  g-file-error-quark: Failed to open file “/home/user/git/linuxcnc-zz/configs/sim/gmoccapy/lathe_configs/macros/images/goto_x_y_z.png”: No such file or directory (4) (gmoccapy:803)
[Gmoccapy][ERROR]  could not resolve the image path '/home/user/git/linuxcnc-zz/configs/sim/gmoccapy/lathe_configs/macros/images/goto_x_y_z.png' given for button 'macro_4' (gmoccapy:805)

the issue here is that the original
SUBROUTINE_PATH = macros:./
does actually not point to an existing 'macros' folder as that is actually located in the parent directory.

So this is really something that was already broken in all the configs inside a sub folder of 'configs/sim/gmoccapy'. In none of those configs can we use for example 'o<i_am_lost>call'.

Fixing this seems to be somewhat tricky because of this path that is used inside the macro ngc files:

(IMAGE, ./macros/images/i_am_lost.png)

So I would suggest to move your two new ngc files into a new 'subroutines' folder and then to add that to the 'SUBROUTINE_PATH' as either ':subroutines' or ':../subroutines' depending on whether the .ini file is located in the 'configs/sim/gmoccapy' folder or a subfolder.

[zz912]

Thank you for explain lathe_macros.ini bug.
BUT i prefer this solution:

Use SUBROUTINE_PATH = ../macros:./
and remove all [MACROS] in INI file.
The behavior will be the same as before.

I want these macros together:

[zz912]

I have a question for @hansu . I wanted to add a note about deleting AUTOMATIC_G43 here:
https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/usr_intf/gmoccapy/release_notes.txt

Currently the version of Gmoccapa is 3.4.8. Unfortunately, this designation is the same in both stable (2.9) and master (2.10). Will there be a change for Gmoccapa versioning? In the past, most PRs was merged into STABLE, so versioning was not a problem. But now there is pressure to have only BUGfix in STABLE. (I agree with this, but grey zone exist) So maybe it would also require a change in versioning, or its definition.

This PR is again an exception. This is a BUGfix, but it changes the behavior a lot, so it must belong to the MASTER branch.

[hansu]

We can increase the version number of gmoccapy for LinuxCNC 2.10 to 3.5.0.
But we definitely should avoid making changes in gmoccapy.glade in 2.9 AND master. Because the glade file would be hard to merge.

[zz912]

Can I ask you explain why? I am interesting.

[hansu]

Because the glade file is generated by the Glade Editor and sometimes it happens that the order changes, maybe by a version change or something different. and if you then change something within those lines ... good luck :)

[hansu]

Suggested change

	- version for 2.10 (master) branche
	- version for 2.10 (master) branch

[zz912]

Thank you.

[hansu]

Is this really needed?

[zz912]

In some INI files is ../macros or ../../macros needed. I wanted to unify it.

[zz912]

Because the glade file is generated by the Glade Editor and sometimes it happens that the order changes, maybe by a version change or something different. and if you then change something within those lines ... good luck :)

I think, that exist 2 ways:

1. same Gmoccapy.glade for 2.9 and 2.10 branche
2. make bugfix for 2.9 manualy, then make bugfix for 2.10 manualy. Dont merge from 2.9 to 2.10

Did you think about second way?

[hansu]

I think, that exist 2 ways:

1. same Gmoccapy.glade for 2.9 and 2.10 branche

That would prevent you from adding new graphical features to Gmoccapy, so no real option.

2. make bugfix for 2.9 manualy, then make bugfix for 2.10 manualy. Dont merge from 2.9 to 2.10

That's only the "emergency option" when merging is not really feasible.

We only have to keep an eye of the changes in the glade file before merging and try to fix the 2.9 glade file manually or make sure Glade does not change the order of elements.

[zz912]

I am confused now.

HansU:

But we definitely should avoid making changes in gmoccapy.glade in 2.9 AND master. Because the glade file would be hard to merge.

Then:

zz912:

same Gmoccapy.glade for 2.9 and 2.10 branche

HansU:

That would prevent you from adding new graphical features to Gmoccapy, so no real option.

What is the procedure for bugfix to 2.9 gmoccapy.glade?
What is the procedure for adding new graphical features to 2.9 gmoccapy.glade?

[hansu]

Just keep the changes in the glade file in 2.9 small.

[andypugh]

Try making just the glade changes in (local) 2.9, then see if you can merge them into a local version of master.
Then carefully check that the new glade file isn't messed up in some subtle way (that might be hard to be sure about)