SCREEN_CONTROL_LAST_SETTING usage
- snowgoer540
- Topic Author
- Offline
- Moderator
Less
More
- Posts: 2388
- Thank you received: 779
18 Dec 2021 20:14 #229429
by snowgoer540
SCREEN_CONTROL_LAST_SETTING usage was created by snowgoer540
I am trying to figure out how to use the following items from the preferences file. No matter how I manipulate them, the graphics preview window loads the same way:
Perhaps I am missing something?
What I am trying to accomplish is having the zoom level be "zoom all" and display the entirety of the machine's extents when the GUI starts, or when no programs are loaded, etc. Any ideas otherwise?
[SCREEN_CONTROL_LAST_SETTING]
conv_preview-user-view = p
conv_preview-user-zoom = 10.0
conv_preview-user-panx = 0.0
conv_preview-user-pany = 0.0
conv_preview-user-lat = 0.0
conv_preview-user-lon = 0.0
gcodegraphics-user-view = z
gcodegraphics-user-zoom = 10.0
gcodegraphics-user-panx = 0.0
gcodegraphics-user-pany = 0.0
gcodegraphics-user-lat = 0.0
gcodegraphics-user-lon = 0.0
Perhaps I am missing something?
What I am trying to accomplish is having the zoom level be "zoom all" and display the entirety of the machine's extents when the GUI starts, or when no programs are loaded, etc. Any ideas otherwise?
Please Log in or Create an account to join the conversation.
18 Dec 2021 22:25 #229442
by cmorley
Replied by cmorley on topic SCREEN_CONTROL_LAST_SETTING usage
From memory, the graphics screen is very stubborn about it's default display.
again from memory, loading a default program allows the preview to be set to a different default.
i remember investigating this (at the time just to get something besides 'P' to display) and i could not find what the secret was besides a default program.
This is deep in the underlaying common code. I believe AXIS works the same.
again from memory, loading a default program allows the preview to be set to a different default.
i remember investigating this (at the time just to get something besides 'P' to display) and i could not find what the secret was besides a default program.
This is deep in the underlaying common code. I believe AXIS works the same.
Please Log in or Create an account to join the conversation.
- snowgoer540
- Topic Author
- Offline
- Moderator
Less
More
- Posts: 2388
- Thank you received: 779
18 Dec 2021 22:56 #229448
by snowgoer540
Replied by snowgoer540 on topic SCREEN_CONTROL_LAST_SETTING usage
Yea, it seemed like it wouldnt be easy. No worries, it's not a huge deal, just was a rabbit hole I had started down.
What is the correct use for the [SCREEN_CONTROL_LAST_SETTING] stuff in the preferences file? I cant seem to get them to affect any change in the GUI...?
What is the correct use for the [SCREEN_CONTROL_LAST_SETTING] stuff in the preferences file? I cant seem to get them to affect any change in the GUI...?
Please Log in or Create an account to join the conversation.
18 Dec 2021 23:26 #229451
by cmorley
Replied by cmorley on topic SCREEN_CONTROL_LAST_SETTING usage
last settings - holds the user view settings - for the user view action button (if there is one)
checkout qtdragon sim for the userview setting/recording button.
checkout qtdragon sim for the userview setting/recording button.
The following user(s) said Thank You: snowgoer540
Please Log in or Create an account to join the conversation.
- snowgoer540
- Topic Author
- Offline
- Moderator
Less
More
- Posts: 2388
- Thank you received: 779
19 Dec 2021 00:18 #229457
by snowgoer540
Replied by snowgoer540 on topic SCREEN_CONTROL_LAST_SETTING usage
Thanks Chris, I’ll take a peep then
Please Log in or Create an account to join the conversation.
- snowgoer540
- Topic Author
- Offline
- Moderator
Less
More
- Posts: 2388
- Thank you received: 779
19 Dec 2021 15:44 #229493
by snowgoer540
Replied by snowgoer540 on topic SCREEN_CONTROL_LAST_SETTING usage
I've worked out the user button stuff, thanks for the nudge in the right direction. I am not using ActionToolButton though, in favor of two separate buttons, one to set the view stuff, and one to change to that view. Calling ACTION.SET_GRAPHICS_VIEW('record-view') and ACTION.SET_GRAPHICS_VIEW('set-recorded-view') respectively.
What I haven't worked out is how to have the user view be the default view on GUI load. It seems if you try to call the set-recorded-view before the graphics window is shown, it causes the works to crash.
Is there a way to do this? Since there are pyqtProperties, I thought maybe there was a way to do it with stylesheets, but nothing I tried worked. Hopefully I missed something simple?
What I haven't worked out is how to have the user view be the default view on GUI load. It seems if you try to call the set-recorded-view before the graphics window is shown, it causes the works to crash.
Is there a way to do this? Since there are pyqtProperties, I thought maybe there was a way to do it with stylesheets, but nothing I tried worked. Hopefully I missed something simple?
Please Log in or Create an account to join the conversation.
20 Dec 2021 03:42 #229537
by cmorley
Replied by cmorley on topic 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.
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.
The following user(s) said Thank You: snowgoer540
Please Log in or Create an account to join the conversation.
- snowgoer540
- Topic Author
- Offline
- Moderator
Less
More
- Posts: 2388
- Thank you received: 779
20 Dec 2021 11:21 #229551
by snowgoer540
Replied by snowgoer540 on topic SCREEN_CONTROL_LAST_SETTING usage
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.
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.
Please Log in or Create an account to join the conversation.
- snowgoer540
- Topic Author
- Offline
- Moderator
Less
More
- Posts: 2388
- Thank you received: 779
24 Dec 2021 21:10 #229925
by snowgoer540
Replied by snowgoer540 on topic SCREEN_CONTROL_LAST_SETTING usage
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!
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!
Please Log in or Create an account to join the conversation.
24 Dec 2021 21:58 #229928
by cmorley
Replied by cmorley on topic SCREEN_CONTROL_LAST_SETTING usage
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)
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)
Please Log in or Create an account to join the conversation.
Moderators: cmorley
Time to create page: 0.087 seconds