[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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic