I don't really see the value in having the loupe possess both the magnified view and the focus view. Several good points have been brought up .... The handle must be shorter and translucent (why not just eliminate the handle?) ... How will the tool behave at the window limits (with no handle, this becomes trivial)? As long as it is a simple matter to toggle the loupe on and off via keystroke so that you don't have to take your eyes off of the screen area of interest, I think doing so would allow the user to still stay grounded in the macroscopic while working in the microscopic without the need for the handle and focus view. I also had one other thought I'd like to share ... I think it would be very convenient for the "Shift+mouse wheel" zoom feature to apply to the loupe window when the loupe is visible. This would allow a quick means of changing the loupe magnification without having to look anywhere else on the screen or take your hand off of the mouse. It also makes sense because if "shift+mouse wheel" does not apply to the loupe, using it may cause the area of interest to move out of the window altogether, requiring the user to pan/scroll the window back. Even if the "shift+mouse wheel" zoom is centered on the loupe, other areas of interest might be moved out of the window. For example, if adding catch lights to a person's eyes, you might want to be able to see both eyes in the macroscopic view to make sure that the size and position of the lights is the same. If you have already done the left eye and are currently using the loupe on the right eye, a "shift+mouse wheel" zoom that applies to the entire window or is centered on the loupe might cause the left eye to move out of the macroscopic window. A startup tip should also be written to present instructions for using the loupe. --- peter sikking <peter@xxxxxxxxxxxx> wrote: > 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 > > > > _______________________________________________ > Gimp-developer mailing list > Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx > https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer > ____________________________________________________________________________________ Now that's room service! Choose from over 150,000 hotels in 45,000 destinations on Yahoo! Travel to find your fit. http://farechase.yahoo.com/promo-generic-14795097 _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
