connect signal 'file-loaded' of hal_filechooser

In a VCP I want to connect to the signal 'file-loaded' to get a callback on loading and reloading.

On loading a new file it works fine, that signal is emitted here:[github.com/LinuxCNC/linuxcnc/blob/master...hon/hal_glib.py#L468]

But I also want to get a callback when the file is reloaded. I saw that hal_filechooser emits the signal for this case:[github.com/LinuxCNC/linuxcnc/blob/master..._filechooser.py#L127]
In Gmoccapy which is using hal_filechooser, I can see that this line is executed. But I don't get a callback in this case.
Shouldn't that line emits the signal?

It's been awhile since working on gladvcp but it has the same problem as any other python program.
The VCP python instance is a different context then Gmoccapy's python instance.
Which means messages from one are not sent to the other.
AFAIK there is no mechanism to exchange info from Gmpccapy internals.

I assumed that they are in the same context because:

That leads to another question which is the reason I thought so.

I separated the load() and calculate_gcode_properties() of your qt version of gremlin (qt5_graphics.py) and let me print the min_extents. (By the way: Nice work - thanks for that!)
If I embed that code in a GladeVCP that is integrated in Gmoccapy, I get values for min_extents which considers the machine offsets.
But if I run this standalone while (LinuxCNC is running). I get values independent of the offset. Have you any idea which code line/function is responsible for that?
 

You probably get the filename change in your vcp but not a reload.
Linuxcnc broadcasts the current file name so two python instances can be aware of a program change, but not a reload.

The same problem comes with changing offsets - linuxcnc does not have a message to send that means 'reload your screen'
I would think your standalone vcp would consider the offset - if you reload it manually.

It's a problem we surely could fix by adding a message to linuxcnc proper for this use but doing anything in linuxcnc proper is usually very painful for non expert level devs.

You probably get the filename change in your vcp but not a reload.
Linuxcnc broadcasts the current file name so two python instances can be aware of a program change, but not a reload.

Hmm it seems more like a sub-process of the main python process.

The same problem comes with changing offsets - linuxcnc does not have a message to send that means 'reload your screen'
I would think your standalone vcp would consider the offset - if you reload it manually.

While preparing an example, I could answer my question by myself. It was the missing linuxcnc.var file. On early tests I just created a blank one and forgot about that

It's a problem we surely could fix by adding a message to linuxcnc proper for this use but doing anything in linuxcnc proper is usually very painful for non expert level devs.

Hmm that could be difficult. I assume that the interpreter wouldn't even see the reload if the file is not changed.

python programs get their information from status messages from linuxcnc.
So as long as the information you need is in the status, multiple python instances can stay in sync.
reload of graphics works outside of linuxcnc status so can have these problems.
Error messages is another weak spot of linuxcnc. If any program reads the error status then no other program gets them.

If you put a G10 in your gcode program I'm 90% sure the graphics will not display properly - there will be an offset.

anytime there is a g10 the graphics need to be reloaded. If linuxcnc sent a message out every g10 then this problem would get simpler