GScreen and some understanding gap of hal-widgets

sad

Not really
I have both variants on disk, so switching is not an issue.

My problem is: I have no idea how to differentiate between my mistakes and linuxcnc bugs

Reinhard wrote: self.widgets.work_GCodes.buf(self.widgets.edit_GCodes.buf)

try this (I haven't) in your __init__ function:

self.widgets.work_GCodes.buf = self.widgets.edit_GCodes.buf

I suspect it won't work as you hope, but there shouldn't be an error.
If it doesn't work - it means it would require so reorganizing of the sourceview widget to allow a buffer to be changed after initialization.

Chris M

If fixed the 'bar' problem - though it the colors don't change for me - it seems it's a known problem in some themes. ProgressBar is not the preferred widget, bars are:
linuxcnc.org/docs/devel/html/gui/gladevc...ml#gladevcp:hal-bars
I'm guessing because of the color problem.

display_units : GLADE is a bit limiting on how the editor renders data types: BOOL data is always a toggle button. yes we should change the tittle or pop up text.

expensive timers: yes Gladevcp was the first try at widget editors so things are not as efficient as possible. (qtvcp is better in this regard) but it's the graphics plot and sourceview editor that are CPU intensive (based on reports of low powered machines)
Someday when we update gladevcp to python3 and gtk3 then will will switch to using the Gstat library to watch linuxcnc and only update what needs to be done (that's what qtvcp does)

Those errors shown from GLADE editor are not important - as you noticed, it's because linuxcnc is not running, so no INI file.

Sourceview buffer - I'd have to research a bit - I'm sure you can share a buffer.

The other handler file errors - with verbose - you will get all kinds of error messages that are unimportant, because it shows info from all of the 'try except' statements. Some errors are hard to find because they are hidden by the' try' statement and that is when verbose should be used.

Chris M

F{}@!\k - I broke my environment by the try to step back ...

expensive timers: yes ...

Ok, so if my feeling was right, I would prefer to go ahead and work on bugs and improvements.
My mill is not ready yet, so I have time to dedicate myself to userinterface ...
I prefer to go ahead instead of stepping back.

@Chris
with your help I would change widget code and try to improve them.
I don't know linuxcnc, python nor imperial habbits, but I will try to get it work for me.
Then I could offer you the changes, so you could check what will be useful for you.
Is it ok to continue with my questions?

I could restore a backup and can continue work.

self.widgets.work_GCodes.buf = self.widgets.edit_GCodes.buf

I suspect it won't work as you hope, but there shouldn't be an error.

You where right - it does not work. So I'll gona try another option.

I tried to add a bitmap/picture to a button - and it did not work either.

Then I played a bit with actions. An action has a label and as far as I understand the flyover help, this label should be used on buttons or menueitems.
I checked it together with a butten and the label of the action was not used.

... and how can I extend the behaviour of an action?
I use an action with a button to load a gcode file. That works fine so far.
But I'd like to display the filename in another widget.
My handler has no connection to the action and changing the action code to add the labels name seems wrong to me.
So how and where could I add a callback or trigger?

darf ich fragen in welchem kenzeichenbereich du dich befindest

und um welche art maschine es sich handelt