This would indeed be useful. But it might turn out to be difficult to implement. I also wonder what to do with the scrollbars when the user scrolls past the image border.

Created attachment 75058 [details] [review]
incomplete patch against CVS

This is a simple patch against current CVS that basically just removes a call to gimp_display_shell_scroll_clamp_offsets(). It also simplifies the code a little but this simplification is only possible because of the missing clamp.

This patch depends on a fix that's in CVS and will cause display problems if applied to the 2.3.12 release. After applying the patch it becomes possible to scroll beyond the image border by using the middle mouse button or the Space bar and left mouse button. It is not complete as you can not yet scroll beyond the image border using the scrollbars. The scrollbars do also not behave correctly. The behaviour on zoom should probably be changed as well. I am only attaching this patch to allow people to give it a try and perhaps suggest how to improve it.

Some feedback would be nice here. We still don't know how the scrollbars should behave. Do other applications provide this functionality? How do their scrollbars behave?

OpenOffice Calc is a nice example. 

The area that's visualised by the scrollbars is at least as large as the active portion of the sheet (that is, the smallest rectangle that contains any cells which have been changed by the user - contain data or are formatted). Additionally, the current viewport is taken into account and the active portion is expanded to always contain the cells visible through the current viewport (on screen) plus some additional margin so that the scrollbar's thumb can never reach the end as soon as the actual end of the sheet hasn't been reached (256 columns wide and 65536 rows high).

So to take this metaphor into the Gimp, if any side of the viewport goes near the image border or beyond it, we should always add a margin of "virtual space" that is e.g. just one half of the current window width/height beyond the current view and all scrollbar measurements should be based on that.

To be more precise, we should always add those margins (even when being far from the image borders with a high zoom level, and merge it with the actual image size.

We can look at this as a bounding rectangle of a sum of two rectangles: the current window + margins and the current image size.

Created attachment 77055 [details]
Visualization of the bounding box idea

Here's the visualisation of the idea - the whole bounding box area should be the area on which scrollbars are based.

I don't see why the margins would have to be added always. That would make the scrollbars pretty much useless. You actually want to be able to easily determine what portion of the image you are looking at.

But there are ways to do that and I already know how. Just need to get the code right.

>I don't see why the margins would have to be added always.
> That would make the scrollbars pretty much useless.

Not really, if the "viewport + margins" area is contained inside the image area, the scrollbars represent the image properly.
When it isn't, the user has zoomed out considerably and should already have an idea of what portion of the image he's looking at.

If it weren't for the margins, scrolling beyond the image's borders would be much harder.

Two notes, this bug seems highly related to bug 66417. And a simple
way, based in how the app works (not spreadsheets in which you go
writing anything anywhere to make a "nice DB"), is to just have a
fixed padding on each border of window dimension/2. That way the image
pixels are always under the center of the window area.

*** Bug 66417 has been marked as a duplicate of this bug. ***

We are not going to need a configurable padding if we fix this bug. I have marked this bug as a duplicate.

*** Bug 437244 has been marked as a duplicate of this bug. ***

As suggested in comment #8, a good way to implement the scrollbars would be to have them behave as if image_width == true_image_width + window_width  (same for height). At whatever zoom level, the image padding dynamically adjusts to 50% of window dimensions. Getting the image border to the center of the window is enough--we don't need to be able to scroll WAY beyond the image border.

Sorry, what I meant in comment #12 by "true_image_width" is actually "image width as it is currently being represented on the display."

I tried Seth's patch in Comment #2 for the latest HEAD from 2007-10-25, it has no effect.  Seth do you think you can fix the patch to work with the latest source?  I don't mind trying it and offering improvement tips and bug testing.  This is a feature that I've wanted for many years and I know I'm not the only one.  It makes many graphics operations hard to do if you're zoomed into an image.

Hei guys!

I have used program for many yeas which allows over border scrolling. It is Autocad. Works greatly and I think that behaviour will work with GIMP also.

Basicly it is like this:

- with scrollbars you could move image beyond border to some limit if you are already near it. If you are zoomed close in the middle of image, you can't scroll with scrollbars to the border, but with Pan you can move image to side that you find borders and with Pan you can move so far as you like.

Pan means same than GIMP middle button (only with my settings?). You can move image from side to side with Pan. this Pan like functionality is in all Cad programs I have used, SW, Inventor, ProE, AutoCad, DWG editor, Progecad (Like acad, but was free). All has its own style which buttons is in use but functionality is the same.

Also you can zoom beyond borders with mouse wheel zoom. GIMP mouse wheel zoom works almost so great as acad does, but GIMP do not allow zooming beyond borders.

But if you try for instance ProgeCad, you'll see how this function has worked since something, maybe since -80's.
 

I believe that this functionality is crucial for working with GIMP after the user interface changes that landed in trunk over the last week. At least on platforms that keep utility windows above the image window, it is absolutely necessary to be able to move the image without being stopped by the image boundary. Increasing the priority accordingly. In my opinion we absolutely need this feature in 2.6.

The attached patch still applies with a minimal offset. Note however that all this patch does is to remove the limitation to the image extents when panning. It doesn't do the necessary changes to the scrollbars and there are issues when zooming in and out.

Created attachment 113197 [details] [review]
Overpan by  0.5 window size at both edges, with working scrollbars 

The 0.5 over-pan may not be enough but allowing the image to go entirely off display is not a good idea either. Over-panning is used to get away from edges so being able to pan image edge closer to window edge is IMHO only confusing from a certain point.

Created attachment 113200 [details] [review]
Correts an issue with <1 zooms and scrollbars.

Now scrollbars should work perfectly. 
What this patch does not handle is offset translations at zooms and the small navigator widget. Theres no point IMHO in working on those before this parts approach is either accepted or rejected...

The patch works great and the scrollbars give a much better result now, scrolling to the end gives the expected result.

I'm assuming the 'offset translations at zooms' is to avoid the edge being re-centered when using the Zoom Tool, other than that and of course the navigator widget this patch is excellent.

Great work, this will be a huge time saver for me!

(In reply to comment #19)
> Created an attachment (id=113200) [edit]
> Correts an issue with <1 zooms and scrollbars.
> 
> Now scrollbars should work perfectly. 
> What this patch does not handle is offset translations at zooms and the small
> navigator widget. Theres no point IMHO in working on those before this parts
> approach is either accepted or rejected...
> 

How this patch could be installed? I have used Gimp, but don't have any experience in programming or any deeper skills for this.

I have Win XP and latest version of Gimp.

Henri

To use the patch you need to apply it to the GIMP source and recompile GIMP. Without experience there is no way you will be able to do that on Windows. Your best shot is to install Linux (because it's 200 times easier to compile GIMP on Linux than on Windows) and ask for help on for example the gimp-developer mailing list.

Yes, re-centering at zooms is a thing that needs corrective action.

As far as scroll bars go three options have been proposed:

1) as it is now, the scrollbars extend over the pan area at all times.
2) scroll bars only cover actual image area, but scrolling beyond is possible, the scrollbar will be extended.
3) Scrolling beyond image area is not possible. You will need to use a pan tool to get there but you can scroll back.

