SCREEN_CONTROL_LAST_SETTING usage

Interesting.  Thanks for the insight, I will try to digest that over the next few.  You did just give me an idea for a much cleaner way to apply the “switch to Z first” workaround, since the grid shouldn’t show in P view.

It’s also interesting that I can get around the grid being disabled in a P related view.

One thing I noticed today is that the view is not correctly saved if you had a Z view applied, rotated the view, and clicked to SET the view. This is because it records '-user-view' as z instead of p.

I am not really sure how to do it, but it would seem that this is already tracked in glnav.py with self.perspective which is true if you rotate, or have a P view, but false otherwise.

A way to fix this, it would seem, is that when gcode_graphics.py records the view, if self.perspective from glnav.py is true, then '-user-view' should be p. Otherwise, '-user-view' should be whatever is reported back.

Sorry, it would have been helpful for me to mention that I did experiment with it, and it appears to work correctly.  

Here's a video showing what I mean:  

Happy to help, I think user view definitely has merit and is useful.

in glnav.py, perhaps they use the wrong term, but they seem to call anything that has any rotation a "perspective" view. self.perspective is true for "set_view_p" and "rotate" functions. All others (x, y, y2, z, z2) set self.perspective to false.

As for the grid, I see what you mean about it being disallowed. I don't know why because it's definitely possible for it to be shown at all times, furthermore, when you rotate from a Z view (for example), it stays shown.

I would love to test out if there are any ramifications for leaving the grid shown in the p view... The way setting P kills the grid feels wrong.

Thanks for pushing that change Chris. Works well!

I've done some more digging and I've come up with two things, neither have specifically to do with User Views, but both have to do with QTVCP's handling of the preview. I find that I find most "bugs" when I set out to do something else, and am not really looking for them (sorry about that haha).

The things:

1. When rotating from a Z view, the "Z" label on the origin disappears. This does not happen if you rotate a P view. I believe this to be part of how QT does the preview window, because I can not duplicate this in Axis, but I can in both QtPlasmaC, and qtaxis.

2. As for the grid, I discovered that neither QtPlasmac, nor qtaxis actually follow what Axis does. In Axis, the grid is shown in any view that has no rotation (X, Y, Z). As soon as any rotation happens from any of those views, the grid disappears. In QtPlasmaC and qtaxis, the grid is allowed to stay when rotations happen.


Further info on the grid stuff that relates to QTVCP screens currently that I gathered before discovering #2 above (so perhaps it's irrelevant now, but I wanted to get it out there nonetheless):

I spent a fair amount of time messing with glcanon.py and the grid today to try and ascertain why we wouldn't want the grid shown in a P view, since, at least with QTVCP screens, it's valid to have the grid shown during any other rotations.

First, the "if view == p: return" line was added with commit 43eda79 by ddjepler. Near as I can tell, this is the commit that first added the ability to show a grid in the preview window.

I think a reason that the grid is not drawn for P views is simply because the math is for X Y Z, and it was an easy way of handling it. The code always draws the grid perpendicular to the chosen view. Another reason might be that maybe it was seen as not necessary? If you're using the grid for scale, it's hard to count the blocks when the view has any rotation. Finally, a third reason might be graphics performance?

At any rate, for QtPlasmaC and qtaxis, it does work to default the grid to the Z "floor" by changing line 1020 in glcanon.py

From:


To:


But overall, maybe the best solution is to "fix" QTVCP's handling of the grid so that it disappears on rotation like Axis (and presumably the other screens, though I did not test any like gmoccapy, etc.).

Figured I'd report back with one more thing that Phill noticed last night.

The user view settings seem to be referenced to the X0 Y0 coordinates of the loaded gcode file, and not the machine home location. So, if you have a user view made with no g-code file, and then load a g-code file, the user view will shift around depending on the X0Y0 location.

Hopefully this is helpful; I dont mean to be a PITA.

Perspective when zoomed in, mostly. Sanity check on size, distance to move, etc.

I wouldn’t say it’s strictly necessary, but I’ve definitely gotten used to it. It’s turned on for all of my machines.