On 2/24/07, Mark Lowry wrote:

It would be useful to add a temporary magnifying window that would provide a
zoomed-in view of the area immediately surrounding the cursor. This could be
accessed, for example, by pressing SHIFT+Z, upon which a small window would
open up and display the area around the cursor. The window that pops up could
have some check boxes for the amount of magnification to be used (1x, 2x, 3x, 5x, etc.).

It doesn't soom to differ significantly from existing Navigation window

Alexandre

On 2/24/07, Alexandre Prokoudine wrote:

to be used (1x, 2x, 3x, 5x, etc.).

It doesn't soom to differ significantly from existing Navigation window

It does! Navigation window provides a zoomed out view of the entire image -- this provides a zoomed in view of the area that the cursor is in.

On Fri, Feb 23, 2007 at 05:14:13PM -0800, Mark Lowry wrote:

It would be useful to add a temporary magnifying window that would provide a
zoomed-in view of the area immediately surrounding the cursor.

This functionality would be very useful when making selections with the pen
tool, lasso tool, etc.

Hmm. I do in fact a lot of zooming when cropping or making rectangular selections, where I need both the 'big picture' and pixel precision.

But how to make sure the window doesn't obstruct an area you need to see?

Another way to implement this would be to have the magnification value in the
preferences, and instead of opening up a separate window for the magnified view
you enlarge a circular region immediately surrounding the cursor

Could be problematic with rectangular selections.

This leads me to a similar idea: Opening a second view (implemented since long) and enabling an option 'follow cursor', which would scroll the view following the cursor, as long as the cursor is on another view.

Mark Lowry wrote:

It would be useful to add a temporary magnifying window that would provide a zoomed-in view of the area immediately surrounding the cursor.

like this?

assigned to a spring-loaded key (push down: magnifier appears, release: disappears). Settings need to be adjustable on the fly, hmmm. magnified area can stay out of the way automatically, without jumpy behaviour, like magic.

--ps

principal user interaction architect man + machine interface works

http://mmiworks.net/blog : on interaction architecture

On Saturday 24 February 2007 14:12, Mark Lowry wrote:

I was thinking more like this ...

http://pic20.picturetrail.com/VOL66/86790/6669793/233033597.jpg

Hello,

I have to admit that this is a great idea. But I think it is better to have both normal and magnified view at the same time, because it can be hard to follow an edge or to see the global aspect if the magnified view hide the normal view.

My 0.02 euros...

On 2/24/07, Mark Lowry wrote:

It would be useful to add a temporary magnifying window that would provide a zoomed-in view of the area immediately surrounding the cursor. This could be accessed, for example, by pressing SHIFT+Z, upon which a small window would open up and display the area around the cursor. The window that pops up could have some check boxes for the amount of magnification to be used (1x, 2x, 3x, 5x, etc.).

