Gmoccapy - duplicate spindle speed settings in *.pref and *.ini files

[zz912]

This Issue is a continuation of the discussion from here:
#3488

Gmoccapy historically reads some parameters from a *.ini file, then saves them to a *.pref file. Then it reads and changes them using the Setup Page.
It is frustrating when you set parameters from a *.ini file, start Gmoccapy, the parameters are read correctly, but subsequent changes to the *.ini file are ignored. I have always struggled with this, but I thought it was just my distraction.

Currently, ISTAT check integration is in progress and there are plans to implement check INI parameters.
http://linuxcnc.org/docs/devel/html/gui/gui-dev-reference.html

It is necessary to decide how to deal with duplicate parameters in the Setup Page (*.pref file) in the future.

[Sigma1912]

some parameters from a *.ini file, then saves them to a *.pref file.

Could you indicate which parameters these are?

[Sigma1912]

I would agree that having ini settings ignored after the first start is rather unintuitive.
This also complicates online support as the ini file no longer reflects the actual setup values being used.

Is there a particular reason for not writing these values to the ini file instead?
After all that is what the 'calibration' tool has been doing for years.

[zz912]

some parameters from a *.ini file, then saves them to a *.pref file.

Could you indicate which parameters these are?

For example:

DEFAULT_SPINDLE_SPEED:
here is readed during first run Gmoccapy:

linuxcnc/src/emc/usr_intf/gmoccapy/getiniinfo.py

Line 281 in 259ad89

def get_default_spindle_speed(self):

here is saved to pref file:

linuxcnc/src/emc/usr_intf/gmoccapy/gmoccapy.py

Line 4330 in 259ad89

self.prefs.putpref("spindle_start_rpm", self.spindle_start_rpm, float)

(I have verified here that this parameter behaves as I wrote above)

in future ISTAT will check:
MAX_SPINDLE_SPEED
But in *.pref exists spindle_bar_max:

linuxcnc/src/emc/usr_intf/gmoccapy/gmoccapy.py

Line 4339 in 259ad89

self.prefs.putpref("spindle_bar_max", self.max_spindle_rev, float)

At this moment, I don't finding out how many parameters there are, because the rules for ISTAT are not yet set and I don't know how Norbert will approach these parameters.

This Issue is not about a technical solution to the problem, but about how the "Setup Page" in Gmoccapy should be developed.

Is there a particular reason for not writing these values to the ini file instead?

#3488 (comment)

After all that is what the 'calibration' tool has been doing for years.

What is 'calibration' tool?

[Sigma1912]

What is 'calibration' tool?

The tool to set the JOINT ini values:

[zz912]

I've gone through everything again and it looks like the problematic parameter now only exists:
DEFAULT_SPINDLE_SPEED

And in the future it will only apply to:
MIN_SPINDLE_SPEED
MAX_SPINDLE_SPEED

So I apologize for using parameters instead of parameter.
Anyway, it doesn't change anything about how to solve it.

[Sigma1912]

I would tend to just simply remove the 'Spindle' box from the Settings page.
In any case, having the pref file overrule an ini file setting seems wrong to me.

[c-morley]

It's not just the name.

It's also location:

Why does the location matter so much? It's very clear where it is from the source.
I'm asking these relentless questions so I make better choices/changes in the future.
To me it seems a bit OCD - which is fine, there are plenty of things I do just because it 'feels' right.

It's also about paths used in the code (eg 'qt_istat.py'):

Yes of course I agree, this needs to change for general usage.

and function names:
less a problem IMHO a function you don't use you can ignore - very clearly named as qt related rather then gtk and it's easy enough to organize the file layout to separate Qt and GTK specific function.

comments:
Obviously I made the file initially for QtVCP, then realized the function was very useful for GladeVCP.

Code that is to be shared by Qt AND non-QT based GUIs should not

use the Qt library

have 'qt' in the file-, class-, function-, variablenames, comments, etc.

be in the folder with the stuff that is only meant to be used by QT based GUIs .

So the easiest way to do this while still keeping common things in one class is to create a base class outside GladeVCP/QtVCP folders and then subclass in each VCP adding the specific toolkit required functions and paths.
It would probably be helpful to create functions for reading/qualifying INI settings so they could be overridden.
I don't prefer this to one file having everything because it promotes overriding and soon you have different ways to do the same thing. Having one file forces us to discuss changes.

Which leads me to:
https://linuxcnc.org/docs/devel/html/gui/gui-dev-reference.html
Which was written by me to get the ball rolling but surely needs discussion and extension.

Thank you.

[Sigma1912]

Thank you for your comments

Why does the location matter so much? It's very clear where it is from the source.

It's not that it's hard to find. The point is that a folder structure should order files in a logical manner. There are of course different ways of doing this but looking at the 'lib/python' folder it seems that the original idea was to have the files structured by gui or application. If this is to make any sense we must not have things in one gui folder import stuff from another gui folder. The things that are to be shared should be in a separate (eg 'common') folder.
When I maintain a GTK based gui like Gmoccapy I should never have to deal with something in a folder called 'qtvcp', 'touchy', 'stepconf' or 'plasmac'.

Just imagine some future person trying to remove one of those guis or applications from the source code. If the folder 'qtvcp' is removed the Gtk based Gui called Gmoccapy will no longer work. This is a clear indication that the folder structure has been broken and can no longer serve its purpose.

[zz912]

Why does the location matter so much? It's very clear where it is from the source.
I'm asking these relentless questions so I make better choices/changes in the future.
To me it seems a bit OCD - which is fine, there are plenty of things I do just because it 'feels' right.

I am an amateur programmer, self-taught. I learned Python, Glade, Git only to help with LCNC maintenance. I am only interested in Gmoccapy, Mesa 7i96 + doughter cards, PncConf. When I saw QT in Gmoccapy, I was scared that I would have to learn another technology, even though I know the others only minimally. I didn't want to hinder development, but if it is possible to continue maintaining/improving Gmoccapy without other new technologies for me, it will help me.

[c-morley]

Where should the common flles go ? python/lib/common?

[c-morley]

When I maintain a GTK based gui like Gmoccapy I should never have to deal with something in a folder

called 'qtvcp', 'touchy', 'stepconf' or 'plasmac'.

I guess this hard line just doesn't apply in my mind. Qtvcp use hal_glib which is gtk/GObject based.
I did this on purpose so as not to double the effort creating a PyQt version of hal_glib.
It also helps that whenever anyone fixes/improves hal_glib all the projects that use it are fixed/improved.
The docs for libraries Gstat (GladeVCP ) and STATUS (Qtvcp) signals and functions are virtually the same.
Much easier for a user/developer to move between the two toolkits.

[Sigma1912]

Where should the common flles go ? python/lib/common?

yes