Some find that being able to scroll beyond image edge causes them problems in finding the edge and that they would like a user configurable pan size.

For me and I believe for many others 2 will make sense...

I'd vote for a modified/ clarified 2):
Scroll bars initially only cover actual image area, but scrolling beyond is possible, the scrollbar will be extended in a way similar to inkscape.

There should also be a specification as to what the following actions should do:

- Set zoom to 100% ("1" key): I think this should also centre around the "real"/inner image area (do we have a name for that?).
- Set window size to image size (Ctrl+E, currently incorrectly named "_Shrink_ wrap"):  I think this should only refer to the inner area dimensions and centre the image.
- Fit image to window size (Ctrl+Shift+E): Dito:  The real image should fill out the window as well as possible.

Just my 2¢.

Created attachment 113356 [details] [review]
Updated overpan

this implements 2) version of scrollbars, that I have come to love from coding side. Scrollbars don't have to give a hoot how much panning is possible, they just reflect the situation.

It also brings the pan ratio into a #define  and makes corp tool exempt from the restriction per pointers given by Peter Sikking.

Created attachment 113365 [details] [review]
Fixes other pan ratios than 0.5 for preivous pan.

Created attachment 114004 [details] [review]
Alternative but slightly broken scrollbar setup.

There are 2 main reason why this does not obsolete the previous patch:
1) The bug in scrolling when for some reason when dragging the slider clamping never takes effect on the slider while it does on canvas as if the clamped value never gets updated back to the scrollbar. It quite easily but not all the time happens when slightly over scrolled to neg side and then dragging the handle back. I haven't even got a clue where to look for that one... Looks like its in GTK to me... Or Ive missed something obvious. Let me know if you see that.

2) I'm not sure its a good idea to completely not allow over scroll with dragging the handle or using the wheel... GUI team may want to chip in here, but I personally would like it to be more like the previous patch without oddities.

Created attachment 114021 [details] [review]
fixed and somewhat cleaned update. might be fit for SVN.

This fixes the bugs outlined in 1) and removes the crop tool special case. It also cleans the code up a bit. Might be the first version of this that could go in SVN IMHO...

Created attachment 114110 [details] [review]
updated and cleaned up patch

After some refactoring it was a much more pleasing experience to implement this. I have commited a change that results in the same behaviour as Alexias patch, but that as an effect of the refactorings also makes the rulers update properly, as well as zooming in/out while maintaining the position of the cursor in the image.

