WARNING TO DIALUP USERS! The GIF file linked to in this post weighs in at 2.2Mb. Quoting peter sikking <peter@xxxxxxxxxxxx>: > "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 Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
