Inkscape

You have to shift-click the guide "far enough" from the rotation center to
activate rotation.
If you shift-click "near enough to" or inside the rotation center circle you
move it through its guide.
I hope this helps you.



Alexandre Prokoudine wrote:
> 
> Hi,
> 
> I know that it might sound unbelievably silly, but no matter how hard
> I try I can't get guides to rotate on canvas. The release notes
> doesn't really explain how to do it. I tried all combinations of Ctrl,
> Alt and Shift above rotation circle mark. So, any clue?
> 
> Alexandre
> 
> ------------------------------------------------------------------------------
> Are you an open source citizen? Join us for the Open Source Bridge
> conference!
> Portland, OR, June 17-19. Two days of sessions, one day of unconference:
> $250.
> Need another reason to go? 24-hour hacker lounge. Register today!
> http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
> _______________________________________________
> Inkscape-devel mailing list
> Inkscape-devel@...
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
> 
> 

-- 
View this message in context: http://www.nabble.com/rotating-guides-tp24145025p24145197.html
Sent from the Inkscape - Dev mailing list archive at Nabble.com.

Press shift before grabbing the guide, and grab it at some distance from its
rotation origin

Et voila!

Diederik

> -----Original Message-----
> From: Alexandre Prokoudine [mailto:alexandre.prokoudine@...]
> Sent: 2009 jun 22 12:35
> To: Inkscape Devel List
> Subject: [Inkscape-devel] rotating guides
> 
> Hi,
> 
> I know that it might sound unbelievably silly, but no matter how hard
> I try I can't get guides to rotate on canvas. The release notes
> doesn't really explain how to do it. I tried all combinations of Ctrl,
> Alt and Shift above rotation circle mark. So, any clue?
> 
> Alexandre
> 
>
----------------------------------------------------------------------------
> --
> Are you an open source citizen? Join us for the Open Source Bridge
> conference!
> Portland, OR, June 17-19. Two days of sessions, one day of unconference:
> $250.
> Need another reason to go? 24-hour hacker lounge. Register today!
>
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.o
> rg
> _______________________________________________
> Inkscape-devel mailing list
> Inkscape-devel@...
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel

Aha, thanks.

The question is... Is it discoverable? :)

Alexandre

On Mon, Jun 22, 2009 at 2:53 PM, Diederik van Lierop wrote:
> Press shift before grabbing the guide, and grab it at some distance from its
> rotation origin
>
> Et voila!
>
> Diederik

>The question is... Is it discoverable? :)

from my 'engineeric' pov — yes it is

-- 
C уважением, Коптев Олег
With respect, Oleg Koptev, SISAM LLC.

Jabber ID - koptevoleg@...

for my "designer-istics" pov was not too discoverable  ( have I an
poorest IQ ?? )


2009/6/22 Oleg Koptev <koptev.oleg@...>:
>>The question is... Is it discoverable? :)
>
> from my 'engineeric' pov — yes it is
>
> --
> C уважением, Коптев Олег
> With respect, Oleg Koptev, SISAM LLC.
>
> Jabber ID - koptevoleg@...
> ------------------------------------------------------------------------------
> Are you an open source citizen? Join us for the Open Source Bridge conference!
> Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
> Need another reason to go? 24-hour hacker lounge. Register today!
> http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
> _______________________________________________
> Inkscape-devel mailing list
> Inkscape-devel@...
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
>



-- 
Nemes Ioan Sorin

On Mon, Jun 22, 2009 at 3:26 PM, Oleg Koptev wrote:
>>The question is... Is it discoverable? :)
>
> from my 'engineeric' pov — yes it is

Even when rotation mark shouldn't really be involved as it turned out? :)

Alexandre

I hope nope :)
I think it is simply more like 'lever-law', so it is more 'physical'

p.s. i remember my iq's is about 140 - don't know how high or low it is.

2009/6/22, SorinN <nemes.sorin@...>:
> for my "designer-istics" pov was not too discoverable  ( have I an
> poorest IQ ?? )
>
>
> 2009/6/22 Oleg Koptev <koptev.oleg@...>:
>>>The question is... Is it discoverable? :)
>>
>> from my 'engineeric' pov — yes it is
>>
>> --
>> C уважением, Коптев Олег
>> With respect, Oleg Koptev, SISAM LLC.
>>
>> Jabber ID - koptevoleg@...
>> ------------------------------------------------------------------------------
>> Are you an open source citizen? Join us for the Open Source Bridge
>> conference!
>> Portland, OR, June 17-19. Two days of sessions, one day of unconference:
>> $250.
>> Need another reason to go? 24-hour hacker lounge. Register today!
>> http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
>> _______________________________________________
>> Inkscape-devel mailing list
>> Inkscape-devel@...
>> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
>>
>
>
>
> --
> Nemes Ioan Sorin
>


-- 
C уважением, Коптев Олег
With respect, Oleg Koptev, SISAM LLC.

Jabber ID - koptevoleg@...

Being discoverable or not doesn't prevent from being written in the Release
Note.

Steren

On Mon, Jun 22, 2009 at 2:13 PM, Oleg Koptev <koptev.oleg@...> wrote:

> I hope nope :)
> I think it is simply more like 'lever-law', so it is more 'physical'
>
> p.s. i remember my iq's is about 140 - don't know how high or low it is.
>
> 2009/6/22, SorinN <nemes.sorin@...>:
> > for my "designer-istics" pov was not too discoverable  ( have I an
> > poorest IQ ?? )
> >
> >
> > 2009/6/22 Oleg Koptev <koptev.oleg@...>:
> >>>The question is... Is it discoverable? :)
> >>
> >> from my 'engineeric' pov -- yes it is
> >>
> >> --
> >> C уважением, Коптев Олег
> >> With respect, Oleg Koptev, SISAM LLC.
> >>
> >> Jabber ID - koptevoleg@...
> >>
> ------------------------------------------------------------------------------
> >> Are you an open source citizen? Join us for the Open Source Bridge
> >> conference!
> >> Portland, OR, June 17-19. Two days of sessions, one day of unconference:
> >> $250.
> >> Need another reason to go? 24-hour hacker lounge. Register today!
> >>
> http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
> >> _______________________________________________
> >> Inkscape-devel mailing list
> >> Inkscape-devel@...
> >> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
> >>
> >
> >
> >
> > --
> > Nemes Ioan Sorin
> >
>
>
> --
> C уважением, Коптев Олег
> With respect, Oleg Koptev, SISAM LLC.
>
> Jabber ID - koptevoleg@...
>
>
> ------------------------------------------------------------------------------
> Are you an open source citizen? Join us for the Open Source Bridge
> conference!
> Portland, OR, June 17-19. Two days of sessions, one day of unconference:
> $250.
> Need another reason to go? 24-hour hacker lounge. Register today!
>
> http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
> _______________________________________________
> Inkscape-devel mailing list
> Inkscape-devel@...
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
>

;) Average is in between 100-110

 People with IQ's of 120 and above tend to staff the professions as
