<div><span class="gmail_quote">On 10/12/05, <b class="gmail_sendername">Simon Hewison</b> <<a href="mailto:simon@zymurgy.org">simon@zymurgy.org</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><br>Yes, I am using the applet.<br><br>I *ALWAYS* end up pressing the plus key at least twice each time the
<br>applet refreshes, otherwise it becomes incredibly fiddly trying to be<br>pixel accurate.</blockquote>
<div> </div>
<div> </div>
<div>Yep, understood.  Some fixed-scales are in the works, and when we have those, I'll set a sensible line thickness for each scale.</div>
<div> </div><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">I would really like the line names to actually work and be persistent.</blockquote>
<div> </div>
<div> </div>
<div>So would I.  This is currently the only bug assigned to me, and I intend to fix it if Steve doesn't get there first.</div>
<div> </div><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">It would be nice for the applet to have a drag/pan tool within it, which<br>would then need to call out and fetch a new data set (google maps
<br>style), but it would be a lot quicker than reloading the entire applet.<br>My browser/java plug in seems to have a memory leak, and I'd prefer not<br>to reload an entire applet by clicking on the navigation in the HTML
<br>wrapping.</blockquote>
<div> </div>
<div>Yeah, we're currently stuck with "simplest thing that could possibly work" (using the static viewer to position, and then going into the editor) but I have similar issues with memory leaks and stuff, and Firefox users on Linux find it frustrating too.  This will be nicer when the static viewer goes all google maps style, but the applet needs to keep up.
</div>
<div> </div><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Once the key/value system is in, and the<br>street-is-composed-of-multiple-segments, we'll need some way of block
<br>selecting a set of segments and forming a street from it, or applying<br>the same key/value pair to everything on the selection. I was thinking<br>along the lines of the way that text highlighting tends to work:</blockquote>

<div> </div>
<div> </div>
<div>Me too!</div>
<div> </div><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">one click - select individual segement<br>double click - select all segments in each direction up to the point
<br>where a node has more than one link.<br>shift-click - select another individual line segment</blockquote>
<div> </div>
<div>I was going to go with shift-click for ranges and ctrl-click for individual add/remove from the selection set.  But yes, this is how it will work if I do it :)</div>
<div> </div>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">One really nice thing for doing motorways and dual-carriageways would be<br>a "convert selection to two carriageways".. but that would require
<br>quite a bit of geometry calculations to appropriately place new nodes<br>approximately 10 metres away, at an angle of half way between the two<br>line segments.</blockquote>
<div> </div>
<div>Sometimes carriages diverge quite a lot, but splitting and moving would be quicker than drawing twice in a lot of cases, I agree.</div>
<div> </div>
<div>Thanks Simon,</div>
<div> </div>
<div>Tom.</div></div>