I really _miss_ this feature! One of the things I do all the time, is selecting rectangular regions from an image, with pixel perfect precision and then copy + paste as new. To achieve the pixel perfect precision, I have to zoom in a lot (10x and maybe more) and try at the same time to make a selection of an area which doesn't even fit my screen. It's hard and irritating.
The important things in implementing something like this are: 1) You have to have an unobstructed view of the image (that's why I don't like peter sikking's proposal) 2) You must be able to see the outline of the brush or the cursor position, in the zoomed in view and the zoomed in view should follow the normal view (that's why a second zoomed in view of the image, with View->New View, wouldn't work)

How about another tab that shows the zoomed in view, with the above characteristics and a key that when you press it and the zoom tab is enabled, it would raise this tab on the front? Of course, finding a key would be difficult... Can ctrl for example be used for this purpose without affecting its use from the other tools? Should be?

Hi,

how should tool interaction work with this? Would you want to see the mouse cursor in the magnified view? Should you able to interact in it or is it just a view?

Sven

Steve Stavropoulos wrote:

I really _miss_ this feature! One of the things I do all the time, is selecting rectangular regions from an image, with pixel perfect precision and then copy + paste as new.

The important things in implementing something like this are: 1) You have to have an unobstructed view of the image (that's why I don't like peter sikking's proposal)

here is the workflow that I am seeing for you:

- set the course selection rectangle - grab a side or corner handle, set it pretty damn close, press magnifier key, see magnified view out if the way of your cursor,
set corner/edge pixel perfect, release handle, release magnifier key - repeat last step for the other 3 corners/sides

unobstructed and precise enough?

--ps

principal user interaction architect man + machine interface works

http://mmiworks.net/blog : on interaction architecture

Hi,

On Sat, 2007-02-24 at 07:41 -0800, Mark Lowry wrote:

Here's a screen shot of the Windows version in action.

http://pic20.picturetrail.com/VOL66/86790/6669793/233053894.jpg

The Windows version is not "bad", but improvements could be made and I don't know if other operating systems have such a tool. A version that resides in GIMP and is designed with retouchers in mind would be a very nice feature, I think.

Pretty much every desktop comes with such a tool and it shouldn't be our business to duplicate this functionality. But a magnifier on the desktop level can only magnify the screen view. It wouldn't give a more detailed view of the image.

Sven

Sven wrote:

how should tool interaction work with this?

the tool still only interacts in a real GIMP window

Would you want to see the mouse cursor in the magnified view?

yep, normal sized mouse cursor, with for all the brush based tools the brush coverage shape enlarged correctly.

Should you able to interact in it or is it just a view?

it is just a temporary loupe.

what I am asking myself is 'does this thing need to be circular?

I can see the circle thing coming from a constant radius around the mouse cursor (and a cool shape in case of the aperture loupe: ), but
I am sure that you will feel a lot better when it can be a square, the small and enlarged one connected by a couple of filled polygons.

--ps

principal user interaction architect man + machine interface works

http://mmiworks.net/blog : on interaction architecture

On Sat, 24 Feb 2007 11:02:26 +0100, Thorsten Wilms wrote:

This leads me to a similar idea:
Opening a second view (implemented since long) and enabling an option 'follow cursor', which would scroll the view following the cursor, as long as the cursor is on another view.

I had exactly the same idea when I read the bug report. This has several advantages:
- you can position the 2nd view wherever you want so that it does not obstruct your work area;
- you can still see everything in the main view, including the exact shape and proportions of the brush; - you can set the zoom level separately for the main view and for the zoomed-in view;
- you can also set the size of the zoomed-in view by just resizing the window instead of having to deal with preferences, etc. - the zoomed-in view can support all other view options such as hiding or showing selections, guides and other stuff independently from the main view;
- support for multiple views is already there, the main thing missing is an option to track the pointer when it is in another view;
- geeks can have more than one zoomed-in view if they want to. ;-)

-Raphael

how should tool interaction work with this? Would you want to see the mouse cursor in the magnified view? Should you able to interact in it or is it just a view?

IMO, there should be a fixed crosshair or something in the center of the "zoom window" that corresponds to the cursor. As the tool moves around the image, the image scrolls but the crosshair does not move.

I do not think there needs to be be any interaction, other than being able to set the magnification level desired - either in prefs or in the window itself.

I'm not sure whether it would be best to implement it as a pop-up as suggested, or as a dialog. I'd probably vote for some type of toggle on the existing navigation window, or a new dialog similar to the nav window. I would probably find the pop-up annoying after a time.

Just my 2¢, Chris

peter sikking writes:

what I am asking myself is 'does this thing need to be circular?

XEphem has a magnifier in some of its views, like the moon view. It's just a square with a yellow border, and you can drag the mouse around and magnify different parts of the image in real time. http://shallowsky.com/tmp/xephem-moon-view.jpg

I don't find it very useful in xephem because there's not enough detail to be worth magnifying, but I'd love a quick way in GIMP of saying "Show me what this small region looks like at full size, even though the image window is zoomed out at 33%." In GIMP, as Sven already said, you can get more useful information than a mere screen magnifier could give.

I think that might be a different use case from what's being discussed here, though, because seeing a brush cursor doesn't make much sense in this model. I'd be moving the mouse around to select what area gets zoomed, not to paint or do other operations. If I want to see both zoomed and normal views while I'm actually painting, opening a second view works fine for me.

Chris Mohler writes:

I'm not sure whether it would be best to implement it as a pop-up as suggested, or as a dialog. I'd probably vote for some type of toggle on the existing navigation window, or a new dialog similar to the nav window. I would probably find the pop-up annoying after a time.

I'd use a popup but I wouldn't use a dialog. If it was a dialog that I had to position on the screen and dismiss later, I'd just as soon open a new view and zoom it. Especially if there were other preliminary steps, like the select-a-region step Peter described.

On Sat, 24 Feb 2007 20:10:47 +0100, Akkana Peck wrote:

peter sikking writes:

what I am asking myself is 'does this thing need to be circular?

XEphem has a magnifier in some of its views, like the moon view. It's just a square with a yellow border, and you can drag the mouse around and magnify different parts of the image in real time. http://shallowsky.com/tmp/xephem-moon-view.jpg

