Re: [Inkscape-devel] rotating guides
2009/9/28 ~suv <suv-sf@...58...>:
While I never really appreciated the new way to delete a guide (I have to reach across the keyboard (laptop) for the <Backspace> key, whereas <Ctrl> is in reach of the resting left hand) now I long for the previous behavior! Many times I accidentally have removed a selected object instead of the to-be-deleted guide - without noticing first, so that I was forced to go through the undo list to discover how far I needed to go back to retrieve the lost object.
Sorry for storming into this discussion (I'm not much into guides), but wouldn't this be solved if we had right click menus that were actually contextual? A guide could then by deleted by right clicking it and selecting Delete Guide.
I don't think making guides selectable is a good idea, because barring any ugly hacks we can only select SPObjects.
Regards, Krzysztof
2009/9/29 Krzysztof Kosiński wrote:
I don't think making guides selectable is a good idea, because barring any ugly hacks we can only select SPObjects.
I'm sorry for being so arrogant, but there is a huge difference between developer's and user's point of view. What you are saying basically boils down to "I don't think this is a good idea, because I don't know how to implement it nicely".
Alexandre
On 9/29/09, Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote:
I'm sorry for being so arrogant, but there is a huge difference between developer's and user's point of view. What you are saying basically boils down to "I don't think this is a good idea, because I don't know how to implement it nicely".
You are unfair. Krzysztof spoke about "ugly hack", not difficulty in implementation. And ugly hacks are bad not only for developers, but above all, for users. They break consistency of the UI, breed confusion and uncertainty, and lead to further unnatural hacks and usage practices. For example, in this case, if we make guides selectable, this will open a whole can of worms - people will complain that the guides cannot be painted by clicking on a color swatch, cannot be aligned with Align dialog, cannot be grouped etc. etc. A lot of things that are natural for objects make little sense for guides, but by allowing to select them we hint that they are "sort of" objects. The amount of special-casing that this will require in the code and, more importantly, in user documentation and user habits and practices is rather frightening.
On Tue, Sep 29, 2009 at 10:03 PM, bulia byak wrote:
usage practices. For example, in this case, if we make guides selectable, this will open a whole can of worms - people will complain that the guides cannot be painted by clicking on a color swatch, cannot be aligned with Align dialog, cannot be grouped etc. etc.
Ahem. Distributing guides via align'n'distribute dialog actually makes a perfect sense. And if you take a time to play with Scribus 1.3.5, you'll notice how handy it is to select a guide and then align objects to it in various ways.
Alexandre
On Tue, Sep 29, 2009 at 10:10 PM, Alexandre Prokoudine wrote:
usage practices. For example, in this case, if we make guides selectable, this will open a whole can of worms - people will complain that the guides cannot be painted by clicking on a color swatch, cannot be aligned with Align dialog, cannot be grouped etc. etc.
Ahem. Distributing guides via align'n'distribute dialog actually makes a perfect sense. And if you take a time to play with Scribus 1.3.5, you'll notice how handy it is to select a guide and then align objects to it in various ways.
And I bet that giving visible names to guides a-la FontForge is out of question too? :)
Alexandre
On 9/29/09, Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote:
And I bet that giving visible names to guides a-la FontForge is out of question too? :)
Why not, a name is a sensible thing to give to a guide.
On 9/29/09, Alexandre Prokoudine <alexandre.prokoudine@...400...> 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".
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) Some more options for creating them in places like that might be useful, but are probably doable as an extension very easily.
Cheers
John
2009/9/29 bulia byak <buliabyak@...400...>:
On 9/29/09, Alexandre Prokoudine <alexandre.prokoudine@...400...> 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".
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 29/9/09 22:01, john cliff wrote:
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) Some more options for creating them in places like that might be useful, but are probably doable as an extension very easily.
already in 0.47pre: 'Edit > Guides around Page' and 'Extensions > Render > Guides Creator...'
and for updated versions of the extension (for 0.46 and 0.46+devel) visit http://code.google.com/p/inkscape-guides-creator/
~suv
2009/9/29 bulia byak <buliabyak@...400...>:
On 9/29/09, Alexandre Prokoudine <alexandre.prokoudine@...400...> 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
2009/9/29 JimmyVolatile <spam@...2208...>:
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
2009/9/29 john cliff <john.cliff@...400...>:
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
2009/9/29 bulia byak <buliabyak@...400...>:
For example, in this case, if we make guides selectable, this will open a whole can of worms - people will complain that the guides cannot be painted by clicking on a color swatch, cannot be aligned with Align dialog, cannot be grouped etc. etc. A lot of things that are natural for objects make little sense for guides, but by allowing to select them we hint that they are "sort of" objects. The amount of special-casing that this will require in the code and, more importantly, in user documentation and user habits and practices is rather frightening.
Yes, this is more or less what I thought too but did not write in the comment :)
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. Alignment to objects would be best done by snapping. This would prevent the confusion between the concepts of object selection and guide selection, in much the same way there is no confusion between the concept of node and object selection in the node tool.
Another possilibity is to make guidelines SPObjects that are hidden when exporting, and not rendered by any other SVG viewers because they use the "inkscape" XML namespace, or are actually stored in some special toplevel element (after all this is why we have the SPObject/XML::Node separation). This is moderately problematic (for example guides do not have a bounding box) but might work.
Regards, Krzysztof
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
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
2009/9/30 Alexandre Prokoudine <alexandre.prokoudine@...400...>:
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
Krzysztof Kosiński wrote:
- 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.
- 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.
- What happens when I try to align a vertical guide and an angled guide?
They align at the rotation/align points.
- ... 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.
- 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).
- Can they be used as LPE parameters?
If it makes sense.
- 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.
- Can I put text on it, and if yes, then where does it start?
Just align the text - no need for this.
- 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
W dniu 30 września 2009 16:28 użytkownik Joshua Facemyer <jfacemyer@...400...> napisał:
Krzysztof Kosiński wrote:
- 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.
- 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.
- 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
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.
- 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.
- 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
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
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
2009/9/30 LucaDC <dicappello@...2144...>:
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
Sorry, forgot the link to non-scaling stroke specification: http://www.w3.org/TR/2005/WD-SVGMobile12-20051207/painting.html#NonScalingSt...
Regards, Krzysztof
participants (9)
-
Alexandre Prokoudine -
bulia byak -
JimmyVolatile -
john cliff -
Joshua Facemyer -
Krzysztof Kosiński -
LucaDC -
Maximilian Albert -
~suv