MonoKrom - QtPyVCP GUI for PlasmaC and Mill

Thanks Rod.  I agree.  So will start that transition.  At the momen I am in the middle of wiring up the filters and the cut parameters to the DB.
Status is:
- filters all wired up and populating correctly
- "static" filters that are more table/shop specific and wont change once set have beenn moved off to a config/setting area.
- filters working correctly as selects so once all set they they will delivery a valid cutset of params for that combination or note that this combinaion is a "new/blank" setup. The intent being that the "new" button would become active, if the user has the rights to create new content
- started wiring up the cut params to DB

todo: I want to make the filters persistent between software starts. This would allow a set of filters that are used day on day to be set and just left and when the software starts up that selection will be in palce and the cut-params all populated. This will also tie in to operater control abilities.  As these filters could be locked down, making the machine specifically configured for a certain cutting setup.  This would probably need to be linked to a default program or set of programs that can be run on that machine.  But getting a little ahead of myself. 


Cheers - J.

Saving the defaults would not be hard. just make a new database table called control and make it contain only one record being the company defaults. Include the keyIDs  to the required tables to load are saved there. On startup, retrieve that record and the cut parameters.
Thats pretty standard for business applications.
If its like QTvcp, you probably have the startup and shutdown procedures and data persistence already built, not counting the SQL stuff..

Just thinking about permissions, I remembered something.  You could number each window/section/field sequentially and fold these numbers into a bitmap. Then you could add user groups and user tables. Retrieve the permissions bitmap on login and then hide or display windows/sections/variables based on that bitmapped value. A 64 bit bitmap is a lot of granular permissions! Sounds like it belongs in QtPyVCP 

for the specific table save/load certain ket data is pretty simple as the widgets are their to support it.  I have had to extend  on this for some where the widgets also need to expose hal pins to support connections to plasmac.  So all doable and already partly done for some fields.   Just time to get to things.

Granular permissions will be some work as it's not a concept that exists at the moment.  The key part will be enabling/disabling fields.  As soon as you start to hide stuff the UI layout starts to change with some potentially unpreidicatble results.  Stopping stuff being changed or pushed is usaually just a case of disabling the field.

The bit map idea sounds promising.  I can see how that could work I think.  Just need to consider how to implement from a code angle.  The nice part is it will be pretty easy to scan through all widgets and test if they should be enabled or not. I wonder if having something built into the base widget class on this would be the better path. Define security concepts into the framework widgets.  Of course that does mean that anything which needs security type control has to be a qtpyvcp widget and not a generic qtbutton etc.

 

Joco wrote:

for the specific table save/load certain ket data is pretty simple as the widgets are their to support it.  I have had to extend  on this for some where the widgets also need to expose hal pins to support connections to plasmac.  So all doable and already partly done for some fields.   Just time to get to things.

Granular permissions will be some work as it's not a concept that exists at the moment.  The key part will be enabling/disabling fields.  As soon as you start to hide stuff the UI layout starts to change with some potentially unpreidicatble results.  Stopping stuff being changed or pushed is usaually just a case of disabling the field.

The bit map idea sounds promising.  I can see how that could work I think.  Just need to consider how to implement from a code angle.  The nice part is it will be pretty easy to scan through all widgets and test if they should be enabled or not. I wonder if having something built into the base widget class on this would be the better path. Define security concepts into the framework widgets.  Of course that does mean that anything which needs security type control has to be a qtpyvcp widget and not a generic qtbutton etc.


 

You keep plodding along and I'll come up with the ideas

Thinking about the security question a little more.  When it comes to setting what fields/buttons/sliders etc can be changed by what operator leve, does that need to be:
a. configurable outside of the UI design file or,
b. can it be baked into the UI?

#b later being much simpler but less flexible than #a.

Asking as it has a fundamental impact on how to design for this and how much effort and complexity will be introduced.  If you say an OEM is expected to set this up beyond a standard UI setup then you can assume the OEM wull open the UI file in Designer and go through and set/adjust the default security levels on each interactable field.  This is arguably "better" in that whoever is editiing the UI file can see clearly what field they are adjusting.  If using some kind of mapping/config file then there will always be some interpretation as to what field is being referenced by the config file AND it is another element to keep in synch as the UI evolves.

Interested in views.

Thanks.

I would suggest having the access level set in designer. This makes it easier from a editing standpoint, and also harder for somebody to change permission levels.