There are some things that needs polishing:

 o The navigation editor
 o Sometimes the zoom in/out makes an annoying little jump when
   it is supposed to maintain the position of the cursor in the image
 o Zooming in out using plain +/- keys doesn't work properly, but
   that is the case even in GIMP 2.4

Since the code I have is good enough for some broader testing, I have commited to trunk rev 26166:

2008-07-12  Martin Nordholts  <martinn@svn.gnome.org>

	The following change is conceptually based on a patch by
	Alexia Death and implements the core functionality for
	bug #362915.

	* app/display/gimpdisplayshell-scroll.[ch]
	(gimp_display_shell_scroll_clamp_offsets): Clamp the offsets in
	such a way that allows to scroll beyond the image border.

	(gimp_display_shell_setup_hscrollbar_with_value)
	(gimp_display_shell_setup_vscrollbar_with_value): Put common
	scrollbar range setup code here.

	* app/display/gimpdisplayshell-scale.c
	(gimp_display_shell_scale_setup): Use above helper functions for
	setting up scrollbar range.

	* app/display/gimpdisplayshell-callbacks.c: Handle adjustment of
	the scrollbar range when they are about to change value.

	* app/display/gimpdisplayshell.c: Always keep the scrollbar
	steppers sensitive to user input.

Keeping open until this is fully polished

The annoying jump was simply because of natural offset clamping, and the claim that zooming in/out using +/- didn't work properly was just a misunderstanding on my part, so the only issues left I am aware of is:

 o Adapt the navigation editor/view

 o When creating a new image that ends up in the no-image-window and
   when using View -> Zoom -> Ft Image in Window or Fill Window, the
   image should be centered afterwards

If you discover more issues, please add them to this bug report.

trunk, rev 26176:

2008-07-13  Martin Nordholts  <martinn@svn.gnome.org>

	* app/display/gimpdisplayshell-scale.c
	(gimp_display_shell_center_image): New function.
	(gimp_display_shell_scale_fill)
	(gimp_display_shell_scale_fit_in): Center the image at the end.

It is slightly trickier to get the same effect in gimp_display_shell_fill() since one needs to wait on the display area to get its new allocation after the scrollbars have been shown.

Left todo:

 o Adapt the navigation editor/view
 o Center images that ends up in the no-image-window
 o Set scrollbar steppers to insensitive when no further pan is possible

trunk, rev 26178:

2008-07-13  Martin Nordholts  <martinn@svn.gnome.org>

	* app/display/gimpdisplayshell.c (gimp_display_shell_new): Get rid
	of non-intelligent scrollbar stepper sensitivity code.

	* app/display/gimpdisplayshell-scroll.c
	(gimp_display_shell_scroll_clamp_offsets): Add intelligent
	scrollbar stepper sensitivity code.

Left todo:

 o Adapt the navigation editor/view
 o Center images that ends up in the no-image-window

Commited to trunk, rev 26185:

2008-07-13  Martin Nordholts  <martinn@svn.gnome.org>

	* app/display/gimpdisplayshell-scale.[ch]
	(gimp_display_shell_center_image): Allow to choose what axes to
	center on.

	(gimp_display_shell_scale_fill)
	(gimp_display_shell_scale_fit_in): Explicitly center on both axes.

	* app/display/gimpdisplayshell.c (gimp_display_shell_fill): Center
	the image in the filled display shell. Rather hackish, but seems
	to work fine.

Left todo:

 o Adapt the navigation editor/view

