MonoKrom - QtPyVCP GUI for PlasmaC and Mill

I'll start thinking about a security model.  I assume it doesn't need to be too clever.  It's not look we are trying to stop elite hackers here is it.

On the buttons front, if we can identify key functions (like park) then we can probably put them in a place that makes sense for the vast bulk of workflows.  Custome buttons are nice but placement in a useful place gets challenging with limited screen realestate.

If we can agree to a 1080p size then we can do a lot and get a lot on a single pane of glass.  However if the UI needs to work on 1280 x 720 it's gonna mean a lot of stuff is going to get "hidden" in tabs or outright dropped.
I just did a quick scan down newegg on toouchscreens and 80-90% of them from large down to 11" were all 1080p res.  Starting to think I am over constraining this UI.

Anyone got a voew on a lower common screen res size to target?  Maybe we build for 1080p, get all the bits we want then do a second UI that is essentailly a reorgnasition of those master elements into a smaller resolution space and/or vertical orientation?

Cheers - James.

 

I had a look at asus and all their touch monitors were 1080p.
I had a look at an industrial monitor supplier and you had to get down to a 10" monitor to go below 1080p
Asus have a nice little  15" monitor I have a couple of.
I'd go for 1080p

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.

KCJ wrote:

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.
 

Cheers - will run with that.  It was also my preferred path and will be way quicker to implement.

Stage 1 on security feature done and pull request raised to framework. This supports trapping the security level against a widget via Designer.

As for the behaviour side of the implemnetation I am thinking doing this via a plugin is the correct pattern.  This way it's not there as standing overhead and can be enabled by a UI designer via the UI's yaml config file.