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

List:       koffice-devel
Subject:    Request for comment: snapping in kivio / flake
From:       Andrew Dorrell <andrew.dorrell () gmail ! com>
Date:       2009-08-30 12:57:22
Message-ID: 200908302257.23057.andrew.dorrell () gmail ! com
[Download RAW message or body]

Hi,

The first thing I found myself hankering for when playing with kivio was 
snapping.  Then I found there was the start of snapping already implemented 
within flake; a snapping docker and a few menu options also.  The design 
seemed good from the perspective that snapping would be available in all apps 
and there seems to be plenty of scope for writing new snapping strategies.

However I found that the current operation of snapping didn't really meet my 
expectations and in general seemed difficult to understand and a bit clunky.  
So after asking on IRC I agreed to post a discussion item.  

What follows is my notes on how I'd like to see snapping work (some of this is 
already implemented, I'm just trying to be complete):

Requirements:
------------------
1. Objects should be easy to align with each other and the page.  As mouse 
placement can be imprecise, snapping is used to attract objects to preferred 
positions on the page.  

2. Snapping should be applied appropriately when objects are moved, resized, 
rotated etc.

3. It should be possible to temporarily toggle snapping mode during object 
moving, resizing etc.  This requirement implies a modifier key be used.

4. It should be possible to adjust the "strength" of snapping

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
    b. align the center of the object being modified with the center of 
        another object on the page
    c. match the size of of the object being modified to the size of an 
        existing object on the page (resize only)
    d. align any edge of the object with a page grid

(As an aside I should point out that I don't like snap to grid but it will be 
familiar and a desired feature.  Grid snapping goes bad if the grid dimentions 
are changed or if objects are resized as a group etc.  I'd like to keep grid 
and object snapping as separate concepts.)

6. Objects should snap during rotation so as to:
    a. match the rotation of the object being modified to the rotation of an 
        existing, previously rotated, object on the page.
    b. align the axis of rotation with multiples of a rotation step size (say
        15 degrees)

7.  It should be possible to snap the position and / or size of an object to a 
     ruler so that the actual drawn dimentions of the object are effectively
     specified.  This is a little like snap to grid except that it can easily
     be used just to fix the size of and object, not its position on the page.

8.  When snapping to another object, the grid or a ruler, visual feedback will 
     be provided so that the user can see both the object being snapped to and
     the mode of snapping being employed.

9.  It should be possible to exclude objects from the snapping rules so
     that no object will snap-to the excluded objects.  This would take two
     forms:
     a. Explicitly exclude an object by modifying its properties
     b. Implicitly exclude an object by adjusting the page view (by zoom and 
         scroll) so that the object to be excluded is not visible.

(Second aside: I'd like to see it possible to resize the document page in a 
similar way to any other shape - perhaps via the master page? and in that case 
I'd expect the operation to make use of ruler snapping as well as significant 
size snapping: tight bounding box and standard paper sizes).


User controls: 
------------------
My first hack at the controls I would expect to see on the docker for snapping 
are:
"snapping mode" check boxes: object; grid; ruler
"snapping strength" slider
"snap only to visible objects"
"Prevent snapping to this object" toggle.



Okay... so there is the kind of thing I'd like to see, personally.  I'm not 
sure how significantly this violates current use cases or working modes etc.  
Please comment freely.
_______________________________________________
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]