rotating guides

[Jimmy Volatile]

2009/9/29 bulia byak <buliabyak@...>:

> On 9/29/09, Alexandre Prokoudine <alexandre.prokoudine@...> wrote:
>> Ahem. Distributing guides via align'n'distribute dialog actually makes
>>  a perfect sense.
>
> Not quite, because it will work for horizontal/vertical only, not
> slanted, and because it has so much stuff that is irrelevant to guides
> and is therefore quite confusing. Also, I think no one would want to
> create a bunch of guides and then distribute them. What we need
> instead is an addition to guide creation dialog, saying "Create N
> multiple guides spaced by X px".

Hi, all.

Sorry for joining the discussion this late.

My suggestion is somewhat different from what's discussed and may really be more suited for Inkscape 0.50 or later.

Suggestion: *STOP* treating guides as a special UI case and *instead* treat them the same way as all other objects in Inkscape. This enables reuse of all the powerful, existing tools for selecting, multi-selecting, moving, distributing, rotating, resizing (yes, resizing), deleting, skewing, setting specific x or y positions, moving guides between layers, and aligning guides to existing objects. Entering and exiting the guide editing mode could be as quick as double-clicking on a guide to start editing and double-clicking outside any guides to stop (similar to how entering/exiting a group works today). Even if there was a shortcut key for entering and exiting the guide editor mode,  it would still mean a lot less shortcuts to memorize. (Adding curves by dragging them from the rulers could of course still work as today, the two interaction patterns do not conflict)

Like Alexandre pointed out, aligning and distributing guides makes perfect sense. I've used this myself on multiple occasions, most recently while making game tiles for a children's board game but it's also commonly used to define layout grids for websites and the like. (And distributing slanted guides could work just as well as long as Inkscape imagines that they have finite length).

I.e.: Imagine being able to, for example, scale down the size of a large part of a design to 50% (including selected guides and all) just by using the transform dialog combined with the guide edit mode.

The current approach has provided quick progress in this area but, as we can see, we're painting ourselves into a corner by not reusing tools and by not utilizing different modes of editing, thereby hampering further progress.

Furthermore, reusing tools means more development focus on the existing tools, further streamlining the UI for them rather than distributing and diffusing development on more and more types of virtually identical interaction mechanics. ( one UI for moving and managing objects, another UI for moving and managing guides and so on )

In my mind, a common approach to almost all editing of on canvas objects in Inkscape would mean a reusable interaction pattern that's very familiar, powerful and intuitive for all users. The same interaction pattern can also be reused when some new kind of feature (like slicing of web graphics) is introduced.

I'm quite happy creating a draft blueprint detailing the unified interaction pattern but I think it'll be 3-4 weeks before I have time.

Any feedback is greatly appreciated,

Until then,
Happy Inkscaping!

Jimmy Volatile

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[Maximilian Albert-2]

2009/9/29 john cliff <john.cliff@...>:
> I did quite want to align some to the page the other day and hadnt
> realised we couldnt do it. Was designing my wedding invite and wanted
> to make sure where it was (just created a vertical line and used that
> instead)

If something cannot be directly achieved with guides, just do it with
lines first and then convert them to guides by pressing Shift+G.

Max

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[Krzysztof Kosiński]

2009/9/29 JimmyVolatile <spam@...>:
> Suggestion: *STOP* treating guides as a special UI case and *instead* treat
> them the same way as all other objects in Inkscape.

That's exactly what I said in the second proposition, but it's not
without problems - for example the guides do not have a well-defined
bounding box (because they are infinite).

Regards, Krzysztof

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[Alexandre Prokoudine]

2009/9/29 Krzysztof Kosiński wrote:

> We MIGHT avert opening this can of worms if we create a grids & guides
> tool (or more generically a drawing helpers tool) that lets one create
> and select guides, rename them, distribute, etc.

That is, you want to avert opening can of worms by duplicating
existing functionality? :)

I'm probably nitpicking already, but I fail to see why it is so bad to
give users more power over guides using existing tools. And I really
don't see where confusuion might take place. A guide is a visible
thing. It is on the page and can be dragged. We might as well ditch
angled guides because we bloody well can rotate them almost like
shapes and paths.

