Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

improvements to ZoomLast, ZoomNext tools (extent history) #11776

Closed
qgib opened this issue May 26, 2009 · 10 comments
Closed

improvements to ZoomLast, ZoomNext tools (extent history) #11776

qgib opened this issue May 26, 2009 · 10 comments
Labels
Feature Request GUI/UX Related to QGIS application GUI or User Experience
Milestone

Comments

@qgib
Copy link
Contributor

qgib commented May 26, 2009

Author Name: Steven Mizuno (Steven Mizuno)
Original Redmine Issue: 1716

Redmine category:gui
Assignee: Marco Hugentobler


I have found the addition of the view extent history using the [[ZoomLast]]/ZoomNext tools to be very useful. However, because there was no status indicated on the buttons it was not easy to tell whether there was an extent to zoom to.

Also, I found that loading a project did not set its extent in the history list.

I believe the extent history should be cleared when a project (new or existing) is loaded because the map extent is set to the extent of a project or the first layer loaded making this point the logical beginning for the extent history.

Some people might argue that the previous view extents might be useful with a new project or even an existing project, but I believe that it is more likely that these extents are of little use.

Note that on program start, the map extent is set twice - once by fileNew, then by the command-line extent processing - so there are two extents in the history instead of one.

I provide a patch to do the following:

Improvements-

  • to make the [[ZoomLast]] and [[ZoomNext]] buttons show whether there is an extent to zoom to (in various functions, signals are emitted to update the button state)

  • provide a new function to clear the extent history and set the current extent as the first item: [[QgsMapCanvas]]::clearExtentHistory()

  • clear the extent history on new project (this is mostly cosmetic as other actions will also clear the history)

  • clear the extent history when the first layer is loaded

  • clear the extent history on project loading (the extent is set in [[QgsMapRenderer]], but the list of extents wasn't updated)

minor updates in [[QgsMapCanvas]] -

  • in zoomToPreviousExtent() and zoomToNextExtent(): refresh() was moved inside the if block so that it is called only if there is a previous or next extent (this doesn't mean much when the now disabled button won't allow a click event in such a case, but was an unnecessary map redraw before the button got status indication)

  • in zoomToPreviousExtent(): mLastExtentIndex was tested for >1 -- it should be >0.

qgsmapcanvas.sip is updated for the new function and signals, so Python can make use of them.


@qgib
Copy link
Contributor Author

qgib commented Jul 18, 2009

Author Name: Paolo Cavallini (@pcav)


Any objection in applying this patch?

@qgib
Copy link
Contributor Author

qgib commented Aug 1, 2009

Author Name: Giovanni Manghi (@gioman)


Hi,

I tried your patch, I applied it and qgis compiled fine and worked the first time, then it started to giving me segmentation faults when launching the program.

Can you please check it? Thanks

PS
it is supposed to see different zoomnext soomlast buttons if there is an extent to zoom to?

@qgib
Copy link
Contributor Author

qgib commented Aug 3, 2009

Author Name: Steven Mizuno (Steven Mizuno)


Replying to [comment:3 lutra]:

I tried your patch, I applied it and qgis compiled fine and worked the first time, then it started to giving me segmentation faults when launching the program.

I have most recently applied the patch to and has been working OK on my Windows system. It has also worked on a Linux system, but I haven't tested it recently, due to problems with that system. Were you applying the patch to a more recent version? I will check further.

it is supposed to see different zoomnext soomlast buttons if there is an extent to zoom to?

The buttons should be enabled when there is an extent in the queue to use whichever direction you are navigating. The buttons are disabled (grayed) when you reach either end of the extent queue. There aren't different icons, they are just colored or grayed.

@qgib
Copy link
Contributor Author

qgib commented Aug 4, 2009

Author Name: Giovanni Manghi (@gioman)


Replying to [comment:4 smizuno]:

I will check further.

thanks.

As a fact I applied the patch to a more recent version (I don't remember exactly, I compile from source very day), but I had to make some changes manually as since you posted the patch the code has changed, so it is possible that I made something wrong (I also didn't see any changes in the zoom buttons).

@qgib
Copy link
Contributor Author

qgib commented Aug 4, 2009

Author Name: Steven Mizuno (Steven Mizuno)


Replying to [comment:5 lutra]:

As a fact I applied the patch to a more recent version (I don't remember exactly, I compile from source very day), but I had to make some changes manually as since you posted the patch the code has changed, so it is possible that I made something wrong (I also didn't see any changes in the zoom buttons).
Upon applying the patch to I found that one part for [[QgisApp]] patches the wrong place which caused some null pointers that were used before being initialized. The part that was affected was where signals are connected. I can't figure out why the patch is applied rather than failing to patch.

I have created a revised patch file.

The zoomlast button will be enabled and the zoomnext button is disabled when QGIS is first started. If you load a project both buttons will be disabled until some zooming or panning is done. Then you can navigate the history of the zoom/pan with the buttons.

@qgib
Copy link
Contributor Author

qgib commented Aug 4, 2009

Author Name: Giovanni Manghi (@gioman)


works for me under 951d2a5 (SVN r11271).

Thanks!

@qgib
Copy link
Contributor Author

qgib commented Nov 24, 2009

Author Name: marisn - (marisn -)


Works just fine with trunk 0dd2615 (SVN r12241) (some parts fail to patch, still can be merged manually). This patch is a must for next release :)

Python changes not tested.

Only feature that seems to be missing for previous/next is automatic re-projection of history extents on projection change event with OTFR enabled. Test: Add data, zoom in/out, pan, enable OTFR to different CRS, zoom previous/next still will use old CRS extents :(

@qgib
Copy link
Contributor Author

qgib commented Nov 27, 2009

Author Name: Steven Mizuno (Steven Mizuno)


Replying to [comment:8 marisn]:
While I was only fixing the extent history mechanics to enable/disable the buttons and track the history correctly, I considered what happens when the map CRS is changed.

While it would be a good idea to have the extent history track the map CRS, there are situations where a previous extent could 'blow up' a CRS transformation. This should be trapped so it doesn't cause a segfault, be what should QGIS behavior be in this case? Doing nothing is confusing. Popping an error dialog gets really annoying after the first one.

The most common scenario I have seen is forgetting to set the map CRS before loading data that has a UTM projection, for example, after starting QGIS. In this case the extents are more correct for the UTM, not the default EPSG:4326, if the map CRS is now changed to UTM. The extents are likely way out of bounds, as well.

I almost put a clear extent history on map CRS change, but decided not to because that behavior could be confusing and annoying.

I believe that all consequences of map CRS change on the extent history should be considered before doing anything further.

@qgib
Copy link
Contributor Author

qgib commented Nov 27, 2009

Author Name: Steven Mizuno (Steven Mizuno)


I recently found a minor problem setting the last index incorrectly in certain situations, which has been fixed in my second updated patch.

Since it has been some time since the previous patch was submitted, several parts now fail in patching due to changes in the surrounding original source, I have revised the patch so 2d29650 (SVN r12263) is the base.

@qgib
Copy link
Contributor Author

qgib commented Nov 28, 2009

Author Name: Marco Hugentobler (@mhugent)


Applied in f81780d (SVN r12280). Thanks!

Marco


  • resolution was changed from to fixed
  • status_id was changed from Open to Closed

@qgib qgib added Feature Request GUI/UX Related to QGIS application GUI or User Experience labels May 24, 2019
@qgib qgib added this to the Version 1.4.0 milestone May 24, 2019
@qgib qgib closed this as completed May 24, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature Request GUI/UX Related to QGIS application GUI or User Experience
Projects
None yet
Development

No branches or pull requests

1 participant