On Fri, 2006-07-28 at 12:15 +0200, Karl Günter Wünsch wrote:
> On Friday 28 July 2006 11:30, [EMAIL PROTECTED] wrote:
> > Quoting Karl Günter Wünsch <[EMAIL PROTECTED]>:
> > 
> > > That's why I would like to update the cursor position after all of  
> > > the calculations are through to reflect the results.
> > 
> > Are you saying that you wish the pointer to be forced to the  
> > calculated corner of a (aspect ratio) constrained mouse movement? If  
> > this is what you mean then I am almost certain this is contrary to the  
> > GNOME Human Interface Guidelines  
> > (http://developer.gnome.org/projects/gup/hig/1.0/index.html).
> What is so wrong in this case to have the cursor follow the only possible 
> path 
> that is within the constraints. Because if you don't then you end up with a 
> pointer position that doesn't correspond to the current selection anymore.

Well we don't do that when snapping to guides and the grid either, and
as said before, it's a totally non-standard way of dealing with
snapping. The mouse pointer should always be driven by the user, not
by the application, and until recently, gtk didn't even have an API
to wrap the mouse, for just that reason.

We won't add that to GIMP.


> In this case we have a corner of an aspect constrained rectangle selected. 
> Both x and y movements are allowed but as these two have to a strict 
> relationship any movement by the user that doesn't follow this relationship 
> (for every 3 pixels horizontally move 2 pixels vertically) will end up having 
> the pointer and the corner being so far apart that the visual relationship 
> between the pointer and the selection isn't aparent any more. I have found a 
> partial solution to this problem yesterday evening (still some quirks to work 
> out) but the problem basically is only reduced by the code that tries to keep 
> the selection as close as possible to the pointer, there still are times when 
> they end up virtually in different corners of the screen...
Gimp-developer mailing list

Reply via email to