doctors, dentists, lawyers, teachers, and college professors. They
fall in the upper 10% of the population. So ..you must be good ...too
good to become the second Bill Gates ..sorry for you :) and sorry for
3 words offtopic

...talking now about Discoverability -> the tradition for a normal
designer ( Corel, Illustrator ) is to look at the status bar for
descriptive messages - I observed there is a message when I move the
mouse over a guideline : Guideline vertical at xxx mm position [ I am
now with Inkscape under XP - I dont check that on Ubuntu yet, ,but
I'll compile the new SVN version when I'm done with my work - BTW I am
now in Windows because I can't use Color Management so I translated
all my Inkscape models in Illustrator to check the right colors ]

Now the question is if there, along the normal text  ... Guideline
vertical at xxx mm position ... can be another descriptive portion
like : Drag to move, Shift + Drag to rotate, Ctrl + Click to delete.

 I hope this will not take too much from development progress - in
case if is possible.

SorinN

P.S. Now - to Shift or not too shift ? - this is the question.

2009/6/22 Oleg Koptev <koptev.oleg@...>:
> I hope nope :)
> I think it is simply more like 'lever-law', so it is more 'physical'
>
> p.s. i remember my iq's is about 140 - don't know how high or low it is.
>
> 2009/6/22, SorinN <nemes.sorin@...>:
>> for my "designer-istics" pov was not too discoverable  ( have I an
>> poorest IQ ?? )
>>
>>
>> 2009/6/22 Oleg Koptev <koptev.oleg@...>:
>>>>The question is... Is it discoverable? :)
>>>
>>> from my 'engineeric' pov — yes it is
>>>
>>> --
>>> C уважением, Коптев Олег
>>> With respect, Oleg Koptev, SISAM LLC.
>>>
>>> Jabber ID - koptevoleg@...
>>> ------------------------------------------------------------------------------
>>> Are you an open source citizen? Join us for the Open Source Bridge
>>> conference!
>>> Portland, OR, June 17-19. Two days of sessions, one day of unconference:
>>> $250.
>>> Need another reason to go? 24-hour hacker lounge. Register today!
>>> http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
>>> _______________________________________________
>>> Inkscape-devel mailing list
>>> Inkscape-devel@...
>>> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
>>>
>>
>>
>>
>> --
>> Nemes Ioan Sorin
>>
>
>
> --
> C уважением, Коптев Олег
> With respect, Oleg Koptev, SISAM LLC.
>
> Jabber ID - koptevoleg@...
>



-- 
Nemes Ioan Sorin

> I'll compile the new SVN version when I'm done with my work - BTW I am
> now in Windows because I can't use Color Management so I translated
> all my Inkscape models in Illustrator to check the right colors 

The color management actually works on XP now.

Copy profiles to this location: 
C:\Documents and Settings\All Users\Application Data\color\icc

and enable color management in the preferences file

On Mon, Jun 22, 2009 at 7:51 AM, LucaDC<dicappello@...> wrote:
>
> You have to shift-click the guide "far enough" from the rotation center to
> activate rotation.
> If you shift-click "near enough to" or inside the rotation center circle you
> move it through its guide.
> I hope this helps you.

In rev 21647 I added a statusbar hint, made cursor change when you're
about to rotate (i.e. far from anchor over the guide and with Shift
pressed), and implemented rotation snapping with Shift+Ctrl. Release
notes are updated.

-- 
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org

Thanks to bulia byak for working on guides. It's a tool I can't live without
and it's been improved so much that I find it really powerful.

Sincerely, I preferred the old arrow cursor (I work under Windows). Now the
four-arrow is less precise and its changing whenever you hover is a bit
disturbing. I understand that on different OSs the default cursor can be
problematic but this imposes the change also where it's not.

Anyway, if you are already over the guide, shift-click to rotate (without
moving the mouse) and start the rotation, the cursor never changes. This
happens also under other circumstances where you click (or unclick) without
moving the cursor. I don't know if this is an OS issue and can be fixed.

Another thing I noticed is that the rotation snap is calculated from the
guide's starting position. I think that as guides are used as absolute
anchors, it would be more intuitive to have absolute snapping angles also
(i.e. if the guide is at -2.25° and the snapping is every 15°, the snapping
will be 0°, 15°, 30°... not -2.25°, 12.75°, 27.75°...). I don't feel that
the relative snapping could be really useful (at least to me), but maybe I'm
wrong.

And finally, I'd like to ask: is there a real reason for which the guide's
origin can't be forced under the cursor whenever you grab the guide? This
would let you snap the origin to a particular point simply moving and
snapping the guide. Is it useful moving the guide and having the origin move
accordingly? I can say that for what I use Inkscape I never need this, but
maybe under different circumstances someone could. That's why I ask. If not,
would it be difficoult to implement?
And in any case, if you move the guide by hand you cannot place its origin
precisely and you could obtain the same result snapping the guide and then
sliding the origin through it; if you don't need to snap the guide you coudl
directly place the origin where desired (and maybe having it under the
cursor makes the whole more intuitive).

Thanks for your work.



bulia byak wrote:
> 
> In rev 21647 I added a statusbar hint, made cursor change when you're
> about to rotate (i.e. far from anchor over the guide and with Shift
> pressed), and implemented rotation snapping with Shift+Ctrl. Release
> notes are updated.
> 
> -- 
> bulia byak
> Inkscape. Draw Freely.
> http://www.inkscape.org
> 
> ------------------------------------------------------------------------------
> Are you an open source citizen? Join us for the Open Source Bridge
> conference!
> Portland, OR, June 17-19. Two days of sessions, one day of unconference:
> $250.
> Need another reason to go? 24-hour hacker lounge. Register today!
> http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
> _______________________________________________
> Inkscape-devel mailing list
> Inkscape-devel@...
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
> 
> 

-- 
View this message in context: http://www.nabble.com/rotating-guides-tp24145025p24161476.html
Sent from the Inkscape - Dev mailing list archive at Nabble.com.

Ah, and the hint is "Shift+drag to rotate" also when you are over the origin,
so this does not completely solve the original problem :)

Luca



bulia byak wrote:
> 
> On Mon, Jun 22, 2009 at 7:51 AM, LucaDC<dicappello@...>
> wrote:
> In rev 21647 I added a statusbar hint, made cursor change when you're
> about to rotate (i.e. far from anchor over the guide and with Shift
> pressed), and implemented rotation snapping with Shift+Ctrl. Release
> notes are updated.
> 
> -- 
> bulia byak
> Inkscape. Draw Freely.
> http://www.inkscape.org
> 
> ------------------------------------------------------------------------------
> Are you an open source citizen? Join us for the Open Source Bridge
> conference!
> Portland, OR, June 17-19. Two days of sessions, one day of unconference:
> $250.
> Need another reason to go? 24-hour hacker lounge. Register today!
> http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
> _______________________________________________
> Inkscape-devel mailing list
> Inkscape-devel@...
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
> 
> 

-- 
View this message in context: http://www.nabble.com/rotating-guides-tp24145025p24161519.html
Sent from the Inkscape - Dev mailing list archive at Nabble.com.