Alexandre

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[Joshua Facemyer]

Alexandre Prokoudine wrote:

> 2009/9/29 Krzysztof Kosiński wrote:
>
>> We MIGHT avert opening this can of worms if we create a grids & guides
>> tool (or more generically a drawing helpers tool) that lets one create
>> and select guides, rename them, distribute, etc.
>
> That is, you want to avert opening can of worms by duplicating
> existing functionality? :)
>
> I'm probably nitpicking already, but I fail to see why it is so bad to
> give users more power over guides using existing tools. And I really
> don't see where confusuion might take place. A guide is a visible
> thing. It is on the page and can be dragged. We might as well ditch
> angled guides because we bloody well can rotate them almost like
> shapes and paths.
>

Bulia mentioned previously that confusion would come from users trying
to apply things to the objects that cannot be applied to them (like
colors, or width, etc).

Is there a reason we can't have contextual modes (i.e. a guide edit
mode) which makes tools that cannot be used with an object null?  For
example, you select a guide and the color swatch palette is greyed out.

For that matter, regarding colors, is there a reason guides can't be
made custom colors?  Or even set to print/be rendered as an option?

It may be confusing for some people, but I think it shouldn't be for the
vast majority, especially if it's documented.  There are plenty of
places where the program can be potentially a LOT more confusing that
this, but we don't worry so much if it provides a wanted functionality.

Simply the fact that guides are produced in a much different way from
regular objects is likely enough to make most people aware that they
operate somewhat differently.  Besides, doesn't one have to look a
little bit to find out how to make guides?  At that point, won't he
understand that they're different?

I do see the opposing points' merit, but only if we're concerned about
making things so user friendly that the user can't do anything he wants
with the program.  That's the main reason I moved away from a particular
OS and will never return to it.  Let's not do that with Inkscape.

Of course, there needs to be some limitation on things, otherwise
Inkscape will become a mess.  However, I don't think this will make a
mess out of anything, and in fact could make Inkscape more intuitive.

JF

> Alexandre
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9-12, 2009. Register now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Inkscape-devel mailing list
> Inkscape-devel@...
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[Krzysztof Kosiński]

2009/9/30 Alexandre Prokoudine <alexandre.prokoudine@...>:
> I'm probably nitpicking already, but I fail to see why it is so bad to
> give users more power over guides using existing tools.

Some of the tools are designed to operate on objects of finite
dimensions only. When an object has infinite dimensions, it creates
problems. For example:

1. Where do we display the transformation handles when only guides are
selected, and how does the selection cue look like?
2. Where do we display the rotation centers of the guides?
3. What happens when I try to align a vertical guide and an angled guide?
4. ... when I try to distribute them?
5. Do guides have fill and stroke properties?
6. Can they be used as LPE parameters?
7. What is the effect of "convert to path"?
8. Can I put text on it, and if yes, then where does it start?
9. What is displayed when I select a guide in the node editor?

Some of those could be solved by defining guides in terms of two
points and a line that goes through them; the segment between the
points could have a different color, and determine the bounding box
for transformations. I have nothing against making guides "normal"
objects (in fact it would be a logical thing to do, and the same goes
for grids), but it requires carefully specifying the behavior in edge
cases.

Regards, Krzysztof

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[Joshua Facemyer]

Krzysztof Kosiński wrote:
  > 1. Where do we display the transformation handles when only guides are
> selected, and how does the selection cue look like?

You only need to display rotation guides - make two rounded double-ended
arrows on either side of the rotation point, which would also be
hi-lighted.  Dragging these transforms (rotates), dragging the rotation
point moves it along the guide.

> 2. Where do we display the rotation centers of the guides?

At the rotation point, which would also be the point at which aligning
is done.  It would be an align/rotation point.

> 3. What happens when I try to align a vertical guide and an angled guide?

They align at the rotation/align points.

> 4. ... when I try to distribute them?

Same - they distribute at the align/rotation point.

We could also consider creating a separate concept of two
align/distribute points, which would be more useful for aligning angled
guides or aligning horizontal to vertical, and the reverse.  That might
be a bit much, but would allow for more control.  The default could be
align/distribute at the rotation point, but the user could add the
additional control points.

