Re: [josm-dev] Lean JOSM - one-language trimmed down builds of JOSM

2009-11-01 Thread Frederik Ramm
Hi, Shaun McDonald wrote: I'll presume that all the GB should be replaced with MB, unless of course someone has managed to sneak in almost the whole planet into the jar file. Probably right although sneaking in the planet into the nightly build would of course be an option too - one

Re: [josm-dev] Lean JOSM - one-language trimmed down builds of JOSM

2009-11-01 Thread Dirk Stöcker
On Sun, 1 Nov 2009, Frederik Ramm wrote: PS: Is it possible to build a JOSM version that supports *only* language X and not English, or is support for English always built-in due to the way we do our I18N? Could I perhaps run a preprocessor to replace the built-in English texts by

[josm-dev] JOSM SVN rules

2009-11-01 Thread Dirk Stöcker
Hello, because I needed to reinvent the rules for JOSM SVN each time I asked a new developer to be member of JOSM (as I never found the older mails I had written), I now made an offical page: http://josm.openstreetmap.de/wiki/DevelopersGuide/SVN_Account Ciao -- http://www.dstoecker.eu/ (PGP

Re: [josm-dev] JOSM SVN rules

2009-11-01 Thread Ulf Lamping
Dirk Stöcker schrieb: Hello, because I needed to reinvent the rules for JOSM SVN each time I asked a new developer to be member of JOSM (as I never found the older mails I had written), I now made an offical page: http://josm.openstreetmap.de/wiki/DevelopersGuide/SVN_Account What do

Re: [josm-dev] JOSM SVN rules

2009-11-01 Thread Dirk Stöcker
On Sun, 1 Nov 2009, Ulf Lamping wrote: because I needed to reinvent the rules for JOSM SVN each time I asked a new developer to be member of JOSM (as I never found the older mails I had written), I now made an offical page: http://josm.openstreetmap.de/wiki/DevelopersGuide/SVN_Account What

[josm-dev] [PATCH] Extrude 'move along normal' and cleanups

2009-11-01 Thread Robert Scott
Hi, Attached is a patch against SVN 2374 which adds a feature to extrude mode: hold ctrl while dragging to move an existing segment along its normal rather than creating a new segment. This is needed to be able to easily edit buildings etc after they have been initially extruded. In adding

Re: [josm-dev] Extrude 'move along normal' and cleanups

2009-11-01 Thread Dirk Stöcker
On Sun, 1 Nov 2009, Robert Scott wrote: Please note I am a c++ programmer, not a java programmer, so comments are welcome. What should this change mean? -return tr(Drag a way segment to make a rectangle.); +return tr(); BTW: Best is to attach patches as Trac tickets.

Re: [josm-dev] Extrude 'move along normal' and cleanups

2009-11-01 Thread Robert Scott
On Sunday 01 November 2009, Dirk Stöcker wrote: What should this change mean? -return tr(Drag a way segment to make a rectangle.); +return tr(); The previous code used a 'mode' of null to represent the initial (non-dragging) state of the mapmode and an inconsistent

[josm-dev] jar compression level; JOSM takes too long to compile

2009-11-01 Thread Sebastian Klein
Hi, Frederik Ramm changed the jar compression level to maximum (9) in r2368. While I thank him for bringing this up, I would rather set it to 0 (uncompressed). This is because I spend quite some time waiting for JOSM to compile and compress. This is what I get: comress level time for

Re: [josm-dev] Extrude 'move along normal' and cleanups

2009-11-01 Thread Dirk Stöcker
On Sun, 1 Nov 2009, Robert Scott wrote: The previous code used a 'mode' of null to represent the initial (non-dragging) state of the mapmode and an inconsistent use of the 'select' mode. I changed it so null is an invalid mode and 'select' is the initial mode. Hence at this this line I

Re: [josm-dev] Extrude 'move along normal' and cleanups

2009-11-01 Thread Robert Scott
On Sunday 01 November 2009, Dirk Stöcker wrote: Then remove it. tr() results in the translators information string which is surely not wanted. Didn't think of that. I'll put the new patch on trac. robert. ___ josm-dev mailing list

[josm-dev] QuadBucket iteration speed (faster than josm-ng Storage)

2009-11-01 Thread Dave Hansen
There have been some concerns that using QuadBuckets makes data set iterations too slow. First of all, I hope that QuadBuckets will vastly reduce the number of full iterations over the data set that are *required* and replace them with coordinate-based searches. But, the concern is valid. I've