[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: Request for comment: snapping in kivio / flake
From:       Jan Hambrecht <jaham () gmx ! net>
Date:       2009-09-17 8:46:20
Message-ID: 4AB1F75C.1030807 () gmx ! net
[Download RAW message or body]

Andrew Dorrell wrote:
> Hi Jan,
> 
> Thanks for the responses.  I'll send some comments on separate ideas in  
> separate mails so the message sizes remain managable.
> 
> On Thursday 17 September 2009 5:34:59 am jaham@gmx.net wrote:
>>> 5. Objects should snap during a move or resize operation so as to:
>>>     a. align any edge of the object being modified with and edge of
>>> another object on the page
>> This does already work when using the othogonal snappig strategy.
>>
> 
> Well it doesn't quite work as I describe.  In particular, only the edges 
> connected to the active point (geometry docker) of the object being moved is 
> subject to snapping (see also bug 
> https://bugs.kde.org/show_bug.cgi?id=206201).  Apparently this is by design - 
> sorry...

As I wrote in another mail, I am not opposed to change that. I thought 
it was a good idea at the time I implemented that. So at least we might 
try it out with using all corners at once and see if that works better 
over the current behaviour.

> 
>>>     b. align the center of the object being modified with the center of
>>>         another object on the page
>> This is provided by the bounding box snapping strategy. The "hot position"
>> of the shape has to be set to the center point. This can be accomplished
>> from the geometry docker of the default tool or by middle mouse button
>> click on the center point of the shape.
> 
> This means getting the snap you want can involve iterating between shifting 
> the object and changing geometry settings - not too nice IMHO. 
> 
> What I'd like is snapping whenever *any* edge, or the center, of the object 
> being moved is in alignment with another object.  At least I'd like to try it.  
> I appreciate that there will be some cases where many possible snaps are 
> possible.  Personally I'd prefer to try and find a heuristic for picking the 
> right one than to continuously have to adjust parameters.  Just my personal 
> preference.  Perhaps worth an experiment.

I agree.

> 
> The other point I wanted to make was that I found the shear number of 
> different snap strategies a little confronting and confusing.  I was not able 
> to easily understand what each did - so my first response was to turn them all 
> on and hope it would do what I wanted.  That didn't work so well ;-)

Yeah, some of them do not work together well. :-) But how would 
condensing them to three checkboxes help to avoid that?

> 
> Naming of snap modes is an issue also (if one that is relatively easily 
> fixed).  For example, to me the concept of an "orthogonal" snap strategy is 
> not very clear.  It took me a while to work out why it was called that (I have 
> a mathematical understanding of orthogonality).  I believe in the end you used 
> this name because of orthogonal projection in drawing?  Even then it is not as 
> obvious what it means as usually when I use this snap I'm not actually drawing 
> an orthogonal projection.  Much clearer to me would have been  "Object" (snap 
> to align with other objects).  But I might be missing something here.

I used it because it snaps using orthogonal directions. And it seems to 
be used in CAD programs too. But as english is not my mother tongue, I 
certainly am open to suggestions to make the name (and also the names of 
the other strategies) more clear.
I think it would also be a good idea to provide some context help 
explaining what each strategy is meant to do. Maybe using a "What's 
this?" help button or an extended tooltip.

Ciao Jan
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]