I've just taken a look at the Snap dialog. One improvement that could be made is to move the "Snap sensitivity" line to the left so it starts to the left of the check boxes. As it appears now, it seems to be an option under the "Snap to object nodes/Snap nodes to Grid/Snap points to guides" lines. This would also clearly separate the "Always Snap" lines which are fundamentally different from the other lines.

Also, it is not clear that their are two separate sections under "Object Snapping", that is what is to be snapped and what is to be snapped to, both of which must have a box checked for object snapping to work.

What about a grid (maybe with a common sensitivity setting for simplicity)?

Snap: Sensitivity Always Bounding Box Node Snap to: Path x 50 x Node x x 0.4 Grid 1.0 Guide 1.0

BTW, why is it "Snap ->nodes<- to grid" but "Snap ->points<- to guides"?

Tav

2006. 05. 18, csütörtök keltezéssel 18.43-kor Ralf Stephan ezt írta:

Please discuss redesign but it will not be implemented in 0.44.

As this task is clearly not depend on programmer experience, I have looked at the source and figured out the exact layout. After that, I have made a simple glade file from it, and builded. So I have attached a glade file, for everyone to play with. I highly recommand gazpacho as glade designer, it have complete undo system and stable for me (more stable than glade). Glade has many popups, and difficult to use (bad ui design). Gazpacho homepage: http://gazpacho.sicem.biz/

After we figure out the layout, we can make simple .glade file, it can be used as a references for coding. (note: Im not proposing to use libglade or any glade related tool in inkscape! just for brainstorming and designing)

Its really fun to play with gazpacho, I strongly suggest everyone to play with. If you have an idea or proposal, just send your .glade file to the list and an (optional) screenshot to be able to collaborate playing and developping further.

I have attached a .glade file (snap.glade.gz) for the recent snap dialog design.

I have made some modification as Tav suggested, and made a mockup. The modified .glade file attached(snapNew.glade.gz).

Here is a comparison screenshot for the two design: http://img226.imageshack.us/img226/3010/spannew8ne.png

Some important modification: In the table it can be only one radiobutton selected. So it is important to snap an object node to an another objects path and nodes at the same time. I think its a good improvement. There is no need to snapping to many things at the same time, it make just difficult to use.

Hope we can figure out a better design!

To Alan: quote:

I don't think the layout you propose would work particularly well. It doesn't seem like something you could do within the Gnome guidelines.

Since me and (I think) other proposals will using glade for the design, I think we can stay within the gnome guideline.

Best regards, Khiraly

On Fri, 2006-05-19 at 16:16 +0200, Khiraly wrote:

2006. 5. 19, péntek keltezéssel 14.26-kor Khiraly ezt írta:

...

I have made some modification as Tav suggested, and made a mockup. The modified .glade file attached(snapNew.glade.gz).

Here is a comparison screenshot for the two design: http://img226.imageshack.us/img226/3010/spannew8ne.png

I have made some more radical modification (snap2.glade.gz) Here is the screenshot: http://img232.imageshack.us/img232/2961/snap22nq.png

Any other ideas?

This is similar to what I proposed with the following differences:

1. You should use check boxes (without labels) rather than radio buttons since more than one type of snapping can be turned on at a time. (I took a look at the HIG for GTK and don't see why using check boxes this way is a problem.)

2. Currently the "From" column should contain Bounding Boxes and Nodes, while the "To" row should contain Paths, Nodes, Grid, and Guides. It would be useful to snap the grid and guides to other objects but it is probably not useful to snap a guide to a guide, and since there is only one grid, you can't snap the grid to itself.

3. The "From" and "To" axes should be swapped (since there are more "To" options than "From" options this will result in a narrow but taller dialog, matching the other tabs).

4. The "Always snap" check box is missing.

There must be a better label that "From" but I can't think of it right now. The first line might better read "Snap <From> to <To>".

Tav

On 5/19/06, Khiraly <khiraly123@...240...> wrote:

I think its a really bad idea. If your object is snapping almost everything, it does not help in your design process.

It depends on what type of design your are doing, really. When I'm working on web-design mockups, I usually have several snaps turned on at once. For example, I often want to snap a rectangle to another rectangle's bounding box, and then snap some bezier nodes to the rectangle. In the current system, I can turn all the snaps on at once and work without interruption. In the new system, I would have to change a settings from "snap bounding boxes to bounding boxes" to "snap nodes to bounding boxes" each time I want to do this. Software that is "easier" but less flexible is not really easier, since the user has to do extra work to get around it. Don't put arbitrary constraints on the user!

...

4. The "Always snap" check box is missing.

What does it do? For me, it does nothing, or am I missed something?

The "always snap" box goes with the "snap sensitivity box." Activating "always snap" makes the sensitivity infinitely large so that snapping always occurs.

-William Swanson

On 5/19/06, Khiraly <khiraly123@...240...> wrote:

If you move to the maximum the "snap sensitivity box" scale, it does do the same, no?

No, it doesn't. To see this, create a blank canvas and add two rectangles. Set up node-to-node snapping and move the sensitivity slider to 50. When you drag the rectangles, the corners only snap when the rectangles are near each other. Now, set the snap sensitivity to "always snap." The two rectangles become stuck to each other and are impossible to separate, even if you try to drag them completely across the screen. This is because the snap sensitivity is infinite rather than 50 px.

What is the difference between "always snap" and "snap sensitivity box" to 50 value? (it was a rethorical question)

Moving the slider to 50 causes snapping if two points are within 50 px of each other. Checking the box causes snapping no matter how far the points are.

-William

On Fri, May 19, 2006 at 11:53:10PM +0200, Khiraly wrote:

2006. 5. 19, p?ntek keltez?ssel 14.37-kor William Swanson ezt ?rta:

...

Moving the slider to 50 causes snapping if two points are within 50 px of each other. Checking the box causes snapping no matter how far the points are.

So how about we modify the slider from 50 to something big, which can practicaly consider as "infinite"

Perhaps better would be something like:

Snapping: ( ) None (*) Variable ( ) Always Sensitivity: [-------XXX----------------------]

or maybe just...

Snapping: ( ) Off (*) Variable ( ) On [--XXX-----------------------]

And then grey-out the second line when Variable is not selected

This would put the Always Snap option in context - it's an alternative to never snap or to variably snap. Note this also unambigiously shows a widget to turn off snapping.

Bryce

2006. 05. 19, péntek keltezéssel 18.10-kor Tavmjong Bah ezt írta:

4. The "Always snap" check box is missing.

What does it do? For me, it does nothing, or am I missed something?

Definietly the table could have empty cell. So snapping from gridto griddoes not make sens. Thanks!

Khiraly

2006. 05. 19, péntek keltezéssel 21.29-kor Alan Horkan ezt írta:

The HIG recommends how you should do things, it doesn't cover things you shouldn't do.

Checkboxes and radio list are designed to include labels. You are fighting the design to do otherwise.

At the very least you make accessibility much more difficult since screen readers cannot know which labels fit to which checkboxes.

Maybe I really miss the point, but why we care about screen readers? It is a *graphical application*, no?

The current proposal the more logic one I think. Maybe its not hig compliant, in this case (if it really matters) we can replace the checkbox/radio button with a simple button with image included.

Khiraly

As Bryce has pointed out, scenarios that need all possibilities of the Snap parameter space are realistic. Also, he gave an intuitive widget arrangement for the 0-50-always problem. This, however, means that 2D arrangements can and will not be implemented.

On William's restructuring / refactoring ideas, I urge Carl to give his opinion, as that's over my head.

Regards, ralf

On 5/19/06, Khiraly <khiraly123@...240...> wrote:

...

Here is a comparison screenshot for the two design: http://img226.imageshack.us/img226/3010/spannew8ne.png

I have made some more radical modification (snap2.glade.gz) Here is the screenshot: http://img232.imageshack.us/img232/2961/snap22nq.png

Any other ideas?

While I like your of making snapping more symmetrical, I do think you have some mistakes in your grid. The things that should appear in the "from" axis are different than the things that should appear in the "to" axis. The canvas grid, for example, cannot be snapped "to" anything since the grid does not move. You also have separate entries for "nodes" and "points", even though nodes and points are the same thing.

If you go through the existing dialog carefully, the things you can snap "from" are: * Bounding boxes * Nodes

The things you can snap "to" are: * Nodes * Paths * Grid * Guides

If you put them in a grid, you get this: http://www.swansontec.com/temp/InkscapeSnapGrid.png

As others have pointed out, however, the grid is a bad usability design. Since the grid has only two columns, you can easily split it in half to form two sets of "ordinary" check boxes grouped under two headings:

http://www.swansontec.com/temp/InkscapeSnapUI.png

This design has all the logical improvements of your grid system while remaining faithful to the Gnome HIG.

The downside is the single "snap sensitivity" group. The prior system offered much more flexibility in terms of different snap sensitivities for different areas. Does anybody see this as a serious loss? I have personally never needed the extra flexibility, but others may have different experience. Bulia?

-William Swanson

On Fri, May 19, 2006 at 02:09:12PM -0700, William Swanson wrote:

The downside is the single "snap sensitivity" group. The prior system offered much more flexibility in terms of different snap sensitivities for different areas. Does anybody see this as a serious loss? I have personally never needed the extra flexibility, but others may have different experience. Bulia?

I could easily imagine wishing to have different snap sensitivities for different work modes.

For example, I might specify To Paths to snap very tightly, and a weak snap sensitivity to Nodes, so that if I want to put something on a node, I can "feel" it snap into place, without having the nodes steal snaps too much. I imagine this to be a common use case for drawing cartoons.

Or another good example would be making snap to grid be set extremely highly, but have the guides and paths also have a small amount of snap, so that if I'm zoomed out, and the grid is very fine, I can rely more on snapping to existing lines. This is a very common case when you're doing technical drawing.

In a way, it seems like it might be useful to have saveable presets, so a novice user could pick some sort of "cartoon style snapping", and another could pick "technical snapping" or "grid-only snapping". Advanced users would be able to hit the "Customize snapping" button and pull up the advanced screen to adjust snapping of specific aspects and then save as "My Snap Style" for future use.

This could get especially valuable as we start having new kinds of grids, more things to snap to, etc.

Bryce

On Fri, May 19, 2006 at 01:34:07PM +0200, Khiraly wrote:

2006. 5. 18, cs?t?rt?k keltez?ssel 13.37-kor Bryce Harrington ezt ?rta:

...

This sounds like a good proposal to me. Do you have sufficient access to the RFE tracker to do this? If not, tell me your SourceForge username, and I will open it for you.

username: khiraly

Great, I've added access for you, with full access to the RFE and bug trackers. I did not add subversion access - if you need that one day, please just ask again.

Anyway, welcome to the team! :-)

However, I dont think Im the right person for this jobs, since, my english is very poor.

Certainly, knowing English is not a requirement, however yours has been quite good - I didn't notice it was not your first language. :-)

Bryce