SCREEN_CONTROL_LAST_SETTING usage

It's not actually a view, in the context of the way glcanon makes a view.
It remembers the last view selected and the mouse movements after that.
ie it selects a P view then left 20 units and rotate 10 units.
unfortunately using zoom in between messes it all up...

It's hacky but super useful.
But that means glcanon doesn't know there is is user view and so it can't be a default view.
We could probably hack that too, but at the moment i would like to assess how hack-but-useful the user view is.

I added it because it was annoying to get the view you wanted then when you did something that had to reload the view, I would have to reset the view again.

I had pieced together that might be how it works (the clue for me was tracking the z or p value), thanks for the insight!  It seems to work well, I noticed your note in the docs about setting and then immediately trying the view because sometimes it doesn't take.  I also noticed that about 1 in 30 tries it doesn't apply the view correctly for some unknown reason, maybe the zoom thing you mentioned.

At any rate, even if it is "hacky", I do find it super useful as well.  I like zooming to the extents when there is no program loaded.  I always find I zoom too fast and too far on the table, and having a button to click is pretty nice.

For testing and what not, I currently have it set so that upon completion of homing, it sets the view to the user view (if the user has chosen to make it the default view via preferences).  It seems to work well, but maybe there's a better way.

I don't know exactly how it works, but when you load a program, it automagically zooms to what seems like the extents of the boundary for the program.  I then wonder how difficult it would be to add an option to zoom to the extents of a bounding box created by the X and Y limits instead.  

Killing a little time waiting on Christmas Eve festivities to commence over here on the east coast of the US.  So Merry Christmas to anyone reading this!

Figured I'd take a minute and give an update... Adding the user view is officially in the pipeline, I definitely see value in it, and I think others will as well. Phill had a good idea for double clicking the button to change it to SET, so I incorporated that and it seems to work well. Also, I made it so upon clicking SET, it records the view, and then immediately applies it so the user can tell right away if it stuck or not.

A few comments from things I learned/saw during the process:

1. I wonder if anything can be done to make applying the view more stable? I am willing to do what I can to help here, if you can give me some nudges in the right direction as far as where to look, and how it's working/what the current programmatic issues are?

2. If you had the grid showing, and if you are in a P view, and change to the User View, the grid will not be displayed. However, I noticed that if you go to Z view first, then click User view, the grid will be shown. The current work around I've implemented is to switch to Z, then switch to User View, it seems to be unnoticeable, but wanted to report back on it in case it can be fixed at the source.

3. Along the lines with #2, but not having to do with User View, if you have a grid applied, when you click P, the grid will disappear. I've tried Axis, and this mimics axis functionality, but the thing that makes me question if it is correct is that if I do the following, the grid will be shown in a P view:

a. click P
b. set the user view to that view
c. apply the user view (which in QtPlasmaC's case, sets Z first, then applies the user view)
d. the grid will be shown in a P view

Anyhow, again, willing to help however I can, but some of this is probably over my head.

Thanks, and I hope everyone enjoys the holidays!

I am sure the view setting could be made better. I think it would take someone who understands openGL programming well. It seems very few linuxcnc developers do.
We in fact use 'old' opengl programming techniques - I'm sure mostly because of this.
I see Grotius built a graphics display alternative that might be a better in the long run and it's C++ based which could be faster. - it uses code that freecad uses for display.

The biggest problem I noticed is the zoom vrs panning.
We keep track of panning etc (translation is more accurate) just by keeping a running variable that gets added/subtracted to as we translate. (glnav's self._totalx, self._totaly)
But zooming changes the scale of these translations.
We really need to normalise the running translation variable or find a better way to track movement.
see glnav.py for base opengl functions and glcanoon.py for machine control related functions.

grid is explicitly disabled in P view as per glcanon.py draw_grid()
I don't know the reasoning.
The user view records the view at the time, so if it's P there should be no grid, if Z then there could be.
Technically the error is probably allowing rotation in Z view (so it seems like P view)

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.