On Tue, Jun 23, 2009 at 11:55 AM, LucaDC wrote:

> Ah, and the hint is "Shift+drag to rotate" also when you are over the origin,
> so this does not completely solve the original problem :)

What do we use the origin mark for, btw?

Alexandre

It should give evidence to where the rotation center is.
If you don't rotate guides, then you don't need it being displayed (so it
could be displayed only when you hover on the guide with shift pressed...).

Luca



Alexandre Prokoudine wrote:
> 
> On Tue, Jun 23, 2009 at 11:55 AM, LucaDC wrote:
> 
>> Ah, and the hint is "Shift+drag to rotate" also when you are over the
>> origin,
>> so this does not completely solve the original problem :)
> 
> What do we use the origin mark for, btw?
> 
> Alexandre
> 
> ------------------------------------------------------------------------------
> Are you an open source citizen? Join us for the Open Source Bridge
> conference!
> Portland, OR, June 17-19. Two days of sessions, one day of unconference:
> $250.
> Need another reason to go? 24-hour hacker lounge. Register today!
> http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
> _______________________________________________
> Inkscape-devel mailing list
> Inkscape-devel@...
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
> 
> 

-- 
View this message in context: http://www.nabble.com/rotating-guides-tp24145025p24165999.html
Sent from the Inkscape - Dev mailing list archive at Nabble.com.

On Tue, Jun 23, 2009 at 5:29 PM, LucaDC wrote:
>
> It should give evidence to where the rotation center is.

So let's sum it up :)

Every guide has a guide origin mark, which roughly indicates placement
of the point around which a guide can be rotated. Unlike other UI
elements it does not serve as *precise* indicator which means that you
do not really know how to use rotating on canvas until you read docs.

Alexandre

On 06/23/2009 03:38 PM, Alexandre Prokoudine wrote:
> Every guide has a guide origin mark, which roughly indicates placement
> of the point around which a guide can be rotated. 

What gives you the impression that it's imprecise? True, it's not a 
crosshair so it might not _look_ that accurate, but it really is 
accurate to the last decimal as far as I know. If not then that should 
be fixed obviously.

> Unlike other UI
> elements it does not serve as *precise* indicator which means that you
> do not really know how to use rotating on canvas until you read docs.
>   
I think I'm missing the point here: how does being imprecise affect the 
discoverability?

Diederik

Personally I had some difficoulties too in understanding how to manage guides
when the little circle first appeared, but I don't see anything wrong in
having to read the documentation to understand how to use well a program. Of
course it's better if you can avoid it but I think that when (not standard)
modifiers are involved either you try all the combinations (and it's not
always straightforward, this is one case) or you read some docs.
Then the problem moves on the completeness and clarity of the
documentation...

About the precision: the little circle doesn't give you the feeling of being
able to place it where you really want (now that you have a big arrowed
cross over it, on Windows, it's even worse!): only snapping does. That's why
I asked for (un)changing the cursor over guides and fixing/restyling the
snapping.

Thanks.
Luca



Alexandre Prokoudine wrote:
> 
> On Tue, Jun 23, 2009 at 5:29 PM, LucaDC wrote:
>>
>> It should give evidence to where the rotation center is.
> 
> So let's sum it up :)
> 
> Every guide has a guide origin mark, which roughly indicates placement
> of the point around which a guide can be rotated. Unlike other UI
> elements it does not serve as *precise* indicator which means that you
> do not really know how to use rotating on canvas until you read docs.
> 
> Alexandre
> 
> ------------------------------------------------------------------------------
> Are you an open source citizen? Join us for the Open Source Bridge
> conference!
> Portland, OR, June 17-19. Two days of sessions, one day of unconference:
> $250.
> Need another reason to go? 24-hour hacker lounge. Register today!
> http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
> _______________________________________________
> Inkscape-devel mailing list
> Inkscape-devel@...
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
> 
> 

-- 
View this message in context: http://www.nabble.com/rotating-guides-tp24145025p24216506.html
Sent from the Inkscape - Dev mailing list archive at Nabble.com.

On Fri, Jun 26, 2009 at 12:07 PM, LucaDC wrote:

> Personally I had some difficoulties too in understanding how to manage guides
> when the little circle first appeared,

Luckily thanks to changes by bulia this doesn't seem to be a problem anymore :)

Alexandre

Yep in a new compilation - I discovered what I search on the place
where - I think - any Corel Draw / Illustrator designer look first for
supplementary info's - on status bar.

Now the circle is complete -> It's easy to find that functionality.


2009/6/27 Alexandre Prokoudine <alexandre.prokoudine@...>:
> On Fri, Jun 26, 2009 at 12:07 PM, LucaDC wrote:
>
>> Personally I had some difficoulties too in understanding how to manage guides
>> when the little circle first appeared,
>
> Luckily thanks to changes by bulia this doesn't seem to be a problem anymore :)
>
> Alexandre
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Inkscape-devel mailing list
> Inkscape-devel@...
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
>



-- 
Nemes Ioan Sorin

Hi

About the guides once again :-) :

There's still something unintuitive with the guide's origin IMHO. When 
you try to drag the origin and try to snap it to something, you'll find 
out at some point that you didn't grab the origin but that you instead 
grabbed the guide itself. And if you really grab the origin itself (with 
SHIFT), you'll notice that you can only move it along the guide and not 
freely over the canvas in 2D. That's really something that we miss now. 
So I propose the following:
1) only when pressing shift, the origin should appear, then
2a) when grabbing the guide far away from the origin, it should rotate,
2b) when grabbing it close to the origin, we should be able to move the 
origin in two dimensions (currently it only moves in 1D, i.e. along the 
guide itself)
3) only when pressing both ctrl AND shift, the motion of the origin 
should be constrained to the guide like it is now

Wouldn't that make more sense?

Diederik

Op Wo, 1 juli, 2009 12:01, schreef LucaDC:
> These are my humble suggestions:
> 1) when moving the guide (no modifiers) you always also move (and snap)
> the
> origin, that goes under the cursor, in 2D (so wherever you click you
> always
> grab the guide at its origin: why moving the guide keeping the origin at
> the
> original distance from the grab/snapping point?); this behaviour would be
> consistent (=intuitive) to what happens when you create a guide;

That makes sense! If no one comes up with a valid use case for the current
behavior then I will implement it the way you suggest.

> 2) if shift is pressed when clicking, the guides always rotate (snapping
> to
> what's around or, if you press ctrl after the rotation is started, to
> absolute angles, i.e. always starting from 0, using the step specified in
> the preferences for when rotating objects);

So shift rotates ...

> 3) if ctrl-shift is pressed when clicking, the origin moves constrained to
> the guide (snapping to what's around projected perpendicularly to the
> guide;
> if you want something different you can create a new guide and snap to the
> intersection, while creating a guide perpendicular to a given one is not
> always straightforward; this is a general consideration regarding snapping
> while constrained).

... but when "adding ctrl to shift" not only it becomes constrained, but
it also changes from rotation to translation. In my opinion using ctrl
should only make the motion constrained, and not change the type of
transformation simultaneously.

