qtvcp issues

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

auto-mation-assist wrote: 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".

So lets talk Dialogs -
Dialogs are meant to be hidden when not being used and pop up if need with relatively small amounts of give-me-attention-now information. They are detached from the main window.
The idiom i envisioned was dialogs working with a focus (screen darken) widget to grab your attention.

It seems you want them as permanent widgets, embedded in your stacked widget. - which is fine but then you don't want dialogs.
I think I mentioned earlier that if you want regular widget versions i can add more (there some already) except for the file dialog, but i have that one figure out too.

But none of that has anything to do with the dialog not going where you want it (unless you mean you want it _in_ the stacked widget).
I'ved added a dialog that always is placed in position relative to the screen as a sample config -qtdefault.
press function key 6 - it will always opens (but hovered) on the top left of the screen. Does that work for you ?

yes the generalized dialog widget always open in the center of the screen - I really wanted this one to stay in center by default, but am having trouble deciding how to facilitate that. (right now it goes to designer placement by default).

I'll see about getting a file managing widget made soon.

Chris M

cmorley wrote:
press function key 6 - it will always opens (but hovered) on the top left of the screen. Does that work for you ?

What I mean by this is does the functionality work (not, is that what you want)

cmorley wrote: yes the generalized dialog widget always open in the center of the screen - I really wanted this one to stay in center by default, but am having trouble deciding how to facilitate that. (right now it goes to designer placement by default).

I meant that all the other dialogs are placed by default in the designer designated spot. the dialog_widget is always placed in center.

Chris M