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

Quoting peter sikking <[EMAIL PROTECTED]>:

> "saul" on the irc made this film (thanks):
> <http://flashingtwelve.brickfilms.com/GIMP/Temp/loupe-demo.gif>
> 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.
Gimp-developer mailing list

Reply via email to