qtvcp issues

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

Chris,

From your response:

"It seems you want them as permanent widgets, embedded in your stacked widget."

Yes that is absolutely correct.

I think of industrial applications where every thing is done on panels with buttons, switches and feedback that could be on a screen, button color changes or a change in a display value, and perhaps even an alarm hanging on wall that is sounding of somewhere distant.

Over time things have progressed a bit and many panels have been replaced by computer screens which caused the name of all the above items I mentioned to become the new internet computer age related term, "dialog".

I can say that I don’t like the word dialog much at all. For industrial applications there is likely a better term or terms that could be used. Can you envision yourself saying to your co worker, 'I’m going to look at my dialogs", instead off "I’m going to have a look at the status of my equipment".

That being said, when I refer to dialog it refers to a panel that has the desired information that needs to be looked at or modified by a user, and has the input capabilities that allows desired changes or entries to be made. It is also a panel that can be brought to the front in a specific location within a gui, and also be replaced in that specific location by other panels when other functions are desired to to be looked at or changed. It is thus embedded in the gui and thus part of the gui's internal panel stack.

If such a panel were to be used as floating on its own in screen space somewhere it would be considered as being a pop-up and should be referred to as being a pop-up to avoid confusion.

As an example we could have "panel_123" and "pop_up_123", same basic functions just a different name to clarify the intended use as being coded for embedded or to be used as a pop-up.

For a programmer the word "dialog" means ??
But for the user of industrial type equipment it likely means "Control panel".
Thus human engineering is a factor to consider and conflicts like this should be reduced at every level of development.

i agree with the problems of interfacing programmers/engineers/machinists.
In this case the reason it's called a dialog is that is what QT (and other toolkits) call 'pop ups'. - it's a programmers term.

There is a pretty good reason to use them - they hold information that needs to be addressed immediately or before you can do something else and the toolkit takes care of stopping the user from doing that something else on the main screen.
My idea to help this further was the focus widget that dims the main screen. (it's a little finicky to get to work). They also can popup automatically, as widgets they cannot - you must program the behavior.

Anyways I will work on making regular widgets of the other dialogs.
there is a FileManager, CamView, and a OriginOffset widget available right now.

Do you want an embedable tool change message or is the popup sufficient?
Oh mabay you are using an automatic tool changer- no dialog needed.

Chris M

Chris,

I’m not planning to use any pop-ups in the x1Mill gui so everything will need to be regular widgets.

I do need to be able to get a message up on screen warning that the machine was set to manual operation only and that CNC mode is not available. This is required to insure that the ball screw clamp on the Z axis gets re-tightened before cnc mode is set again. The Z axis linear glass scale is also used in manual operation mode.

As far as the F6 checks. I have done some but they have not worked for me at all so I will need too make sure that I’m using the proper configuration and the right file for the test.

Chris,

I figured out where you put the test file and to get to it. Here is the result of the F6 test

Oh sorry i forgot i didn't tell you were to look..
Ok now we know your system is capable of dialog placement.
Clearly now I see we were thinking on two different things
In the docs I will try to make it clear that dialogs are pop up devices.

Chris M

And pushing offsets gives this result;

that looks right the origin offsets should be placeable by the user and the tool offsets should always open at the top left.
Though I see the label at the bottom of the focus widget displays the wrong message.

f3 = origin offsets
f4 = camview
f5 = macros
f6 = tool offsets
There are other key bindings also.
all set in the handler file

Chris M

I have figured out why the gui would not allow me to move it to the edge of the screen.

This will not work now: DISPLAY = qtvcp -d -g 1024x768+0+0

But this will: DISPLAY = qtvcp -d -g 1024x768+1+1