So:
A) when dragging with no modifiers we will move the origin to the pointer
location (freely, in 2D)
B) with ctrl we will have a constrained translation of the origin along
the guide
C) with shift we will rotate
D) with ctrl-shift we will rotate to increments of the absolute angle

and with A), B), and C) Inkscape will snap depending on the snapping
parameters.

It looks like we're converging here, aren't we ;-) ? What do you think?

Diederik

Good.
I'd only warn about using ctrl alone as modifier as it's already in use to
delete the guide.
You could end up in accidentally deleting the guide of which you want to
move the origin.

Luca



Diederik van Lierop wrote:
> 
> So:
> A) when dragging with no modifiers we will move the origin to the pointer
> location (freely, in 2D)
> B) with ctrl we will have a constrained translation of the origin along
> the guide
> C) with shift we will rotate
> D) with ctrl-shift we will rotate to increments of the absolute angle
> 
> and with A), B), and C) Inkscape will snap depending on the snapping
> parameters.
> 
> It looks like we're converging here, aren't we ;-) ? What do you think?
> 
> Diederik
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Inkscape-devel mailing list
> Inkscape-devel@...
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
> 
> 

-- 
View this message in context: http://www.nabble.com/rotating-guides-tp24145025p24351661.html
Sent from the Inkscape - Dev mailing list archive at Nabble.com.

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 07/06/2009 10:35 AM, LucaDC wrote:
<blockquote cite="mid:24351661.post@..." type="cite">
  <pre wrap="">I'd only warn about using ctrl alone as modifier as it's already in use to delete the guide.
You could end up in accidentally deleting the guide of which you want to move the origin.
  </pre>
</blockquote>
<br>
Good point, I hadn't thought of that yet but I would have certainly run
into this problem. Thanks!<br>
<br>
1) We could distinguish between pressing ctrl before or after pressing
the mouse button, but that's not very attractive. <br>
2) We could leave the ctrl key for deleting, and do a constrained
translation of the origin only when the guide is grabbed near its
origin, and do a free translation of the guide when grabbing it
elsewhere (and positioning the origin at the location where we release
the mouse button). <br>
3) We could find another way to easily delete guides and use ctrl for
constrained translation. That's what most consistent because ctrl is
used in<br>
many cases already for constrained transformations. But I'm afraid that
people already got used to ctrl-click deletion, so we will have to find
a<br>
_really_ good alternative if we want to get consensus on this.&nbsp; What
about pressing the delete key when already dragging? It's a bit more
laborious than just ctrl-click, but it's close to being perfect IMHO.
Any other suggestions? <br>
<br>
Diederik<br>
<br>
<blockquote cite="mid:24351661.post@..." type="cite">
  <pre wrap="">

Diederik van Lierop wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">So:
A) when dragging with no modifiers we will move the origin to the pointer
location (freely, in 2D)
B) with ctrl we will have a constrained translation of the origin along
the guide
C) with shift we will rotate
D) with ctrl-shift we will rotate to increments of the absolute angle

and with A), B), and C) Inkscape will snap depending on the snapping
parameters.

It looks like we're converging here, aren't we ;-) ? What do you think?

Diederik


------------------------------------------------------------------------------
_______________________________________________
Inkscape-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Inkscape-devel@...>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/inkscape-devel">https://lists.sourceforge.net/lists/listinfo/inkscape-devel</a>


    </pre>
  </blockquote>
  <pre wrap=""><!---->
  </pre>
</blockquote>
<br>
</body>
</html>

On Mon, Jul 6, 2009 at 4:48 PM, Diederik van Lierop<mail@...> wrote:
> 1) We could distinguish between pressing ctrl before or after pressing the
> mouse button, but that's not very attractive.
> 2) We could leave the ctrl key for deleting, and do a constrained
> translation of the origin only when the guide is grabbed near its origin,
> and do a free translation of the guide when grabbing it elsewhere (and
> positioning the origin at the location where we release the mouse button).
> 3) We could find another way to easily delete guides and use ctrl for
> constrained translation. That's what most consistent because ctrl is used in
> many cases already for constrained transformations. But I'm afraid that
> people already got used to ctrl-click deletion, so we will have to find a
> _really_ good alternative if we want to get consensus on this.  What about
> pressing the delete key when already dragging? It's a bit more laborious
> than just ctrl-click, but it's close to being perfect IMHO. Any other
> suggestions?

What's wrong with only constrained rotating with Ctrl+Shift, and
deleting with Ctrl? This is what we have in the code right now and it
works for me.

-- 
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org

The reason I didn't suggest to think about a new way to delete guides is the
same that you explained: it's really difficoult to find a good alternative.
Ctrl-click is strange (I often did it by mistake at the beginning) but when
you get used it's easy. I was used to drag the guide outside the canvas but
now I never do so anymore (also if I've seen it works in Inkscape too now, I
can't say since when).

Left-click and select "delete guide"? Now there is no specific context menu
for guides.
But the new command should be very quick as the plugin for deleting all
guides is not easily reachable and one could need to delete a lot of guides
but not all existing ones.

I really have no other suggestions but either keeping the
distance-dependent-click or introducing a new modifier. Up to now I would
keep the former as it's already implemented.
I agree it's a pity that ctrl-click was allocated to something that has
nothing to do with constrained moving. Personally I could sacrifice the
quick-deleting command to coherence, but I feel it's not a practical
solution.

Luca



Diederik van Lierop wrote:
> 
> 
> 
> 
>   
> 
> 
> On 07/06/2009 10:35 AM, LucaDC wrote:
> 
>   I'd only warn about using ctrl alone as modifier as it's already in use
> to delete the guide.
> You could end up in accidentally deleting the guide of which you want to
> move the origin.
>   
> 
> 
> Good point, I hadn't thought of that yet but I would have certainly run
> into this problem. Thanks! 
> 
> 1) We could distinguish between pressing ctrl before or after pressing
> the mouse button, but that's not very attractive. 
> 2) We could leave the ctrl key for deleting, and do a constrained
> translation of the origin only when the guide is grabbed near its
> origin, and do a free translation of the guide when grabbing it
> elsewhere (and positioning the origin at the location where we release
> the mouse button). 
> 3) We could find another way to easily delete guides and use ctrl for
> constrained translation. That's what most consistent because ctrl is
> used in 
> many cases already for constrained transformations. But I'm afraid that
> people already got used to ctrl-click deletion, so we will have to find
> a 
> _really_ good alternative if we want to get consensus on this.  What
> about pressing the delete key when already dragging? It's a bit more
> laborious than just ctrl-click, but it's close to being perfect IMHO.
> Any other suggestions? 
> 
> Diederik 
> 
> 
>   
> 
> Diederik van Lierop wrote:
>   
>   
>     So:
> A) when dragging with no modifiers we will move the origin to the pointer
> location (freely, in 2D)
> B) with ctrl we will have a constrained translation of the origin along
> the guide
> C) with shift we will rotate
> D) with ctrl-shift we will rotate to increments of the absolute angle
> 
> and with A), B), and C) Inkscape will snap depending on the snapping
> parameters.
> 
> It looks like we're converging here, aren't we ;-) ? What do you think?
> 
> Diederik
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Inkscape-devel mailing list
> Inkscape-devel@... 
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel 
> 
> 
>     
>   
>   
>   
> 
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> 
> _______________________________________________
> Inkscape-devel mailing list
> Inkscape-devel@...
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
> 
> 