I don't find it very useful in xephem because there's not enough detail to be worth magnifying, but I'd love a quick way in GIMP of saying "Show me what this small region looks like at full size, even though the image window is zoomed out at 33%." In GIMP, as Sven already said, you can get more useful information than a mere screen magnifier could give.

I think that might be a different use case from what's being discussed here, though, because seeing a brush cursor doesn't make much sense in this model. I'd be moving the mouse around to select what area gets zoomed, not to paint or do other operations. If I want to see both zoomed and normal views while I'm actually painting, opening a second view works fine for me.

Chris Mohler writes:

I'm not sure whether it would be best to implement it as a pop-up as suggested, or as a dialog. I'd probably vote for some type of toggle on the existing navigation window, or a new dialog similar to the nav window. I would probably find the pop-up annoying after a time.

I'd use a popup but I wouldn't use a dialog. If it was a dialog that I had to position on the screen and dismiss later, I'd just as soon open a new view and zoom it. Especially if there were other preliminary steps, like the select-a-region step Peter described.

just a quick thought following from an earlier comment. As an aid to getting pixel precision on a larger area than could be displayed in one go at a sufficient resolution.

If the mouse wheel is configured like googleEarth zoom, could this provide a way to pinpoint with pixel accuracy each corner of the rectangle without the need for a loupe?

Scroll zoom , select rectangle vertex 1, zoom out, find second part in image, zoom in, click second defining vertex.

Currently the zoom is disabled while the mouse button is down.

I'll let Peter suggest the best way implement this. Whether by allowing mouse scroll events while left button is depressed , or by some other selection means.

Currently I dont see a way to select a rectangle larger than the visible area without compromising precision.

gg.

Hi,

On Sat, 2007-02-24 at 13:29 -0800, Mark Lowry wrote:

If a second, stationary window is used rather than a moving "lens", I would suggest that it should have its own buttons for controling the magnification level. Its desktop location should also be able to be remembered upon exiting GIMP or any time it is closed so that when it is launched again it re-opens in the same location.

It could be dockable. In the long term our plans for dockables is that anything that you ever added to a dock will open again where you had docked it the last time.

Sven

Mark Lowry wrote:

Good point. A GIMP magnifier such as we are discussing should magnify the actual image, not just the desktop portrayal of the image.

Yes of course. Sorry not to have explicitly written this.

If a second, stationary window is used rather than a moving "lens", I would suggest that it should have its own buttons for controling the magnification level.

also the temporary loupe can have its own zoom level and also I will give it an option to work absolute (to the image data) or relative (to the zoom level in the actual image window). This means you can set it to display the image data at 400%, or 400% of the window level (window is at 33%, result in the loupe is 132%). And all this of course not far away in the preferences, but there when the loupe is there.

A few people here seem to favour a permanent loupe window because it would not cover the main image. Now let me first say that additional view windows (different from the cloned main window that the GIMP already had now) tracking the mouse pointer, already have been identified as a requirement in our UI evaluation. These however, do not solve the problem we got here.

Now, a permanent loupe window does cover the main window, in a way. It simply eats screen real estate.

Let's look at the user requirements: for a _moment_ you want to see what you are _doing_ at high magnification, while working on a _macroscopic_ scale.

I add here that to be able to be of help, the magnified area needs to have a strong relationship (closeness) to the actual mouse position, but always needs to be out of the way.

everything speaks for a key-triggered loupe.

during the moment that one is focussed on the detail there is plenty screen space to put a really sizeable loupe window, and it will be automatically close, but also automatically out of the way.

the next moment when one is focussed on the macroscopic image, the loupe is gone, taking no screen real estate.

gg: mouse wheels are not universally available, so they can never be part of the primary solution. Like second monitors, they are extras, and we provide extra UI and shortcuts to help the people who have them, and actually like them.

--ps

principal user interaction architect man + machine interface works

http://mmiworks.net/blog : on interaction architecture

On Sun, 25 Feb 2007 21:01:47 +0100, peter sikking wrote:

Let's look at the user requirements: for a _moment_ you want to see what you are _doing_ at high magnification, while working on a _macroscopic_ scale.

I would like to know why you state that the user requirements include showing for a _moment_ what you are doing at high magnification.

If the view of the zoomed-in area does not overlap the normal work area, some users may be equally interested in seeing at all times what they are doing at high magnification so that, for example, they could detect any unusual details that are not visible at a smaller scale. Or they could be interested in seeing the high magnification area at many moments that are relatively close to each other in time so that, for example, they could precisely adjust several points in a path or iscissors curve.

To me, the argument that the zoomed-in area should only be displayed for a brief moment is far from obvious.