> 5. Do guides have fill and stroke properties?

They would only have fill, and it should probably be limited to colors
(though I don't see why, except that filling with a pattern would be
kinda strange for a one-pixel line).

> 6. Can they be used as LPE parameters?

If it makes sense.

> 7. What is the effect of "convert to path"?

It could convert to a line, but there's the problem of infinity of
length. Would it ever really make sense to do this?  Why not just align
an svg object?  This could be made more precise if we had an angle
snapping mode.

> 8. Can I put text on it, and if yes, then where does it start?

Just align the text - no need for this.

> 9. What is displayed when I select a guide in the node editor?

Nothing - just like for bitmap objects.  If there are no nodes, it does
nothing.

>
> Some of those could be solved by defining guides in terms of two
> points and a line that goes through them; the segment between the
> points could have a different color, and determine the bounding box
> for transformations.

I guess that's basically the same idea I mentioned above.

JF

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[Krzysztof Kosiński]

W dniu 30 września 2009 16:28 użytkownik Joshua Facemyer
<jfacemyer@...> napisał:
> Krzysztof Kosiński wrote:
>> 1. Where do we display the transformation handles when only guides are
>> selected, and how does the selection cue look like?
>
> You only need to display rotation guides - make two rounded double-ended
> arrows on either side of the rotation point, which would also be hi-lighted.
>  Dragging these transforms (rotates), dragging the rotation point moves it
> along the guide.

The problem is that those arrows would be very close to the rotation
point and therefore not very precise. One could drag them away from
the point before rotating but it's rather annoying to do it every
time.

>> 7. What is the effect of "convert to path"?
> It could convert to a line, but there's the problem of infinity of length.
> Would it ever really make sense to do this?  Why not just align an svg
> object?  This could be made more precise if we had an angle snapping mode.

This is necessary for e.g. cutting shapes. A safe option would be to
convert to a line that extends to the edges of the geometric box of
the entire drawing.

>> 8. Can I put text on it, and if yes, then where does it start?
> Just align the text - no need for this.

Aligning never rotates the aligned object, and in the case of an
angled guide aligning the baseline of text to its rotation point is
not something the user would want. Moreover if the guide is rotated,
the text should rotate as well. So we need 'text on path' for this.

Regards, Krzysztof

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[Joshua Facemyer]

Krzysztof Kosiński wrote:
>> You only need to display rotation guides - make two rounded double-ended
>> arrows on either side of the rotation point, which would also be hi-lighted.
>>  Dragging these transforms (rotates), dragging the rotation point moves it
>> along the guide.
>
> The problem is that those arrows would be very close to the rotation
> point and therefore not very precise. One could drag them away from
> the point before rotating but it's rather annoying to do it every
> time.

Not necessarily - couldn't they be wherever we want - like, say, 50% of
the distance between the rotation point and the edge of the viewport?
Or they could move dynamically along the guide when you grab it to
rotate.  In fact, that might be a lot better.  You grabe the rotation
handle and slide it out more for more precision as you rotate.

>>> 7. What is the effect of "convert to path"?
>> It could convert to a line, but there's the problem of infinity of length.
>> Would it ever really make sense to do this?  Why not just align an svg
>> object?  This could be made more precise if we had an angle snapping mode.
>
> This is necessary for e.g. cutting shapes.

Not sure what you mean.

> A safe option would be to
> convert to a line that extends to the edges of the geometric box of
> the entire drawing.

I still think it might be better to just leave it out.  You'll have to
adjust it more likely than not anyway.

Or, maybe a nice option would be to make snapping the start and end
points of an object to guides very simple.

>
>>> 8. Can I put text on it, and if yes, then where does it start?
>> Just align the text - no need for this.
>
> Aligning never rotates the aligned object, and in the case of an
> angled guide aligning the baseline of text to its rotation point is
> not something the user would want. Moreover if the guide is rotated,
> the text should rotate as well. So we need 'text on path' for this.

As I had mentioned in another point, rotation snapping would be a great
solution to this.  Also, specification of snapping point for text (to
baseline or bottom) would work here.

However, I don't think that guides should be expected to do everything
any other object does, since they are only guides.  I don't think it's
very intuitive to have any object attached to a guide.  It's no longer a
"guide", if that's the case.