-- 
View this message in context: http://www.nabble.com/rotating-guides-tp24145025p24376635.html
Sent from the Inkscape - Dev mailing list archive at Nabble.com.

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 07/07/2009 12:33 AM, bulia byak wrote:
<blockquote
 cite="mid:3c78ff030907061533i5d44e6f2s3f9c731f9cdaf765@..."
 type="cite">
  <pre wrap="">On Mon, Jul 6, 2009 at 4:48 PM, Diederik van Lierop<a class="moz-txt-link-rfc2396E" href="mailto:mail@...> wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">1) We could distinguish between pressing ctrl before or after pressing the
mouse button, but that's not very attractive.
2) We could leave the ctrl key for deleting, and do a constrained
translation of the origin only when the guide is grabbed near its origin,
and do a free translation of the guide when grabbing it elsewhere (and
positioning the origin at the location where we release the mouse button).
3) We could find another way to easily delete guides and use ctrl for
constrained translation. That's what most consistent because ctrl is used in
many cases already for constrained transformations. But I'm afraid that
people already got used to ctrl-click deletion, so we will have to find a
_really_ good alternative if we want to get consensus on this.&nbsp; What about
pressing the delete key when already dragging? It's a bit more laborious
than just ctrl-click, but it's close to being perfect IMHO. Any other
suggestions?
    </pre>
  </blockquote>
  <pre wrap=""><!---->
What's wrong with only constrained rotating with Ctrl+Shift, and
deleting with Ctrl? This is what we have in the code right now and it
works for me.
  </pre>
</blockquote>
<br>
We should allow for free translation of the guide and constrained
translation of its origin. Most logically the former should have no
modifier key, whereas the latter should use the ctrl key because in
many other case the ctrl-key is used for constraining already. But as
you noticed the ctrl-key has already been assigned to deleting. On top
of that, rotating the guide and translating the origin, which are two
very different things, are both activated by shift, and the distinction
between these two modes is in where you grab the guide. Once you're
used to that it's OK, but it's not very straightforward. It's much
cleaner to have it like this:<br>
<br>
no modifiers for moving<br>
shift for rotation<br>
ctrl for constraining<br>
delete for deleting<br>
<br>
So we will end up like this<br>
A) when dragging with no modifiers we will move the origin to the
pointer location (freely, in 2D)<br>
B) with ctrl we will have a constrained translation of the origin along
the guide<br>
C) with shift we will rotate<br>
D) with ctrl-shift we will rotate to increments of the absolute angle<br>
E) when pressing delete when hovering above a guide in the selector
tool, or while dragging a guide, the guide will be deleted. We can even
add a context menu as Luca suggested<br>
<br>
If I remember correctly then this quick-deleting was not available in
v0.46, or was it? We'd better change (or at least find consensus on
either solution) now, before we hit the masses! <br>
<br>
Diederik<br>
<br>
</body>
</html>

2009/7/8 Diederik van Lierop <mail@...>:

> So we will end up like this
> A) when dragging with no modifiers we will move the origin to the pointer
> location (freely, in 2D)
> B) with ctrl we will have a constrained translation of the origin along the
> guide
> C) with shift we will rotate
> D) with ctrl-shift we will rotate to increments of the absolute angle
> E) when pressing delete when hovering above a guide in the selector tool, or
> while dragging a guide, the guide will be deleted. We can even add a context
> menu as Luca suggested
>
> If I remember correctly then this quick-deleting was not available in v0.46,
> or was it? We'd better change (or at least find consensus on either
> solution) now, before we hit the masses!

I agree. And I'd vote for the above suggestion, too, because it's the
most consistent and foreseeable. Indeed, quick-deleting with
Ctrl+click was introduced not so long ago, more or less as a quick
solution and because it wasn't foreseeable that full
translation/rotation abilities of guides were going to be implemented
soon. Now that these are availabe I'd personally vote for the more
consistent set of controls as described by Diederik above. The only
small thing is that I find it a bit inconvenient to use Delete because
it's located at the top right corner of the keyboard instead of
conveniently on the lower left. But it's still good enough, I guess.
Perhaps we can additionally have something like Ctrl+Alt+Click for
quick-deletion (or something similar; I don't know what would be most
appropriate)?

Max

On Tue, Jul 7, 2009 at 11:13 PM, Diederik van Lierop wrote:

> If I remember correctly then this quick-deleting was not available in v0.46,

Oh, it surely was. One of the best additions to that release :)

Alexandre

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 07/08/2009 04:44 AM, Maximilian Albert wrote:
<blockquote
 cite="mid:36204bf00907071944m6fef7eaeo6c766025882d3e2@..."
 type="cite">
  <pre wrap="">2009/7/8 Diederik van Lierop <a class="moz-txt-link-rfc2396E" href="mailto:mail@...>:

  </pre>
  <blockquote type="cite">
    <pre wrap="">So we will end up like this
A) when dragging with no modifiers we will move the origin to the pointer
location (freely, in 2D)
B) with ctrl we will have a constrained translation of the origin along the
guide
C) with shift we will rotate
D) with ctrl-shift we will rotate to increments of the absolute angle
E) when pressing delete when hovering above a guide in the selector tool, or
while dragging a guide, the guide will be deleted. We can even add a context
menu as Luca suggested

If I remember correctly then this quick-deleting was not available in v0.46,
or was it? We'd better change (or at least find consensus on either
solution) now, before we hit the masses!
    </pre>
  </blockquote>
  <pre wrap=""><!---->
I agree. And I'd vote for the above suggestion, too, because it's the
most consistent and foreseeable. </pre>
</blockquote>
<br>
Hi Max, thanks for chimming in!<br>
<br>
So if no one has any serious objections then I'll go ahead and change
this as soon as possible.<br>
<br>
Diederik<br>
</body>
</html>

For what it's worth, I suppose you already know that I completely agree.
I hope you'll find time to work on it soon.

Luca


Diederik van Lierop wrote:
> 
> 
> 
> 
>   
> 
> 
> On 07/08/2009 04:44 AM, Maximilian Albert wrote:
> 
>   2009/7/8 Diederik van Lierop <mail@...; :
> 
>   
>   
>     So we will end up like this
> A) when dragging with no modifiers we will move the origin to the pointer
> location (freely, in 2D)
> B) with ctrl we will have a constrained translation of the origin along
> the
> guide
> C) with shift we will rotate
> D) with ctrl-shift we will rotate to increments of the absolute angle
> E) when pressing delete when hovering above a guide in the selector tool,
> or
> while dragging a guide, the guide will be deleted. We can even add a
> context
> menu as Luca suggested
> 
> If I remember correctly then this quick-deleting was not available in
> v0.46,
> or was it? We'd better change (or at least find consensus on either
> solution) now, before we hit the masses!
>     
>   
>   
> I agree. And I'd vote for the above suggestion, too, because it's the
> most consistent and foreseeable. 
> 
> 
> Hi Max, thanks for chimming in! 
> 
> So if no one has any serious objections then I'll go ahead and change
> this as soon as possible. 
> 
> Diederik 
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge  
> This is your chance to win up to $100,000 in prizes! For a limited time, 
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full
> prize  
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> Inkscape-devel mailing list
> Inkscape-devel@...
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
> 
> 

-- 
View this message in context: http://www.nabble.com/rotating-guides-tp24145025p24457452.html
Sent from the Inkscape - Dev mailing list archive at Nabble.com.

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
On 07/13/2009 12:07 PM, Maximilian Albert wrote:
<blockquote
 cite="mid:36204bf00907130307g7c3d1ab7u206525de8d17db29@..."
 type="cite">
  <pre wrap="">Hi Diederik,

  </pre>
  <blockquote type="cite">
    <pre wrap="">Hi Max, thanks for chimming in!

So if no one has any serious objections then I'll go ahead and change this
as soon as possible.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Have you started working on this yet? I have very limited time
resources right now but I feel that if I work on anything at all it
would be best to choose some part of the code base I'm familiar with
and an easy task. So I guess changing the guide behaviour would be a
good way to disburden you somewhat and give you more time to continue
your awesome bug hunt. :-) Let me know what the status is.

Best regards,
Max

  </pre>
</blockquote>
No, I haven't started on this yet so please go ahead. Don't worry about
me, I don't get bored that easily ;-).<br>
<br>
Diederik<br>
</body>
</html>

2009/7/8 Diederik van Lierop <mail@...>:

> So we will end up like this
> A) when dragging with no modifiers we will move the origin to the pointer
> location (freely, in 2D)
> B) with ctrl we will have a constrained translation of the origin along the
> guide
> C) with shift we will rotate
> D) with ctrl-shift we will rotate to increments of the absolute angle
> E) when pressing delete when hovering above a guide in the selector tool, or
> while dragging a guide, the guide will be deleted. We can even add a context
> menu as Luca suggested

I just commited the corresponding changes to SVN (rev. 21846). Please
test extensively and report anything which is not yet as desired or
can still be improved. Apart from the things listed above, I also made
the cursor switch correctly between rotation and translation depending
on whether Shift is pressed or not (this didn't work 100% before) and
also removed the info about keyboard modifiers from the guides dialog
(the one which opens when double-clicking on a guide) because it's
essentially useless there and consumes a lot of space.

Some comments or issues I couldn't resolve:

1) There is a strange bug which can reproduced as follows: Start
Inkscape afresh and drag a guide out of the ruler. Then hover the
mouse over it and press Delete. Nothing happens, and the status bar
shows the message "Nothing was deleted". Now click anywhere on the
canvas, hover again over the guide and press Delete. This time the
guide gets deleted as intended. Even when the canvas-click occurs
before creating the guide, everything is normal. It seems a bit like
the canvas first has to be "activated" before keyboard events are
processed correctly.

The reason for this strange behaviour is that the first time the key
press is not propagated to sp_dt_guide_event() but gets caught earlier
and is then processed in sp_selection_delete(). However, after the
canvas-click the propagation to sp_dt_guide_event() works fine. I have
no clue where this comes from and any hints are greatly appreciated.
BTW, this is also the reason why the cursor doesn't change when you
hover over a newly created guide and press Shift (this also only works
after a canvas-click).

2) I don't know what to include in the status bar message. With a
description of all modifiers the message is definitely too long. Right
now I have it say "Shift+drag to rotate, Ctrl+drag to move origin, Del
to delete". In particular, I dropped "Drag to move" because it seemed
to me that users would expect this intuitively. Other suggestions?

3) IMHO it would be nice if the kind of guide movement could change
interactively when pressing/releasing a modifier while dragging a
guide. For example, when we start dragging and press Shift (while
continuing to drag) it would be nice if the motion switched to a
rotation. Or when starting to move the origin by Ctrl+dragging and
releasing the Ctrl key then the motion should switch to regular
dragging. What do you think? I tried to implement this but encountered
a bug similar to the one described in (1) which prevents some keyboard
events from being passed to sp_dt_guide_event(). I'm not sure if it's
caused by the same thing, though. Any hints where to look are again
highly appreciated.

4) LucaDC said he felt that the new cursor which appeared when
dragging a guide conveyed a feeling of imprecision, so I changed it
back to the original arrow-shaped cursor. For rotation, however, I
still use the new cursor. Is everyone happy with that?

5) In principle, snapping guides to other objects should work, but I
only manage to snap guides to other guides and to nothing else.
Diederik?

6) As mentioned above, guides are now deleted by pressing Del when
hovering over them. Is this sufficient or should we implement a second
shortcut similar to the original one (like Alt+Ctrl+click)?

Thanks for any comments!
Regards,
Max

On 07/16/2009 05:31 PM, Maximilian Albert wrote:

> I just commited the corresponding changes to SVN (rev. 21846). Please
> test extensively and report anything which is not yet as desired or
> can still be improved. 

Works like a charm! This behavior is far more intuitive IMHO!

One thing we could add is that ctrl-clicking on a guide at some distance 
of the origin immediately moves the origin to that position on the 
guide. Now you first have to get the origin and drag it to where you 
want it.

> 5) In principle, snapping guides to other objects should work, but I
> only manage to snap guides to other guides and to nothing else.
> Diederik?
>   

Snapping to objects works for me. Did you select the "snap to cusp 
nodes" button on the snap toolbar? By default no snap target is enabled, 
only the guides and the grids. Guides do not snap to grids yet, I still 
need to implement that.
> 6) As mentioned above, guides are now deleted by pressing Del when
> hovering over them. Is this sufficient or should we implement a second
> shortcut similar to the original one (like Alt+Ctrl+click)?
>   

While dragging or rotating a guide and pressing delete, nothing happens. 
However when I'm dragging the origin with ctrl, pressing del deletes the 
guide.

Thanks for your work Max, it's much appreciated!

Diederik

Hi,

	Is it possible to prevent the guide line from being moved when double
clicking on it (i.e. when opening the guide-line dialog)? The movement
make the "Relative change" option rather pointless as well as messing up
carefully set x and y values.

						Tav

Diederik van Lierop wrote:
> On 07/07/2009 12:33 AM, bulia byak wrote:
...
> 
> We should allow for free translation of the guide and constrained
> translation of its origin. Most logically the former should have no
> modifier key, whereas the latter should use the ctrl key because in many
> other case the ctrl-key is used for constraining already. But as you
> noticed the ctrl-key has already been assigned to deleting. On top of
> that, rotating the guide and translating the origin, which are two very
> different things, are both activated by shift, and the distinction
> between these two modes is in where you grab the guide. Once you're used
> to that it's OK, but it's not very straightforward. It's much cleaner to
> have it like this:
> 
> no modifiers for moving
> shift for rotation
> ctrl for constraining
> delete for deleting
> 
> So we will end up like this
> A) when dragging with no modifiers we will move the origin to the
> pointer location (freely, in 2D)
> B) with ctrl we will have a constrained translation of the origin along
> the guide