I add here that to be able to be of help, the magnified area needs to have a strong relationship (closeness) to the actual mouse position, but always needs to be out of the way.

everything speaks for a key-triggered loupe.

Again, this is far from obvious. You state that it "always needs to be out of the way" but there is no real way to ensure that it is _always_ out of the way, except by letting the user position some window in advance (which then speaks against a key-triggered loupe). Otherwise, there is no way for GIMP to predict what area close to the mouse pointer is a "safe" area that the user is not interested in. The user may still be interested in some context around this area in order to be able to align things, repeat some pattern, etc.

during the moment that one is focussed on the detail there is plenty screen space to put a really sizeable loupe window, and it will be automatically close, but also automatically out of the way.

You assume that focusing on the detail means that the user lost interest in the context. This is not always the case. If you do not let the user position the high magnification area (as would be possible with an auto-tracking view), then the key-triggered loupe would probably have to support a combination of modifiers so that the user can tell GIMP: "no, don't pop it up somewhere above my mouse pointer, but rather somewhere in the lower left corner, or somewhere far to the right".

-Raphaël

Raphaël wrote:

Let's look at the user requirements: for a _moment_ you want to see what you are _doing_ at high magnification, while working on a _macroscopic_ scale.

I would like to know why you state that the user requirements include showing for a _moment_ what you are doing at high magnification.

the first mail in this thread does, also the "I really _miss_ this feature!" mail by Steve Stavropoulos does.

The macroscopic and momentarily aspects are the core of this problem.

If the view of the zoomed-in area does not overlap the normal work area, some users may be equally interested in seeing at all times[...]

To me, the argument that the zoomed-in area should only be displayed for a brief moment is far from obvious.

different use case. I already said that additional tracking views of the same file at different magnifications will solve that.

back the the problem of this thread.

I add here that to be able to be of help, the magnified area needs to have a strong relationship (closeness) to the actual mouse position, but always needs to be out of the way.

everything speaks for a key-triggered loupe.

Again, this is far from obvious. You state that it "always needs to be out of the way" but there is no real way to ensure that it is _always_ out of the way

this does it:

it is always out of the way where the mouse and the attention is (centre of the smaller circle).

The user
may still be interested in some context around this area in order to be able to align things, repeat some pattern, etc.

my solution involves a switch (on/off of the loupe) to do that, your solution involves a switch (user views out/in of the main window) to do that.

the problem with your solution is the cost in screen real-estate minimum 100x100, which force the loupe window to be small, and not see the surrounding of the point of interest at a generous magnification. It is also by definition farther away, being non- overlapping with the man window, which is not what one wants when performing finicky surgery.

The way for the future for GIMP UI is to display a lot more things on the fly, just when one needs them, and only the truly universal things fixed in the inspectors. Can already get used to the term HUD (heads-up display).

during the moment that one is focussed on the detail there is plenty screen space to put a really sizeable loupe window, and it will be automatically close, but also automatically out of the way.

You assume that focusing on the detail means that the user lost interest in the context.

during those 1-2 seconds. It is actually physiological. you angle of view narrows to a few degrees, when concentrating.

This is not always the case.
If you do not let the user position the high magnification area (as would be possible with an auto-tracking view), then the key-triggered loupe would probably have to support a combination of modifiers so that the user can tell GIMP: "no, don't pop it up somewhere above my mouse pointer, but rather somewhere in the lower left corner, or somewhere far to the right".

see the linked picture above, close and always out of the way. very cool.

gg: I am not going to forbid anyone to pop up a loupe while the mouse is down.

--ps

principal user interaction architect man + machine interface works

http://mmiworks.net/blog : on interaction architecture

Hi Gimpers,
allow me to join the brainstorm. As the loupe tool seems to be most useful for making pixel-perfect selections while retaining a global view on the image, what if the selection tools provided that functionality?

When creating or resizing selections, the loupe would show up after holding the mouse button for a certain amount of time, automatically. Alternatively it could be a checkbox in the tool's preferences.

I also believe the preview is more useful being rectangular rather than round.

cheers

I really like the idea. It sounds like a shortcut for an operation I perform all the time:

1. Create a new view 2. Zoom right in on a point I want to edit. 3. Do operation
4. Close view.

In fact, an option I can think of that would be quite flexible would be to bind a keyboard shortcut (say shift-z) to the new view button - cos that would be useful in its own right - and then have an additional modifier that says, "while shift is still held down, switch to zoom tool" so that a user can zoom in on the area required. Then releasing shift goes back to whatever tool he had selected previously. Finally, shift-z can close the window again when he's finished.