I think there is at least one other issue that should be sorted out before 2.6 (but it doesn't block 2.5.2): When doing a crop, the result is displayed in the upper left corner of the canvas. This looks odd and it gets worse when you undo and redo. IMO we should either try not to move the content when doing a crop or just always center when the image dimensions change.

Yes indeed, crop should be taken care of. Scaling the image poses the same problem. I think the most elegant would be to:

When the image is scaled:
Adjust the viewport offset so that the center of the image doesn't move. Accordingly when undo-ing.

When the image is cropped:
Adjust the viewport offset so that the part of the image that is left after the crop doesn't move. Accordingly when undo-ing.

If 'Resize window on image size change' is used, the image should just be centered in the viewport afterwards.

Keeping the center of the image in the same place may cause the image to be completely outside the canvas. I know that this can't happen, but the result would still be unexpected.

As far as I can see the following rule should take care of all cases and it should be relatively easy to implement:

   Whenever the image dimensions change, for each display, keep the pixel in
   the center of the display in the same place.

For crop this would mean that the image wouldn't move. And for a scale the user would still be looking at roughly the same region on the image.

Created attachment 114836 [details] [review]
handle-image-size-change-2008-07-19.patch

You're right, the same mechanism can be used to handle scale. Not only scale and crop needs to be taken care of, also rotate and canvas resize.

I have attached a patch that seems to work nicely, including for undo and redo. I used an image origo-based approach rather than a display shell center approach. Please take a look at the patch before I commit it.

I discovered a bug that I will take care of before commiting; when undoing/redoing e.g. a crop with a lot of overpan, offset clamping will be applied to the smaller version causing a jump.

origo is not an english term. I think you meant to use "origin" instead.

Commited to trunk, rev 26354:

2008-08-03  Martin Nordholts  <martinn@svn.gnome.org>

	Further work for completing bug #362915 that makes changes to the
	image size (e.g when cropping) be much more nicely handled by
	display shell.

	* app/core/gimpimage.[ch]: Add new signal
	GimpImage::size-changed-detailed that is emited whenever
	GimpViewable::size-changed is. The new signal provides additional
	information, namely the previous origin relative to the current
	origin. Cliens choose what specific signal to listen to depending
	on how much info they need.

	* app/display/gimpdisplayshell-handlers.c: Connect to
	GimpImage::size-changed-detailed instead of
	GimpViewable::size-changed since the shell wants information about
	the previous image origin.
	(gimp_display_shell_resolution_changed_handler): Use
	gimp_display_shell_scale_resize() instead to avoid display
	garbage.

	* app/display/gimpdisplayshell-scale.[ch]: Add new utility
	function gimp_display_shell_center_image_on_next_size_allocate().

	* app/display/gimpdisplayshell-scroll.[ch]
	(gimp_display_shell_handle_size_changed_detailed): New function
	that replaces logic in gimp_display_shell_handle_size_changed and
	that takes previous-origin of the image into account and adjusts
	the offset so that the image content that remains doesn't move. If
	the window is resized on image resize, just center the image
	afterwards.

	* app/core/gimpimage-undo-push.[ch]
	(gimp_image_undo_push_image_size): Add previous-origin paremeters.

	* app/core/gimpimageundo.[ch]: Add and manage previous-origin
	properties so that the display shell offset can be appropriately
	adjusted also when undoing.

	* app/core/gimpundo.h
	* app/core/gimpimage-undo.c: Add previous_origin members to the
	undo accumulator and emit that information when the size of the
	image changes due to the undo.

	* app/core/gimpimage-crop.c (gimp_image_crop)
	* app/core/gimpimage-scale.c (gimp_image_scale)
	* app/core/gimpimage-rotate.c (gimp_image_rotate)
	* app/core/gimpimage-resize.c (gimp_image_resize_with_layers):
	Supply information about the previous-origin of the image to the
	size-changed signals and the undo system.

Left todo:

 o Adapt the navigation editor/view

Since my last update on this bug report, I have been adapting this feature for zoom in/out and image window resizing. Now the navigation view should be in GIMP 2.6 state:

2008-08-22  Martin Nordholts  <martinn@svn.gnome.org>

	* app/widgets/gimpnavigationview.c: Adapted to play nicely with
	the overscroll feature. Basically remove limitations of the
	marker, but also draw the marker frame with an inner and outer
	border so it is possible to see on what side the viewport is when
	zoomed out and overscrolled to the max. This is further work on
	bug #362915.

Left todo:

 o Adapt the navigation editor (namely the popup in the
   lower right corner of image windows)

 o Make autoscroll behave more intelligently, it's currently
   annoying e.g. when cropping.

2008-08-24  Martin Nordholts  <martinn@svn.gnome.org>

	* app/display/gimpnavigationeditor.c
	(gimp_navigation_editor_popup): Prevent the popup from being
	positioned far away from the click position. This is further work
	on bug #362915.

Left to do:

 o Make autoscroll behave more intelligently, it's currently
   annoying e.g. when cropping.

Commited to trunk, rev 26775:

2008-08-26  Martin Nordholts  <martinn@svn.gnome.org>

	* app/display/gimpdisplayshell-scroll.c
	(gimp_display_shell_scroll_unoverscrollify): New function.

	* app/display/gimpdisplayshell-autoscroll.c
	(gimp_display_shell_autoscroll_timeout): Make sure the autoscroll
	does not result in overscroll. This more or less finalizes the
	implementation of the enhancement request in bug #362915.

There's still some polishing left to do, I'm keeping this bug report open meanwhile..

I am currently not aware of any 2.6 blockers related to this functionality, so I'm closing this as FIXED now. Please report any problems separately, preferably on IRC, instead of reopening this beast.

I think that this bug is easy to fix.  Just make the scroll bars scroll the same width and height as the navigation dialog and paining do.  If you go into the navigation dialog and you move the view port you can move it past the image boarder, you can also do the same if you hold down the space bar to pan the image.  Both these methods give you a nice distance away from the image.  You could set the page width and height to what ever they are set to.

This is still a problem in version 2.9.3 and it would be nice to have this fixed.