JF

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[LucaDC]

My thoughts about all this:

 - guides already have an origin so there's no need to add other reference points on them; every operation done on a guide are intuitively expected to be done on it (e.g. aligning or distributing, something I would appreciate if added);

 - I don't feel the need to have guides behave exactly as other objects: they are only guides, used for snapping or aligning other objects; if you want particular effects done on it, use lines (or does anyone want to blur a guide?);

 - "convert guide to path" is simply creating a segment (a two point straight path) with its nodes laying somewhere on the guide, something really easy to do with already existing tools (and you can choose from where to where without having programmers guess what you want); also, this eliminates the problem of which styles to apply to border and fill (if a guide has only fill and no border, converting it to a segment with only fill and no border would lead to an invisible object!);

 - I expect guides not being selected when I drag-select "normal" objects: I think at guides as something "stick to the paper" I'm drawing on so they are a reference; I wouldn't like having guides "mess with normal objects" (again, I would use segments if I need so);
 - the same applies to moving, rotating, grouping, and so on; I understand that being able to move (or scale) some objects together with the guides they are based on is interesting, but I'm not sure that this is what is always wanted so this could introduce difficoulties in other "normal" operations (like selecting some objects and not the underlying guides); what about introducing "construction lines", different than guides in exactly this aspect so they are managed as "normal" objects and follow them in transformations?
 - thinking of a grid that moves or scales or rotates if I (accidentally) drag-select it, simply frightens me;

 - a way to easily select multiple guides (to move or delete them) must be added and it definitely must be different than for other objects (so you don't use it accidentally);

 - having guides of different colours could create nice effects in my technical drawings... it's a pity they are not printed and that I don't have a colour laser printer... :) to say I don't feel this need; actually one interesting thing that could solve different problems without involving poor guides would be the possibility to have 0-thickness lines with a border (different than lines with no border), so they are always drawn with 1 pixel width depending on the device resolution (1 point if printed, 1 pixel on screen regardless the zoom level, etc...); I don't know if this is allowed by SVG specifications; they could be moved, aligned, rotated, scaled, jiust like normal objects as they would be normal objects;

 - I don't want objects sticking to guides: what when I want to move a guide? would all objects I aligned on it follow me? Aaargh!

Please, let guides (and grids) rest in place.

Luca

[~suv-2]

On 30/9/09 18:48, LucaDC wrote:
> Please, let guides (and grids) rest in place.

I had no idea what kind of Pandora's box i opened when voicing my
concerns about the new <Del> command for guides. No need to repeat
Luca's long list - I agree and second his views.

Please let the guides stay guides, but add
- rotational snap (for guides and objects)
- extend/trim (of straight path segments)
and any combination of guide line positioning is possible combined with
the powerful 'Objects to Guides' command which even works with LPEs
(take 'Ruler' or 'Interpolate' or 'Stitch' to create amazing Guides sets).

The new 'delete' command which re-uses a keyboard shortcut for objects
but not the same selection mechanism still concerns me and I really
would like to see it changed back to 'Ctrl' or another combination of
meta-keys that is still available for guides. Or - if possible: define a
verb for it so the user can redefine the shortcut in 'keys/default.xml'.

~suv


------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[Krzysztof Kosiński]

2009/9/30 LucaDC <dicappello@...>:
> actually one
> interesting thing that could solve different problems without involving poor
> guides would be the possibility to have 0-thickness lines with a border
> (different than lines with no border), so they are always drawn with 1 pixel
> width depending on the device resolution (1 point if printed, 1 pixel on
> screen regardless the zoom level, etc...)

This is not allowed in SVG 1.1. There is a vector effect called
"non-scaling-stroke" in SVG 1.2 Tiny which effectively lets you
specify the width in output user units (which is more powerful than
simple hairline strokes :) ), but I think it's not supported in other
programs yet.

Regards, Krzysztof

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[Krzysztof Kosiński]

Sorry, forgot the link to non-scaling stroke specification:
http://www.w3.org/TR/2005/WD-SVGMobile12-20051207/painting.html#NonScalingStroke

Regards, Krzysztof

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel