qtvcp issues

Yes I also started thinking about what I was trying to do and it made no sense because there are controls in place that prevent anyone from doing that. Taking a break every now and then is a good thing and the results are often beneficial.

The Xembed widget is causing the window to not follow -g geometry.
Took awhile to find that!

In your handlerfile:
self.w.tooloffsetdialog_geometry_string='0 0 600 400 onwindow'
is spelled wrong (note the period added):
self.w.tooloffsetdialog._geometry_string='0 0 600 400 onwindow'
probably why it didn't work (I hope)

I see you loaded gobject for a periodic timer.
Use this instead:
STATUS.connect('periodic', self._periodic)

I'll have to look into the Xembed problem yet.
Chris M

Hi Chris,

Great work on Qt vcp, so easy to get up and going to develop a custom UI! I have one issue though that I hope you may be able to help with. In designer, or when Linuxcnc is trying to load a screen with the GCodeGraphics, they both crash with similar errors.

PyOpenGL is installed and working well.

Thoughts?

Thanks

Scott A

Scott

Glad you find it useful - that encouraging.

I'm sorry I have not seen that before.
Can you give more information on your system?

I see on the net that there was some problems in pyopengl that caused that error message but seems a long time ago.

Chris M

Darn, I totally missed that period in self.w.tooloffsetdialog._geometry_string='0 0 600 400 onwindow'. Perhaps new glasses will help.

Hi Chris,

People will think this is a strange one. System is Raspberry Pi 3. I am off loading the hard real-time work to a PRU via a custom SPI component.

On my virtual development environment there is no problem. Probably a driver issue with the RPi but the PyOpenGL demos are working ok on the system...?

Thanks

Scott A

Ok, after some more investigation it does not appear to be a driver issue. PyOpenGL gears.py demo runs at 60 fps and super smooth.

How to debug this one?

Thanks

Scott A

I'm a total python noob but mr google says:

"You MUST create a valid OpenGL rendering context before any OpenGL command will work. And don't forget to call wglMakeCurrent.
Placing OpenGL commands in a constructor is just as good as anywhere else."

How to check this for the GCodeGraphics widget?

Thanks

Scotta

Chris,

In ref to the 1xMill gui,

I have been looking for a reason why the dialogs are not showing up today. I was looking and some of the code in tool_offsetview.py and think I may have found the problem. I was thinking that these are being hidden and I can see this happening even with the qt designer when using its run feature.

I think that these dialogs are designed coded to float on top of a gui and be hidden under user controlled conditions and also perhaps under not homed and estop conditions. If this is correct then that presents a problem with gui's that have the dialogs layered in like the 1xMill gui with no need for the to be to be hidden at all. I’m not able to generate homing signals yet for testing.

Also while I was looking at the dialog_widget.py I have never seen it enter the: def geometry_parsing(widget, prefname): near the bottom of that file.

Here are some pictures from qt designer showing the tool_offset dialog partially showing in the lower rignt and when run mode is entered it is hidden. Perhasps that is the reason they are not looking at "onwindow".

scotta wrote:

I'm a total python noob but mr google says:

"You MUST create a valid OpenGL rendering context before any OpenGL command will work. And don't forget to call wglMakeCurrent.
Placing OpenGL commands in a constructor is just as good as anywhere else."

How to check this for the GCodeGraphics widget?

Thanks

Scotta

Sorry Scotta, I'm no OpenGL expert - I just ported code from GTK version of gremlin to QT (which was in fact code ported to GTK)
and have never used a Pi. It's been mentioned that the OpenGL code used is a very old API.

Chris M