On Saturday 03 March 2007 17:50, David Marrs wrote:

I really like the idea. It sounds like a shortcut for an operation I perform all the time:

1. Create a new view 2. Zoom right in on a point I want to edit. 3. Do operation
4. Close view.

In fact, an option I can think of that would be quite flexible would be to bind a keyboard shortcut (say shift-z) to the new view button - cos that would be useful in its own right - and then have an additional modifier that says, "while shift is still held down, switch to zoom tool" so that a user can zoom in on the area required. Then releasing shift goes back to whatever tool he had selected previously. Finally, shift-z can close the window again when he's finished.

Could it possible to make a script-fu for such operation, and assign it a shortcut?

Hi,

On Sat, 2007-03-03 at 16:50 +0000, David Marrs wrote:

I really like the idea. It sounds like a shortcut for an operation I perform all the time:

1. Create a new view 2. Zoom right in on a point I want to edit. 3. Do operation
4. Close view.

Wouldn't it be easier if you could quickly zoom in (and back out again to the previous zoom level) without having to open a new view for this? In the SVN version you can already revert to previous zoom level. What's the point of doing this in a separate window?

Sven

Hi,

I have done a small change to the "Revert Zoom" feature that was recently introduced (bug #338168). You can now zoom in a certain point of interest using either the mouse wheel or the zoom keyboard shortcuts, edit, and use Zoom->Revert (bound to the ` key by default) to return to the original zoom scale. That should solve the use case that David brought up.

Perhaps it's about time that we try to summarize this discussion and distill the results into an enhancement request?

Sven

Here is the feature request (as I see it): distill away.

Magnifier: (Needs a better name - spy glass, super loupe?) ================================================

The maginfier provides the ability to see an "up close" view of the area immediately surrounding the cursor, in a manner that does not interfere with the current view of the image. The center of the up-close view represents the cursor, the image "scrolls' past the center of the up-close view as the cursor moves across the image. In case that's clear as mud: the cursor is fixed in the magnifier view, and only the image data moves. (Think of the bombsight on a war plane)

A "static" magnifier could be added to the navigation dialog[1], below the current image "map", and small in size. Additionally, a command or shortcut could be applied to "pop-up" (and banish) a magnifier.

Both the static and pop-up magnifier should have a simple plus or minus zoom setting[2], and possibly a text entry for percentage.

In short, the main purpose of the tool would be to provide a precision view of the cursor when making selections[3] that are too large for the image window when zoomed in - removing the need to zoom in and out multiple times while making a selection, therefore making workflow easier.

Chris

[1] This seems like the best existing dialog to place this. It doesn't seem to warrant it's own dialog, unless we were to extend the funtionality into a new "info" dialog similar to PS, in which the color values under the cursor are reported, along with selection size, tranform values, etc. Most of this info is reported already in the status bar though.

[2] Another shortcut for zooming the magnifier?

[3] A suggestion was made to tie the magnifier to the selection tools, but it seems that a magnifier could also prove useful when performing other operations besides selections. Moving a selection for example: one could grab the selection at the very edge and watch for alignment with a particular area (in the magnifier), while still being able to see the overall layout.

I was unable to locate any discussion covering a "tracking view window" and was hoping someone could either explain it or provide a link to an explanation.

It would seem to me that, depending upon how it were implemented, a view window with tracking capabilities might be sufficient to meet the needs of the user without having to resort to the implementation of a new tool.

Hi,

On Sun, 2007-03-04 at 12:53 -0600, Chris Mohler wrote:

[1] This seems like the best existing dialog to place this. It doesn't seem to warrant it's own dialog, unless we were to extend the funtionality into a new "info" dialog similar to PS, in which the color values under the cursor are reported

GIMP already has such a dialog among the dockables that the user can add to their docks. The easiest and the most consistent way for adding a magnifier view is to add it as another dockable. It should be pretty much straight-forward to do that and it would solve most of the use cases that have been brought up.

Sven

On 3/4/07, Sven Neumann wrote:

Hi,

On Sun, 2007-03-04 at 12:53 -0600, Chris Mohler wrote:

[1] This seems like the best existing dialog to place this. It doesn't seem to warrant it's own dialog, unless we were to extend the funtionality into a new "info" dialog similar to PS, in which the color values under the cursor are reported

GIMP already has such a dialog among the dockables that the user can add to their docks. The easiest and the most consistent way for adding a magnifier view is to add it as another dockable. It should be pretty much straight-forward to do that and it would solve most of the use cases that have been brought up.

Wow. Until today, I had overlooked the 'pointer' dialog. D'oh!

Chris

Hi,

On Sun, 2007-03-04 at 15:01 -0500, saulgoode@flashingtwelve.brickfilms.com wrote:

It would seem to me that, depending upon how it were implemented, a view window with tracking capabilities might be sufficient to meet the needs of the user without having to resort to the implementation of a new tool.

I don't think anyone suggested making this a new tool. If it was a tool, you couldn't use other tools at the same time. That would render it almost useless.

But yes, the most obvious and by far the easiest solution is to add a tracking view that users can add to their docks similar to the Navigation dialog.

Sven

Sven wrote,

GIMP already has such a dialog among the dockables that the user can add
to their docks. The easiest and the most consistent way for adding a magnifier view is to add it as another dockable.

easiest to implement, yes.

It should be pretty
much straight-forward to do that and it would solve most of the use cases that have been brought up.

Again, I have nothing against a tracking view with a different magnification than the main window. But it does not solve most of the use cases that came up in this thread, only the exceptional ones Raphael came up with.

Let's look at a couple of aspects:

affordance:

I see a lot of value in supporting "work macroscopic, adjust/paint microscopic." there is a lot more than selections that can benefit from this. That is why I find it a pity to solve it in a way that can only be afforded by users with seriously big screens.

I would like everyone with smaller than 1600x1000 screens to look at their GIMP set-up and figure out where to put an extra 200x200 view. I am on 1280x854 and would not know where to put it.

This is what I mean with 'the cost is too high to have it open all the time.'

closeness:

Experiment for everyone: move your mouse cursor dead centre of your screen. Focus your eyes on it. Now look quickly at one of the corners of your screen (where the permanent view would sit). If you did not turn your neck, you strained your eyes. Is this supporting working swiftly, at a "pro's" pace? Do you want to strain yourself like that all day?

Now compare this to focussing on the dead centre mouse cursor, and quickly looking at an area beside it. Quicker and painless, no?

This is what I mean with 'it has to be close (but out of the way) in order to support working swiftly.'

size matters:

The permanent dialog has to be compromised in size, exactly because it is permanent. 200x200 is a lot of pixels in this context. A pop-up loupe however, can easily be 400x400, showing a lot more image data at the moment that is is needed.

final plea:

Again, I have nothing against a tracking view with a different magnification than the main window. But is you want to make a real, substantial and general improvement in GIMP and support "work macroscopic, adjust/paint microscopic", then a pop-up loupe is the way to go.

It is a cool cairo project, and I'd be happy to specify it.

--ps

principal user interaction architect man + machine interface works

http://mmiworks.net/blog : on interaction architecture

First off, I want to apologize - it's not my intention to be combative, and I can be a total ass sometimes. Secondly, I wonder if we should make two feature requests: the first for a dockable magnifier with options, and the second for a key-triggered pop-up version of the same magnifier. Should there be no objections, I'll file the first request in BZ. Peter, do you have any problems with writing up the second request? Sounds like you have a clearer vision of how it should be implemented. Finally, I'm looking at the latest SVN to see if this is a project that's within my abilities. It looks like a lot of the code that's needed already exists and just needs to be extended into a new dialog - pointers/pitfalls welcome.

Chris

On 3/4/07, Sven Neumann wrote:

But yes, the most obvious and by far the easiest solution is to add a tracking view that users can add to their docks similar to the Navigation dialog.

I've filled out a feature request based on this approach. I've also taken initial steps to implement it, but I have some questions ;)