I might be too late, but it seems to me that we will have more
consistent behavior if we follow existing keybinding of other tools. For
example, here is what "Inkscape keyboard and mouse reference" says,

*Ctrl+Alt+mouse drag - move along handles*
This restricts movement to the directions of the node's handles, their
continuations and perpendiculars (total 8 snaps).

Ignoring rotation part, Ctrl+Alt will, with this modification, still
move handle point along (guide) line.

This small change would make behavior of somehow similar tools (to some
extent), well, similar. The only difference would be Shift becoming from
- no-snap modifier to - rotate modifier.

Hope this will be considered, at least.
Vlada

> C) with shift we will rotate
> D) with ctrl-shift we will rotate to increments of the absolute angle
> E) when pressing delete when hovering above a guide in the selector
> tool, or while dragging a guide, the guide will be deleted. We can even
> add a context menu as Luca suggested
> 
> If I remember correctly then this quick-deleting was not available in
> v0.46, or was it? We'd better change (or at least find consensus on
> either solution) now, before we hit the masses!
> 
> Diederik

Hi Tav,

>        Is it possible to prevent the guide line from being moved when double
> clicking on it (i.e. when opening the guide-line dialog)? The movement
> make the "Relative change" option rather pointless as well as messing up
> carefully set x and y values.

Sorry, but I cannot reproduce the problem. When I manually set the
position of a guide (e.g., via the guidelines dialog itself) and then
double click on it, I always get the same coordinates back when the
dialog opens. Can you give precise steps how to see the problem?

Best,
Max

2009/7/17 Vladimir Savic <vladimir.firefly.savic@...>:

> I might be too late, [...]

It is never too late in open source software. :-) However, I'd like to
hear other people's opinions on this before implementing it because
I've used Inkscape very little for real production work lately so that
I feel I can't thoroughly judge usability questions.

> but it seems to me that we will have more
> consistent behavior if we follow existing keybinding of other tools. For
> example, here is what "Inkscape keyboard and mouse reference" says,
>
> *Ctrl+Alt+mouse drag - move along handles*
> This restricts movement to the directions of the node's handles, their
> continuations and perpendiculars (total 8 snaps).
>
> Ignoring rotation part, Ctrl+Alt will, with this modification, still
> move handle point along (guide) line.
>
> This small change would make behavior of somehow similar tools (to some
> extent), well, similar. The only difference would be Shift becoming from
> - no-snap modifier to - rotate modifier.

I'm not sure if I understood the last paragraph correctly. Just to
make sure, your suggestion is to use Ctrl+Alt instead of Ctrl for
moving the anchor along the guide, right? Frankly, I'm not convinced.
If we implement this change then the Ctrl modifier (whithout Alt) will
be unused. Firstly, this forces the user to unnecessarily press a
second modifier to obtain constrained movement, which is cumbersome,
and secondly, it makes the feature a little less discoverable. In the
Node tool the Ctrl modifier alone also has a certain meaning, and it
is also related to constrained movement (as is generally the case in
Inkscape), so my personal opinion is that the analogy is still there
and we should leave it as it is. But I'm open to different opinions.
What do other people think?

Max

Great work!

> In particular, I dropped "Drag to move" because it seemed
> to me that users would expect this intuitively. Other suggestions?
I agree.

> 3) IMHO it would be nice if the kind of guide movement could change
> interactively when pressing/releasing a modifier while dragging a
> guide.
I think that this could be confusing. Anyway, if you think it would be
useful...

> 4) LucaDC said he felt that the new cursor which appeared when
> dragging a guide conveyed a feeling of imprecision, so I changed it
> back to the original arrow-shaped cursor.
Thanks a lot. :)

> For rotation, however, I
> still use the new cursor. Is everyone happy with that?
I am. The problem was grabbing the guide: after the operation has started
you don't need precision in the cursor anymore as you look at the object you
are moving, not at the cursor, I think (at least I do so).

> 6) As mentioned above, guides are now deleted by pressing Del when
> hovering over them. Is this sufficient or should we implement a second
> shortcut similar to the original one (like Alt+Ctrl+click)?
I won't add more shortcuts: then you have do document them, add a message on
the status bar and so on...

> Thanks for any comments!
> Regards,
> Max
Thanks to you.

Just let me add a couple of things:
 - delete doesn't work for me (Windows) while dragging the guide (actually,
I don't think it's important);
 - we spoke about showing the origin only when needed, so while dragging,
rotating its guide or sliding through it; is this difficoult to implement?
 - there's still no snapping while moving the origin throug the guide.
(ok, I know they are three... :)

Luca


------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel



-- 
View this message in context: http://www.nabble.com/rotating-guides-tp24145025p24537495.html
Sent from the Inkscape - Dev mailing list archive at Nabble.com.

Hi Max,

> >        Is it possible to prevent the guide line from being moved when double
> > clicking on it (i.e. when opening the guide-line dialog)? The movement
> > make the "Relative change" option rather pointless as well as messing up
> > carefully set x and y values.
> 
> Sorry, but I cannot reproduce the problem. When I manually set the
> position of a guide (e.g., via the guidelines dialog itself) and then
> double click on it, I always get the same coordinates back when the
> dialog opens. Can you give precise steps how to see the problem?

Hmmm, a little investigation shows that the problem only happens when I
am using the mouse with my Wacom tablet. If I use the laptop track pad
and buttons, the guide lines don't move.

					Tav

On 07/17/2009 12:39 PM, Vladimir Savic wrote:
> I might be too late, 
You're never too late, as Max already said!
> example, here is what "Inkscape keyboard and mouse reference" says,
>   

Thanks for pointing me at this document, I didn't know it existed!
> *Ctrl+Alt+mouse drag - move along handles*
> This restricts movement to the directions of the node's handles, their
> continuations and perpendiculars (total 8 snaps).
>
> Ignoring rotation part, Ctrl+Alt will, with this modification, still
> move handle point along (guide) line.
>   
But when looking at the selector tool, the rectangle tool, the star 
tool, the ellipse tool, and probably other tools too, you'll notice that 
there ctrl is used for constraining, so I'd prefer just ctrl, instead of 
ctrl-alt. On the other hand, it currently doesn't matter whether you use 
ctrl or ctrl+alt because Inkscape only looks for the ctrl key.

Diederik

On 07/16/2009 05:31 PM, Maximilian Albert wrote:
> 3) IMHO it would be nice if the kind of guide movement could change
> interactively when pressing/releasing a modifier while dragging a
> guide. 
Yes, I agree that that would be nice. However I don't have a clue what's 
going on in that bug you mentioned.

One little quirk I noticed when dragging the origin with ctrl: If you 
press shift too then the pointer changes to rotation, but you cannot 
actually rotate.

Diederik

