GUI Framework

IconFileSelection works well though it doesn't support filters programs (could be added)

Is filter programs the filter for file extensions? If so, IconFileSelection does support those.

See property "filetypes"

Norbert

No I meant program filters like AXIS and gladevcp has.
www.linuxcnc.org/docs/2.5/html/gui/axis.html#_program_filters

Chris M

Halo Chris,

I took a look at the filters program part. It is completely different to my reasons to code the IconViewSelection widget. It has been designed to select a file and return the file path. It should not do anything else. If you want a more specialized widget for your purpose, then I would recommend to add an additional widget.

It would be a pitty, if we can not use this widget to code something outside from linuxcnv.

IMHO the most needed is to rework hal action and hal stat and some other stuff, so there is no more need to run many timers, most could be done by one. There should be integrated a uniform api for the communication of GUI with linuxcnc, as at this time an y GUI seems to have it's own way to get in contact with the linuxcnc module.

Norbert

Yes we could probably build a filter-ized one by wrapping your widget in another layer of python.

hal_glib which contains Gstat could be expanded to be more glue between gui's and linuxcnc and widgets, using more GObject signals.

We do this already - eg HAL_Gremlin is connected to Gstat to find out about loaded files.
for instance I probably could have had HAL_gremlin go though Gstat when the line are selected.
This could have directed Gstat to emit 'line_changed' which automatically would have updated the sourceview widget highlight.
The you wouldn't have to manually add the signal and python code to do it and then only Gstat does polling.
I am wondering if Michael's Zmq work will collide with this system though.
I had planned on looking at Gstat in 2.7

Chris M

Halo Chris,

I do agree in most, but not in all!

Yes, we should have all the widgets to be able to react to emitted signals, and some / many will need the possibility to send signals.
Hal Actions and Hal _stat should send and receive signals, so a user may react to that signals.

But I would not like to see "autoconnecting" the widgets each one by themselves.
I do not like at all the behavior of hal_mdi_history and friends which are now not sensitive if not homed and so on, IMHO that is exactly what the GUI should to, take care to allow only reasonable actions and hide or forbid stupid behavior of the user

I would have preferred, make this selectable, in my init_hal:mdihistory I would have cut all connections to gstat, as they really are not needed, (by the way we also do not need import gobject, or am I wrong!?)

Why does tooledit widget need a timer? It should just send a signal, when something changed and receive a signal from gstat (tool in spindle changed,offset_canged etc.)

Same happen for the offset widget, it also has a timer, and IMHO it could also done with signals.

Please don't see my comments as to much criticism, it should only reflect my opinion about the way we should take.
My dream would be a GUI /linuxcnc only working with signals, no timers in the GUI and all this being able to be controlled with a simple protocol....

But it is only a dream and unfortunately I am busy enough at the moment with gmoccapy development, as there is only the WIKI as documentation, it will be needed to write a complete handbook for the GUI and I also want to include a shop programming system, an error pin, reacting to user errors, a matrix_hal_pin component able to control whatever function you like........

Shit, I just took a look on my ToDo List, will I ever be able to finish the list

Norbert

The idea of MDI_history and friends is stock widgets that do the most expected behaviours.
When a widget function is not available it should indicate this (eg by desensitizing)
When I click on the gremlin plot line I would expect it to highlight the code in sourceview.

If we want true drag and drop screen building capability this auto connecting has to happen.

Adding switches to widgets to change behaviour is an ok option to keep them flexible - gremlin has use_default_controls for this reason.

But if you want specific behaviour you can always program it directly rather then using the widget.


Tooledit could be auto connected to Gstat to receive a signal to allow editing - it was built before I knew of the capability.
offsetwidget could connect to Gsctat, and remove the timer too.
This would be part of the work to utilize Gstat better.

The offsetpage widget has a different reason for the timer. linuxcnc stat only gives access to the offsets of the current user system.
offsetpage gets around this by reading the vars file directly. The is no mechanism to tell us when the file has changed so we must poll it.

Yes there is always too much to do

Chris M

On the hal history widget maybe it would be a nicer look to just desensitize the entry on the bottom rather then the whole widget?

Chris

Halo Chris,

On the hal history widget maybe it would be a nicer look to just desensitize the entry on the bottom rather then the whole widget

I would prefer to get the whole widget desensitized, otherwise the users will try to execute a command by double click, what by the way should be possible if sensitized!

And yes, please add a switch to disable auto-connect signals, so it is up to the user how to handle the signals, i.e. in between a popup window or what else. I agree that default should be "Autoconnect enabled"

The offsetpage widget has a different reason for the timer. linuxcnc stat only gives access to the offsets of the current user system.
offsetpage gets around this by reading the vars file directly. The is no mechanism to tell us when the file has changed so we must poll it.

I can not follow in that one. The user should use touch off button or set the values with dialogs or what else, all this only for the active coordinate system, so we would be able to track that ones, correct from my side?

If the user wants to edit other offsets than the actual one, he should use the offsetpage widget, so we notice that one too!

Every time he enters the offsetpage, with a click or what ever, we just do read again the file, so why a timer?

If the offsets would be eddeted in any other way, the user must know, what he is doing!


Or even better, we do modify linuxcnc.stat to handle all offsets.

Norbert

newbynobi wrote:

Halo Chris,

The offsetpage widget has a different reason for the timer. linuxcnc stat only gives access to the offsets of the current user system.
offsetpage gets around this by reading the vars file directly. The is no mechanism to tell us when the file has changed so we must poll it.

I can not follow in that one. The user should use touch off button or set the values with dialogs or what else, all this only for the active coordinate system, so we would be able to track that ones, correct from my side?

If the user wants to edit other offsets than the actual one, he should use the offsetpage widget, so we notice that one too!

Every time he enters the offsetpage, with a click or what ever, we just do read again the file, so why a timer?

If the offsets would be eddeted in any other way, the user must know, what he is doing!


Or even better, we do modify linuxcnc.stat to handle all offsets.

Norbert

Offsets can be modified in the Gcode.
Offsets can be changed in MDI.
Offsets of other user systems can be changed without changing to that user system. (so you must check the vars file)
Linuxcnc does not send any signal when offsets are changed (that would be nice) so offsetpage polls to see if they changed.
These are other reasons why it polls.
To have a widget that can display the offsets wrongly unless you set the offsets only though the GUI mechanism is trouble waiting to happen.


Chris M