1. gdk_draw_drawable - should this be used, or dropped in favor of cairo/gnomecanvas/other?

2. adding a new widget was pretty straightforward, but mine is still missing the icon in the tab, and I see this in the terminal: gimp_menu_factory_manager_new: no entry registered for "". My grep-fu isn't working - where does one reference the icon/menu item?

Thanks,
Chris

Hi,

On Mon, 2007-03-19 at 04:06 -0500, Chris Mohler wrote:

1. gdk_draw_drawable - should this be used, or dropped in favor of cairo/gnomecanvas/other?

We aren't using cairo yet. But I don't see what you would want to use gdk_draw_drawable() for.

2. adding a new widget was pretty straightforward, but mine is still missing the icon in the tab, and I see this in the terminal: gimp_menu_factory_manager_new: no entry registered for "". My grep-fu isn't working - where does one reference the icon/menu item?

app/dialogs/dialogs.c, IIRC

Sven

On 3/19/07, Sven Neumann wrote:

We aren't using cairo yet. But I don't see what you would want to use gdk_draw_drawable() for.

OK - I have more to learn!

app/dialogs/dialogs.c, IIRC

Thanks.

Chris

Chris,

First off, I want to apologize - it's not my intention to be combative, and I can be a total ass sometimes.

don't worry, I am also fired up about this one. here is why:

