GUI Framework

Hallo JT,

this is the beginning of custom glade widgets: Custom Glade Widgets

But it is not very well documented, the part of adding the Gui to the XML File give lots of error possibilities.

As touch screen file selection, look at IconFileSelection, it is the one I made for gmoccapy.

We do miss a dial widget and a complete stand alone error handling, my notification of gmoccapy may be a point to begin.

As I am just splitting gscreen and gmoccapy to be two different GUI, and also planing the industrial version of gmoccapy (luminos) I unfortunately will only be able top help in part time.

Norbert

this is the beginning of custom glade widgets:Custom Glade Widgets
But it is not very well documented, the part of adding the Gui to the XML File give lots of error possibilities.

Also see here developer.gnome.org/gladeui/3.6/catalog.html

I have written about 3 dozen custom HAL widgets for Qt recently, but unfortunately there is no common ground.
Qt uses compiled plugin libraries for Designer, any superficial similarities between that and glade soon disappear upon inspection.

My widgets are for QtVCP panels, to replace pyVCP and avoid glade.
I use them myself but don't know if I would want to bother trying to publish and support them.
At their simplest they are just button and LED panels, but if you want to, you can control program execution and the machine directly.

The building sequence could be similar for your GUI framework.

First step, I subclassed a MainWindow to a specific HAL class and this is the base of all panels.
All the HAL and NML access functions are available through this class and it takes care of initiation of the component and registering with the running lcnc process.

This class then parses through the Designer ui file and picks up all the child widgets within it. It creates HAL pins for them and sets up a handler for data entries / updating etc
It refreshes / checks all the handlers on a timer poll
If needs be it can run the associated hal file through halcmd, to make all the connections once the pins exist

Some widgets just display or receive data, but others have built in access to HAL/NML and carry out specific functions. EStop button, MDI command line widget, for example.

Something along those lines, with a base class which does all the work in the background, decorated by the user with child widgets to perform specific functions, is one way of getting the framework you are looking at.

With python you are at a bit of an advantage, because the run time compile nature makes dynamic creation easier, I had to come up with cunning pre-compilation strategies to do the same in C++

regards

newbynobi wrote:

Hallo JT,

this is the beginning of custom glade widgets: Custom Glade Widgets

But it is not very well documented, the part of adding the Gui to the XML File give lots of error possibilities.

As touch screen file selection, look at IconFileSelection, it is the one I made for gmoccapy.

We do miss a dial widget and a complete stand alone error handling, my notification of gmoccapy may be a point to begin.

As I am just splitting gscreen and gmoccapy to be two different GUI, and also planing the industrial version of gmoccapy (luminos) I unfortunately will only be able top help in part time.

Norbert

We should probably add that widget tutorial to the manual..
IconFileSelection works well though it doesn't support filters programs (could be added)
I think we should extend the EMCSTAT object to watch / send more events, such as error messages.
This would avoid multiple programs polling.

jogging controls would be nice widgets.
adding editing and searching to the source widget would be user friendly.
a run-at-line dialog with buttons to set collant and spindle would be handy...

Chris M

Most post processor I've worked with read the xml meta file of the drawing to extract key components so I think it would be relatively easy to 'find' the widgets present at run time in a ui.

add a widget tutorial probably should target RIP but installed is the same - just put in different places.

I agree about the scroll bar - a different theme can make the scroll bar larger, which helps.
I have a custom theme that makes them very much wider.

When i said emcstat i meant the widget emcstat (hal_stat in the source)
it polls linuxcnc about certain states and sends Gobject signals that widgets can connect to

Right now many of the custom widgets poll linuxcnc them selves.

editting and searching in the hal_sourceview widget (sorry didn't use the full name) to allow searching and editing of Gcode.
Gscreen does this but a widget would be more convenient for screen builders.

Not sure about TOUCHY run from line.
One of the big problems of run from line is that it doesn't restart the spindle or turn the coolant on again.
adding convenience buttons to a dialog would be helpful.
These would not be the general way to start the spindle or coolant.
better would be to re-parse the Gcode to see what the status of spindle/coolant were supposed to be...

discovering widgets is possible by trying to referencing them.
if it errors then the widget is not available.
add a try except so that the user doesn't see the error.

Gscreen does this for several objects.

I think building some basic widgets to do 90% of what users usually want is realistic.
This allows true drag and drop building.

beyond that allowing the user to add python code, allows then to do anything else they would like.

This is what Norbert did with Gmoccapy. He started with Gscreens framework and widgets and added python code to get the behaviour he wanted.
Then he build more custom widgets and python code.
At this point he basically only use gscreen to load the glade file and python code, almost everything else is his code.

Gaxis is a skin example that uses many custom widgets and very little python code.

Chris M