On 12/11/10 4:09 PM, Christiaan Hofman wrote:
>

>
> I cannot tell you when precisely this discussion was held on this
> list, as SF's mail search has seriously deteriorated, I have the same
> information you have. But it has been discussed to death. The short
> discussion (that won't be revisited) is that without this (i.e. with
> your branch) it is virtually impossible to select the freehand note,
> and edit it (for instance to change the color or delete it, or join
> it to another, etc.) Now, everything important should at least be
> possible, therefore your solution is just no option. Also by not
> selecting the freehand note afterwards, you cannot easily change
> other properties like color and line style, or perhaps move it. There
> are conflicting requirement, it's necessarily a compromise, but
> making things impossible is most certainly not an acceptable option.
> In fact, as I said before, the fact that any solution would be
> necessarily imperfect was a very important reason to be reluctant to
> add the freehand note feature in the first place (also archived
> somewhere on this list).


Thanks for the reply.  I can certainly understand not wanting to spend a 
lot of time revisiting issues that have been thought and discussed a 
extensively.

You're right that my solution makes it necessary to go back to the 
selecting tool in order to change the properties of the lines, combine 
lines, etc.  These things are possible, but they just require the extra 
step of switching out of the freehand annotation tool.  For me, since I 
am hardly ever changing the properties of the line, or at least I break 
my annotations into writing and editing phases, that is not much of an 
issue.

I'm very glad you added the freehand annotation tool, even though it 
involves compromises!  I've often heard that "perfect" is the enemy of 
progress.  It would be nice if there was a hidden preference that let us 
switch between making it easy to write and making it easy to change line 
properties (so we as users get to decide which side of the compromise we 
need most).  But I'm perfectly fine with just applying my patch so that 
I get the functionality I need.  Hooray for open-source!


> Moreover, the margin to select the line is
> pretty small (smaller than it was), so I really believe this should
> be such a big problem.

I tried for a while to get used to this, but in many of my strokes in 
printing letters, I would start a stroke virtually on top of another 
stroke (for example, writing a capital "D" or capital "P").  That would 
select the previous stroke and I would lose my thought as I had to deal 
with moving the previous stroke back, etc.

Thanks again for all you've done!

Jason


------------------------------------------------------------------------------
Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL,
new data types, scalar functions, improved concurrency, built-in packages, 
OCI, SQL*Plus, data movement tools, best practices and more.
http://p.sf.net/sfu/oracle-sfdev2dev 
_______________________________________________
Skim-app-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/skim-app-users

Reply via email to