people have talked to me a week or more ago on the irc along the line of: "what's the big deal, one way or another will do."

here is the big deal: for my pov the dockable magnifier is just-another-feature, it will make some people happy in some situations. the pop-up loupe however, has the potential to be a transformational feature. It has the potential (when properly designed) to fully transform the way most people work with GIMP in work-macroscopic/change-microscopic situations, that go way beyond the mentioned setting selections pixel-precise.

"saul" on the irc made this film (thanks):

I could imagine here some dust spotting going on, on a macroscopic scale the photog decides what really needs to be spotted, pops up the loupe and makes a precise change.

I would spec some things different than saul shows us here: enlarged area much closer to the smaller mouse area; semitransparent frame to make the tool less obstructive; real tool display in the enlarged area.

Secondly, I wonder if
we should make two feature requests: the first for a dockable magnifier with options, and the second for a key-triggered pop-up version of the same magnifier. Should there be no objections, I'll file the first request in BZ.

practically speaking, this will have to wait for cairo, and I see you are already off the mark.

Peter, do you have any problems with writing up the second request? Sounds like you have a clearer vision of how it should be implemented.

I am not sure if Sven wants another feature request in bugzilla. If so I will write it.

--ps

principal user interaction architect man + machine interface works

http://mmiworks.net/blog : on interaction architecture

Hi,

On Tue, 2007-03-20 at 18:01 +0100, peter sikking wrote:

I am not sure if Sven wants another feature request in bugzilla. If so I will write it.

Yes sure. We have discussed the feature here and now we should make a useful bug report from it. That will help to remember the outcome of the discussion and it might attract a developer who wants to work on this feature.

I am not at all opposed to bug reports. I just doubt that it makes much sense to keep adding enhancement requests without discussing them beforehand. We currently have about 600 open bug reports, most of them enhancement requests. For someone who isn't deeply involved with GIMP development, it seems impossible to find out what would be important to work on or even to get an idea of the direction that GIMP is taking.

Sven

WARNING TO DIALUP USERS! The GIF file linked to in this post weighs in at 2.2Mb.

Quoting peter sikking :

"saul" on the irc made this film (thanks):

I could imagine here some dust spotting going on, on a macroscopic scale the photog decides what really needs to be spotted, pops up the loupe and makes a precise change.

I would spec some things different than saul shows us here: enlarged area much closer to the smaller mouse area; semitransparent frame to make the tool less obstructive; real tool display in the enlarged area.

Indeed, the "handle" of the loupe tool in my simulation is much longer than it should be (and the frame should have been translucent). I did not realize this until after I had generated the file (a process which took my puny 'puter quite a while to accomplish). The "red dot" which I employed in the zoomed porthole of the loupe would be replaced by a cursor/outline representing the active tool (but my main concern was with the relative motions of the different elements).

Personally, I am not that enthusiastic about the proposed loupe gadget's interface and consider a "dockable tracking view" to offer a better solution. It is not a firm aversion to the loupe but more just reservations about the "comfort" of its use. I would not discourage anyone from actually producing a test implementation.

Firstly, there is an effective "warping" of the pointer when the tool is invoked whereby the focal point is relocated and the user must find it. While such warping is discouraged by GNOME Human Interface Guidelines (HIG), in this case it is probably acceptable (and one could argue that the focal point is actually the small view port and is not warped). Nonetheless, this behavior can be disorienting. It should be noted that the overly-long "handle" shown in the simulation exaggerates the severity of this problem.

More important is the general nature of the "tracking" of the different elements of the loupe in response to mouse movement and the dichotomous nature of the user's focus (i.e., whether his attention is on the view's port or the zoomed port).

I would assume (and this is not shown in the simulation) that when the loupe is invoked, the resolution of the mouse movement switches to that of the zoomed view. This assumption may be faulty but it would seem that if you are zoomed in at 10X and the mouse inputs are not scaled appropriately then you will experience difficulty with positioning of the tool within single-pixel precision (in the zoomed port). If sub-pixel mouse resolution is high enough than the loupe could track the mouse 1:1 and the image in the zoomed port could track it at 10X the speed (or whatever the zoom factor is set at) -- I don't believe this to be the case.

The simulation shows a 4X zoomed version of the image in the larger port. Based on the preceding assumption, the movement of the loupe itself would become 1/4th the movement of the mouse pointer when the loupe is not invoked. The change in orientation of the loupe when it approaches the window's limits results in rather serious disjointedness between mouse movement and the zoomed port (though the view's port would continue its original behavior). Perhaps a better solution than that shown in the simulation is available.