On 07/17/2009 06:16 PM, LucaDC wrote:
>  - we spoke about showing the origin only when needed, so while dragging,
> rotating its guide or sliding through it; is this difficoult to implement?
>   
If we want to snap objects to the origin of the guide then the origin 
should probably be visible at all time. Do we want to snap to guide 
origins?

>  - there's still no snapping while moving the origin throug the guide.

Works for me! (but please remind that snapping guides to grids has not 
been implemented yet). Can you give me a bit more details, e.g. what 
snapping options have been enabled and what the steps are to reproduce 
this behavior?

Diederik

2009/7/18 Tavmjong Bah <tavmjong@...>:

> > >        Is it possible to prevent the guide line from being moved when double
> > > clicking on it (i.e. when opening the guide-line dialog)? The movement
> > > make the "Relative change" option rather pointless as well as messing up
> > > carefully set x and y values.
> >
> > Sorry, but I cannot reproduce the problem. When I manually set the
> > position of a guide (e.g., via the guidelines dialog itself) and then
> > double click on it, I always get the same coordinates back when the
> > dialog opens. Can you give precise steps how to see the problem?
>
> Hmmm, a little investigation shows that the problem only happens when I
> am using the mouse with my Wacom tablet. If I use the laptop track pad
> and buttons, the guide lines don't move.

That's odd, but unfortunately I cannot help with this because I don't
own a tablet. Did this behaviour already occur before my recent
changes? What happens, exactly? Does the guide already move after the
first of the two clicks or only after the second? By what amount, on
average? Do you inadvertently move the cursor between the two clicks
and are the two distances related, e.g., is the guide movement larger
if the second click happens further away from the first one?

Max

On Fri, Jul 17, 2009 at 8:16 PM, LucaDC wrote:

>> 6) As mentioned above, guides are now deleted by pressing Del when
>> hovering over them. Is this sufficient or should we implement a second
>> shortcut similar to the original one (like Alt+Ctrl+click)?
> I won't add more shortcuts: then you have do document them, add a message on
> the status bar and so on...

Well, I've grown to love Ctrl+Click, but I won't bitch about this
change even if deleting guides is longer now :)

Alexandre

On 07/17/2009 06:16 PM, LucaDC wrote:
>If we want to snap objects to the origin of the guide then the origin 
>should probably be visible at all time. Do we want to snap to guide 
>origins?
My opinon is that I won't snap on guides origins: a guide is a guide and
shouldn't have "preferences" over its points. If you want to snap to a
particular point you can use two guides and snap to the intersection. Also,
I prefer not seeing all those little circles on the drawing: when there are
a lot of guides I find them visually disturbing and sometimes I drag them
out of view to clean things up.

>>  - there's still no snapping while moving the origin throug the guide.
>Works for me! (but please remind that snapping guides to grids has not 
>been implemented yet). Can you give me a bit more details, e.g. what 
>snapping options have been enabled and what the steps are to reproduce 
>this behavior?
I simply expect the origin to snap wherever the guide snaps when dragging it
in 2D. Now this doesn't happen for me in WXP.
E.g.:
 - draw a rectangle;
 - add a guide and snap it to a corner (e.g. bottom-left);
 - rotate the guide so it snaps to the opposite corner (e.g. top-right);
 - drag the center on the guide to snap it on the opposite corner
(top-right): it doesn't.

Luca

------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel



-- 
View this message in context: http://www.nabble.com/rotating-guides-tp24145025p24565959.html
Sent from the Inkscape - Dev mailing list archive at Nabble.com.

Alexandre Prokoudine wrote:
> Well, I've grown to love Ctrl+Click, but I won't bitch about this
> change even if deleting guides is longer now :)

Yes, deleting guides is longer now, indeed: I always ctrl-click first, then
remember it doesn't work anymore and finally press delete... :)
I hope I'll get used as quickly as I learned ctrl-click.

One drawback of del is that if you have an object selected, you hover on a
guide to delete it but slightly move the mouse just before pressing del, you
delete the object. It's so difficoult to highlight a guide being the
selection margin so narrow!
Maybe a way to click-select the guide to delete (so the guide remains
selected also after you move the mouse away from it) would simplify the
operation.
And you could also select many guides (with shift) and delete them all
together with a single "del".

In fact, there is still the (old) problem of deleting many guides (non all
guides!): let me suggest something like a "guide rubber", i.e. something
like a selection rectangle that kills every guide it intersects or a
particular "fat" cursor that annihilates all guides it's clicked on.

Ah, and click-selecting guides could also allow copy-paste to generate a new
guide starting from an existing one, which is useful when you have
strange-angled guides.
And you could move a "guide set" to a different point...

Sorry, too many things!

Luca
-- 
View this message in context: http://www.nabble.com/rotating-guides-tp24145025p24566909.html
Sent from the Inkscape - Dev mailing list archive at Nabble.com.

On 20/7/09 12:00, LucaDC wrote:
> Alexandre Prokoudine wrote:
>> Well, I've grown to love Ctrl+Click, but I won't bitch about this
>> change even if deleting guides is longer now :)
> 
> Yes, deleting guides is longer now, indeed: I always ctrl-click first, then
> remember it doesn't work anymore and finally press delete... :)
> I hope I'll get used as quickly as I learned ctrl-click.
> 
> One drawback of del is that if you have an object selected, you hover on a
> guide to delete it but slightly move the mouse just before pressing del, you
> delete the object. It's so difficoult to highlight a guide being the
> selection margin so narrow!

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.

> Maybe a way to click-select the guide to delete (so the guide remains
> selected also after you move the mouse away from it) would simplify the
> operation.

It would not simplify the operation but give the user the necessary
feedback which object will be deleted with <DEL>. The color-changing of
hovering indicator is too easily overlooked when the mouse cursor is
slightly moved before the delete command. For me this seems increasingly
like a regression the more often I work with the new (and otherwise
fantastically improved!) guides features.

> And you could also select many guides (with shift) and delete them all
> together with a single "del".

seconded.

~suv

p.s. as an interim workaround to delete them all there's the extension
'Remove Guides' at
<http://screencasters.heathenx.org/blog/2009/06/09/inkscape-extension-remove-guides/>
- maybe a candidate to be included in 0.47?

2009/9/28 ~suv <suv-sf@...>:
> 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@...> 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.

-- 
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org

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@...> 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

On 9/29/09, Alexandre Prokoudine <alexandre.prokoudine@...> 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.

-- 
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org

2009/9/29 bulia byak <buliabyak@...>:
> 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

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@...>:
> 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".
>
> --
> bulia byak
> Inkscape. Draw Freely.
> http://www.inkscape.org
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; 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&#45;12, 2009. Register now&#33;
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Inkscape-devel mailing list
> Inkscape-devel@...
> 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@...>:
>
> > 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

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

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

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

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

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

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

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

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

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
-- 
View this message in context: http://www.nabble.com/rotating-guides-tp24145025p25684924.html
Sent from the Inkscape - Dev mailing list archive at Nabble.com.

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@...>:
> 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#NonScalingStroke

Regards, Krzysztof