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