The zoomed image in the larger port would move in the opposite direction of the mouse movement in order to track the image properly. Within the large port, this behavior of mouse movement not resulting in movement of the pointer, but in the scrolling of the image behind it is somewhat non-standard (excepting for traditional cases where a pointer butts up against a window border, resulting in scrolling of a view window).

While there are certainly similar loupe "gadgets" present in a few other programs, the only ones I have encountered are more interested in _viewing_ things at a microscopic scale and not actually _working_ at that level. I am suspicious that the more intense focus of the user entailed will exascerbate the disparities in the screen response to mouse movements.

----

For a dockable tracking view, I would suggest the following be considered for incorporation into its implementation:

1) The view always tracks the cursor when the cursor is over the image window. 2) That the display (outline, mask, etc) of the active tool within the tracking view be optional.
3) That a modifier key would switch mouse input scaling to match the zoom factor of the tracking view.
4) That when the modifier key is depressed, a rectangular outline appear in the image window indicating the bounds of the tracking view (and that the mouse scaling mentioned in "3)" is active.

P.S. My apologies if this appears twice on the list. My first attempt to submit it did not seem to work.

Sven wrote:

I am not sure if Sven wants another feature request in bugzilla. If so I will write it.

Yes sure. We have discussed the feature here and now we should make a useful bug report from it. That will help to remember the outcome of the
discussion and it might attract a developer who wants to work on this feature. I am not at all opposed to bug reports.

just checking, because of:

I just doubt that it makes much
sense to keep adding enhancement requests without discussing them beforehand. We currently have about 600 open bug reports, most of them enhancement requests.

then saul wrote:

I would spec some things different than saul shows us here: enlarged area much closer to the smaller mouse area; semitransparent frame to make the tool less obstructive; real tool display in the enlarged area.

Indeed, the "handle" of the loupe tool in my simulation is much longer than it should be (and the frame should have been translucent). I did not realize this until after I had generated the file (a process which took my puny 'puter quite a while to accomplish).

my thanks for you and the 'puter, again.

Firstly, there is an effective "warping" of the pointer when the tool is invoked whereby the focal point is relocated and the user must find it. While such warping is discouraged by GNOME Human Interface Guidelines (HIG), in this case it is probably acceptable (and one could argue that the focal point is actually the small view port and is not warped).

the last point is exactly how it works (also for humans) and means no HIG felonies.

Nonetheless, this behavior can be disorienting. It should be noted that the overly-long "handle" shown in the simulation exaggerates the severity of this problem.

the point of my 'must be close, but out of the way' guiding principle.

More important is the general nature of the "tracking" of the different elements of the loupe in response to mouse movement and the dichotomous nature of the user's focus (i.e., whether his attention is on the view's port or the zoomed port).

that is at the user's discretion.

I would assume (and this is not shown in the simulation) that when the loupe is invoked, the resolution of the mouse movement switches to that of the zoomed view.

excellent point. since the point of the loupe is working precise, the mouse must move at the speed of the zoomed view.

The change in orientation of the loupe when it approaches the window's limits results in rather serious disjointedness between mouse movement and the zoomed port (though the view's port would continue its original behavior). Perhaps a better solution than that shown in the simulation is available.

your solution really got me thinking. there are multiple other alternatives. at the end it is about having the most stable, predictable loupe placement, and technical feasibility.

The zoomed image in the larger port would move in the opposite direction of the mouse movement in order to track the image properly.

well, if you want to see the spec of dust to the top-left of your current view better, you move the mouse top-left, and you see the spec of dust centred. sounds good to me...

While there are certainly similar loupe "gadgets" present in a few other programs, the only ones I have encountered are more interested in _viewing_ things at a microscopic scale and not actually _working_ at that level. I am suspicious that the more intense focus of the user entailed will exascerbate the disparities in the screen response to mouse movements.

we really will have to work hard to make this reach the transformative potential it has. Working with it is the highest goal.

--ps

principal user interaction architect man + machine interface works

http://mmiworks.net/blog : on interaction architecture

Sven Neumann wrote:

Wouldn't it be easier if you could quickly zoom in (and back out again to the previous zoom level) without having to open a new view for this? In the SVN version you can already revert to previous zoom level. What's the point of doing this in a separate window?

Sorry for such a late reply. I like to use a different view to make precision adjustments because it means that I can have both scales visible simultaneously and can see how my changes look at normal scale while I'm making them.

Davidm