GUI Framework

More
02 Feb 2014 20:57 #43432 by BigJohnT
BigJohnT created the topic: GUI Framework
I'm just thinking out loud here... and looking at the HAL Python and EMC Actions widgets in Glade is there anything missing from that set to build a full featured GUI? I don't see a menu bar for a mouse/keyboard type of GUI.

Just to break it down seems to me that there are two basic GUI's a keyboard/mouse and a touch screen. From that point the GUI's could need almost anything or almost nothing just depending one the machine function. I'm thinking of more than mills and lathes here even something as simple as a spool winder.

More rambling thoughts... seems to me a GUI will need a way to load a G code file and the EMC FileChooserDialog seems to fit the bill for keyboard/mouse but does not work for touch screens. Do we need to develop some touch screen widgets? I don't even know how to add a widget to Glade any more... I think Chris told me once.

JT
More
02 Feb 2014 22:57 #43436 by newbynobi
newbynobi replied the topic: 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
More
02 Feb 2014 23:51 #43439 by ArcEye
ArcEye replied the topic: GUI Framework

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
More
03 Feb 2014 00:05 #43441 by BigJohnT
BigJohnT replied the topic: GUI Framework
Hi Norbert,

Thanks for the link on Glade.

JT
More
03 Feb 2014 00:07 #43443 by BigJohnT
BigJohnT replied the topic: GUI Framework
Thanks for the link to glade ui.

JT
More
03 Feb 2014 01:58 #43456 by cmorley
cmorley replied the topic: GUI Framework

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
More
03 Feb 2014 04:09 - 07 Feb 2014 20:03 #43467 by BigJohnT
BigJohnT replied the topic: GUI Framework

cmorley wrote: 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 coolant and spindle would be handy...

Chris M


Should the "Add a Widget to Glade" target installed or RIP?

I noticed IconFileSelection still has a mouse scroll part, not much use for fat fingers. Big Up/Down buttons would be better.

Which multiple programs poll for errors and what do they poll if not EMCSTAT?

adding editing and searching to the source widget would be user friendly.


I don't follow this, can you explain?

I just tried to use the run from line in Touchy and that doesn't work. I think a separate widget for spindle and coolant would be more flexible. You drop in a container the spindle widget, coolant widget, and the run from line widget.

Is there any way at run time to "discover" what widgets are present in a GUI?

JT
Last Edit: 07 Feb 2014 20:03 by BigJohnT.
More
03 Feb 2014 06:13 #43469 by gww250
gww250 replied the topic: GUI Framework
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.
More
03 Feb 2014 07:01 #43470 by cmorley
cmorley replied the topic: GUI Framework
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
More
03 Feb 2014 21:43 - 03 Feb 2014 22:02 #43495 by BigJohnT
BigJohnT replied the topic: GUI Framework
I was amazed how easy it is to add to the Glade widget to the pallet ... only took me an hour to decipher the secret code this morning and add a useless widget and category.

Edit: I just noticed that Master has many more widgets than 2.5.x..

JT
Last Edit: 03 Feb 2014 22:02 by BigJohnT.
Time to create page: 0.079 seconds
Powered by Kunena Forum