WARNING TO DIALUP USERS! The GIF file linked to in this post weighs in
Quoting peter sikking <[EMAIL PROTECTED]>:
> "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
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
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