Re: Call to plugin authors: svgs in JOSM

2020-10-17 Thread Holger Mappt

Hi,

I think I figured everything out. An important detail is to delete the
build directory with "ant clean" before running ant, otherwise the old
PNG images will appear in the JAR and JOSM picks the PNGs.

Thanks,
Holger

Am 15.10.20 um 15:31 schrieb simson.gert...@gmail.com:

Am 11.10.2020 um 18:09 schrieb Holger Mappt via josm-dev:

What are
recommended page sizes for map mode icons and menu icons?

For map view icons 16px, for gui icons usually 24px (which is the size
in the toolbar).

A short review results in these typical "sizes": Map view icons and main
toolbar icons are 24px, menu icons are 16px, status line icons are 18px,
preferences icons (on the left) are 48px.



Re: Call to plugin authors: svgs in JOSM

2020-10-11 Thread Holger Mappt via josm-dev

Hi,

Is there a JOSM icon style guide? What elements should be used to depict
different actions? E.g. I want to express move, that would be crossed
arrows like in the move map mode icon, right? Arrows in all directions
is zoom in/out or full screen. Do colors have a meaning? What are
recommended page sizes for map mode icons and menu icons?

Are there recommended icon sets that can be used as reference and that
have the right license to copy items?

Thanks,
Holger


Am 12.09.20 um 16:56 schrieb simson.gert...@gmail.com:

Hi,
there were constantly made improvements in the last years for better
hidpi support in JOSM. Since the newest JOSM tested version 17013 all
internal icons are in svg (except Potlatch2 mappaint style icons).
However most plugins still use png icons.
This is a call to all plugin authors to follow and to transform all
icons of your JOSM plugins to svg (or reuse core icons if suitable are
available). You don't want your pixelated icons stand out between the
sharp core icons ;)
I recommend to clean your svgs with svgcleaner to keep the plugin jar
file size small.

Regards,
Stefa






Re: JOSM developers meetup at Karlsruhe?

2018-09-09 Thread Holger Mappt

Hi,

I don't consider myself a real JOSM developer and I didn't have much 
time to contribute lately. But I would like to spend more time working 
on the project, so that's a good reason to get it started. Count me in.


Regards,
Holger


On 03.09.18 at 22:36 Vincent Privat wrote:

Hello,
I was thinking for quite some time about setting up a meeting between JOSM
developers somewhere in Germany (for convenience).
As Christine and Frederik are inviting OSM developers to Karlsruhe on
October 20th-21st, I just registered myself!
Would other team members be interested? I'd love to meet everyone in person!
As for JOSM projects/activities for this hack week-end, there are plenty of
them to work on, it will depend on who's there :)
Cheers,
Vincent






Re: Publish plugin issue

2018-06-03 Thread Holger Mappt

Hi Vincent,

I restored to original behavior without the SVN update and commit part 
(in r34244).


Regards,
Holger


On 2018-06-03 at 18:58 +0200 Vincent Privat wrote:

Hello,
This involves unneeded work from us. As said before, please restore the 
previous mechanism, which is being used for Nexus, and simply make sure 
only the plugin jar is commited, this is the only change that is required.

Best regards,
Vincent

2018-06-01 11:07 GMT+02:00 Holger Mappt:

On 2018-05-31 at 21:00 +0200 Dirk Stöcker wrote:

On Thu, 31 May 2018, Michael Zangl wrote:

We currently have all snapshot plugin jars including
source/javadoc on the nexus server:


https://josm.openstreetmap.de/nexus/content/groups/public/org/openstreetmap/josm/plugins/

<https://josm.openstreetmap.de/nexus/content/groups/public/org/openstreetmap/josm/plugins/>


You can pull them from there if you need them for anything.

For local development, you could just check out and add the
source directory of the plugin to your favorite IDE, you
don't need a jar file for this.


You forget that the nexus server uses this build procedure. If
it is disabled files will be gone there as well.


Hi,

That is the first hint what the sources and javadoc JARs are used
for. Is there a description how the Nexus thing works? What targets
does it call? How does it know what files are to be kept and from
where to take them?

How about a new target like "dist-all" that can be used to generate
everything that one can dream of? That target is used by Nexus or by
whoever wants everything. The regular plugin developer will continue
to use "dist". "dist-all" will generate the JARs in the dist
directory, *-javadoc.jar and *-sources.jar are in the ignore list
already. No SVN update/commit for sources.jar and javadoc.jar.





Re: Publish plugin issue

2018-06-02 Thread Holger Mappt

On 2018-05-31 at 21:00 +0200 Dirk Stöcker wrote:

On Thu, 31 May 2018, Michael Zangl wrote:

We currently have all snapshot plugin jars including source/javadoc 
on the nexus server:


https://josm.openstreetmap.de/nexus/content/groups/public/org/openstreetmap/josm/plugins/ 



You can pull them from there if you need them for anything.

For local development, you could just check out and add the source 
directory of the plugin to your favorite IDE, you don't need a jar 
file for this.


You forget that the nexus server uses this build procedure. If it is 
disabled files will be gone there as well.


Hi,

That is the first hint what the sources and javadoc JARs are used for. 
Is there a description how the Nexus thing works? What targets does it 
call? How does it know what files are to be kept and from where to take 
them?


How about a new target like "dist-all" that can be used to generate 
everything that one can dream of? That target is used by Nexus or by 
whoever wants everything. The regular plugin developer will continue to 
use "dist". "dist-all" will generate the JARs in the dist directory, 
*-javadoc.jar and *-sources.jar are in the ignore list already. No SVN 
update/commit for sources.jar and javadoc.jar.


Regards,
Holger

PS: The shenron.openstreetmap.org mail server delays the emails, e.g. 
Dirks email was delayed by 8 hours. Does someone know why it does that? 
The messages show up in the mail archive immediately, but I need to wait 
until I get it to be able to reply.





Re: Publish plugin issue

2018-05-30 Thread Holger Mappt

On 2018-05-30 at 11:57 +0200 Dirk Stöcker wrote:

On Wed, 30 May 2018, Holger Mappt wrote:

I don't see how that can be done without conflicts. If the sources and 
javadoc JARs are generated but not svn added and svn committed then 
those JARs are SVN private files. Everyone who runs the according 
target will have those private files in her/his working copy dist 
directory. If someone svn adds and svn commits the JARs then the next 
svn update will show merge conflicts because the JARs are now in the 
repository and the working copy as private files and SVN doesn't know 
what to do.


A clean solution is to either add the sources and javadoc JARs to all 
targets and to create+commit them for all plugins in dist, or not to 
do that. The sources and javadoc JARs that were added in r34045 were 
deleted in the next revision, so my assumption is that we don't want 
those JARs in dist.


So what's the plan with sources and javadoc JARs?


Vincent wants these files to build, but they should not to be released.

Add an svn:ignore in build directory?

Ciao


Hi,

Build the files to do what with them? Would a nodist directory parallel 
to dist be an option if the JARs are not to be uploaded to the repository?


The conflict will occur if the JARs are released later on. An svn:ignore 
will not help in that case. It is better to have separate directories 
for released and not released files.


Regards,
Holger




Re: Publish plugin issue

2018-05-30 Thread Holger Mappt

Hi Vincent,

I don't see how that can be done without conflicts. If the sources and 
javadoc JARs are generated but not svn added and svn committed then 
those JARs are SVN private files. Everyone who runs the according target 
will have those private files in her/his working copy dist directory. If 
someone svn adds and svn commits the JARs then the next svn update will 
show merge conflicts because the JARs are now in the repository and the 
working copy as private files and SVN doesn't know what to do.


A clean solution is to either add the sources and javadoc JARs to all 
targets and to create+commit them for all plugins in dist, or not to do 
that. The sources and javadoc JARs that were added in r34045 were 
deleted in the next revision, so my assumption is that we don't want 
those JARs in dist.


So what's the plan with sources and javadoc JARs?

Regards,
Holger


On 2018-05-30 at 01:36 +0200 Vincent Privat wrote:
Ah sorry I totally misunderstood your change. Please restore what I did, 
I thought you would only modify the "publish" target to ignore the files 
when committing to SVN, not delete the targets!


2018-05-29 22:03 GMT+02:00 Holger Mappt <mailto:holger...@gmx.net>>:


Hi,

I implemented the two changes in r34224 and r34225. This undid most
of the changes to build-common.xml from r34045 where
plugin-sources.jar and plugin-javadoc.jar were added.

Marián, it should work for you now.

Regards,
Holger


On 2018-05-27 at 12:18 +0200 Vincent Privat wrote:

No objections:)

    Le sam. 26 mai 2018 à 22:54, Holger Mappt
mailto:holgerosm-hi6y0cq0...@public.gmane.org>> a écrit :

Hi Marián,

There are two problems and I can confirm your issue.

Problem one is "ant update-current" which expands
../dist/${plugin.jar}
to
../dist/home/marian/projekty/josm/josm_plugins/dist/pointInfo.jar
instead of ../dist/pointInfo.jar. The ../dist/ must be
removed in the
target, the path to dist is part of ${plugin.jar} already.

Problem two is that "ant commit-dist" tries to commit
pointInfo-javadoc.jar and pointInfo-sources.jar. I think
they should not
be committed. They are in the ignore list (svn pl -v
../../dist) and I
don't see that other plugins have them in dist. SVN fails to
commit the
two files because they are not "svn add"ed.

I assume you are the only one who uses the publish target.
Otherwise all
others would see the same problem.

Who else uses "ant publish"? If there are no objections I
will make
these two changes to build-common.xml:
* Remove ../dist/ from update-current
* Do not update/publish/commit plugin.sources.jar and
plugin.javadoc.jar

Regards,
Holger






Re: Publish plugin issue

2018-05-29 Thread Holger Mappt

Hi,

I implemented the two changes in r34224 and r34225. This undid most of 
the changes to build-common.xml from r34045 where plugin-sources.jar and 
plugin-javadoc.jar were added.


Marián, it should work for you now.

Regards,
Holger


On 2018-05-27 at 12:18 +0200 Vincent Privat wrote:

No objections:)

Le sam. 26 mai 2018 à 22:54, Holger Mappt 
 a écrit :


Hi Marián,

There are two problems and I can confirm your issue.

Problem one is "ant update-current" which expands ../dist/${plugin.jar}
to ../dist/home/marian/projekty/josm/josm_plugins/dist/pointInfo.jar
instead of ../dist/pointInfo.jar. The ../dist/ must be removed in the
target, the path to dist is part of ${plugin.jar} already.

Problem two is that "ant commit-dist" tries to commit
pointInfo-javadoc.jar and pointInfo-sources.jar. I think they should not
be committed. They are in the ignore list (svn pl -v ../../dist) and I
don't see that other plugins have them in dist. SVN fails to commit the
two files because they are not "svn add"ed.

I assume you are the only one who uses the publish target. Otherwise all
others would see the same problem.

Who else uses "ant publish"? If there are no objections I will make
these two changes to build-common.xml:
* Remove ../dist/ from update-current
* Do not update/publish/commit plugin.sources.jar and plugin.javadoc.jar

Regards,
Holger





Re: Error while updating svn repository

2018-05-29 Thread Holger Mappt

Hi Biswesh,

Was that all you got, no other messages which external has the problem? 
What does a "svn status" show? Without more context it is not possible 
to know what the problem is. Externals are links to other repositories 
or paths in the same repository. The plugins tree has many externals 
defined (X in status). Any of them could cause the error message.


Regards,
Holger


On 2018-05-19 at 01:15 +0200 Imt2016050 Biswesh Mohapatra wrote:

Hello,

I am working on PT_Assistant plugin for GSOC 2018. I got an error while I did 
svn up -

At revision 34194.
svn: E205011: Failure occurred processing one or more externals definitions

   1.

When I searched on the net, the only solution they gave was to delete the 
previously checked out branch and checkout again. Is there a better solution 
for the problem?

My last commit was 34184 while the latest revision is 34194.

Kindly advise me on the steps that are required to resolve the issue.

Regards
Biswesh






Re: Publish plugin issue

2018-05-26 Thread Holger Mappt

Hi Marián,

There are two problems and I can confirm your issue.

Problem one is "ant update-current" which expands ../dist/${plugin.jar} 
to ../dist/home/marian/projekty/josm/josm_plugins/dist/pointInfo.jar 
instead of ../dist/pointInfo.jar. The ../dist/ must be removed in the 
target, the path to dist is part of ${plugin.jar} already.


Problem two is that "ant commit-dist" tries to commit 
pointInfo-javadoc.jar and pointInfo-sources.jar. I think they should not 
be committed. They are in the ignore list (svn pl -v ../../dist) and I 
don't see that other plugins have them in dist. SVN fails to commit the 
two files because they are not "svn add"ed.


I assume you are the only one who uses the publish target. Otherwise all 
others would see the same problem.


Who else uses "ant publish"? If there are no objections I will make 
these two changes to build-common.xml:

* Remove ../dist/ from update-current
* Do not update/publish/commit plugin.sources.jar and plugin.javadoc.jar

Regards,
Holger


On 2018-05-23 at 22:31 +0200 Marián Kyral wrote:

Hi,
sorry for the late reply.

Dne 17.5.2018 v 22:03 Holger Mappt napsal(a):

Hi Marián,

Looks like you managed to publish the PointInfo plugin in the meantime
(r34195).

Yes, I did it manually by committing the binary with proper commit message.


An SVN status with ! is never good. I assume there was a newer version
in the repo that was not fetched because you had a modified
dist/pointInfo.jar. Run svn status with option -u (to see what updates
are in the repository), delete your modified pointInfo.jar, svn update
dist, publish.

And this is strange. I deleted the binary and restored them from repo.
Then I run "ant publish", it deleted binary in "dist" folder, compile
it, created the "*-source.jar" and "*-javadoc.jar" files and svn commit
fails on messages I've sent.


*Just tested now ant the result is the same. Folders are clean*

[22:06:24 marian@worker pointInfo (master)]$ svn status -u
Status against revision:  34216
[22:10:39 marian@worker pointInfo (master)]$ svn status -u ../../dist
Status against revision:  34216

*But:*

[22:10:55 marian@worker pointInfo (master)]$ ant publish
Picked up _JAVA_OPTIONS: -Dawt.useSystemAAFontSettings=on
-Dswing.aatext=true
Buildfile:
/home/marian/projekty/josm/josm_plugins/plugins/pointInfo/build.xml

ensure-svn-present:

core-info:
  [echo] Building against core revision 13823.
  [echo] Plugin-Mainversion is set to 12666.
    [delete] Deleting:
/home/marian/projekty/josm/josm_plugins/plugins/pointInfo/core.info.xml

commit-current:
  [echo] Commiting the plugin source with message 'PointInfo: Adds a
link to photo metadata in Catastro module. Patch by Javier Sánchez
Portero.' ...

update-current:
  [echo] Updating plugin source ...
  [echo] Updating
/home/marian/projekty/josm/josm_plugins/dist/pointInfo.jar ...
  [exec] Result: 1

[...]

commit-dist:
  [echo]
  [echo] * Properties of published
/home/marian/projekty/josm/josm_plugins/dist/pointInfo.jar *
  [echo] Commit message    : 'PointInfo: Adds a link to photo
metadata in Catastro module. Patch by Javier Sánchez Portero.'
  [echo] Plugin-Mainversion: 12666
  [echo] JOSM build version: 13823
  [echo] Plugin-Version    : 34216
  [echo] * / Properties of published
/home/marian/projekty/josm/josm_plugins/dist/pointInfo.jar *
  [echo]
  [echo] Now commiting
/home/marian/projekty/josm/josm_plugins/dist/pointInfo.jar ...
  [echo]
  [exec] Result: 1

publish:

BUILD SUCCESSFUL
Total time: 11 seconds


*The svn.log*

[22:15:06 marian@worker pointInfo (master)]$ cat svn.log
[...]

Updating '.':
At revision 34216.
Skipped
'../dist/home/marian/projekty/josm/josm_plugins/dist/pointInfo.jar'svn:
E155007: None of the targets are working copies

Skipped
'../dist/home/marian/projekty/josm/josm_plugins/dist/pointInfo-javadoc.jar'
Skipped
'../dist/home/marian/projekty/josm/josm_plugins/dist/pointInfo-sources.jar'
svn: E29: Commit failed (details follow):
svn: E29:
'/home/marian/projekty/josm/josm_plugins/dist/pointInfo-sources.jar' is
not under version control

*And current status:*

[22:15:10 marian@worker pointInfo (master)]$ svn status -u
?    svn.log
Status against revision:  34216
[22:23:10 marian@worker pointInfo (master)]$ svn status -u ../../dist
M    34216   ../../dist/pointInfo.jar
Status against revision:  34216
[22:23:15 marian@worker pointInfo (master)]$

Maybe, could you try?

Thanks,
Marián



Regards,
Holger


On 2018-05-17 at 12:42 +0200 Marián Kyral wrote:

Hi,
It is a long time ago when I published last version of pointInfo plugin.
Now I want to publish updated version, but it does not work :-(


I've commited changes in code:


Re: Publish plugin issue

2018-05-17 Thread Holger Mappt

Hi Marián,

Looks like you managed to publish the PointInfo plugin in the meantime 
(r34195). An SVN status with ! is never good. I assume there was a newer 
version in the repo that was not fetched because you had a modified 
dist/pointInfo.jar. Run svn status with option -u (to see what updates 
are in the repository), delete your modified pointInfo.jar, svn update 
dist, publish.


Regards,
Holger


On 2018-05-17 at 12:42 +0200 Marián Kyral wrote:

Hi,
It is a long time ago when I published last version of pointInfo plugin.
Now I want to publish updated version, but it does not work :-(


I've commited changes in code:


r34168 | mkyral | 2018-04-24 07:48:05 +0200 (Út, 24 dub 2018) | 5 lines

PointInfo: Add Spanish Cadastre Web Services module.

Patch by Javier Sánchez Portero.


Then I want to publish updated binary:


$ cd /home/marian/projekty/josm/josm_plugins/dist/
$ svn status
! pointInfo.jar
$ svn update
Updating '.':
Restored 'pointInfo.jar'
At revision 34194.







Re: Plugins: deprecated API to be removed

2017-10-30 Thread Holger Mappt

On 2017-10-23 at 00:15 +0200 Paul Hartmann wrote:

On 21.10.2017 17:49, Holger Mappt wrote:
Is the sonar the right place to see what is deprecated, i.e. what 
needs to be changed? [1]
[1] 
https://josm.openstreetmap.de/sonar/project/issues?id=josm-plugins&resolved=false&rules=squid%3ACallToDeprecatedMethod 


Possible, but the normal way would be to have the java compiler output 
deprecation warnings (use compiler option -Xlint:deprecation for javac 
to see details).


The trick is to call "ant clean" before "ant", otherwise the deprecation 
messages are not shown. Option -Xlint:deprecation is on by default if 
../build-common.xml is imported from build.xml.


Thanks,
Holger








Re: Plugins: deprecated API to be removed

2017-10-21 Thread Holger Mappt

Hi,

Is there a plugin that is updated already? I need some examples to see 
what I should do with the deprecated items. E.g. I have

Main.map.mapView.addMouseListener(mouseAdapter);
in my plugin. Main.map is a deprecated field and should be changed to 
MainApplication.getMap(). But the access to 
MainApplication.getMap().mapView is discouraged. The documentation [1] 
says I should use LayerManager [2] instead. But how do I register a 
mouse listener with the LayerManager? Or should I use the MainPanel [3] 
for the mouse listener? If so it would be good to have a direct mapping 
from Main.map.mapView.addMouseListener() to the corresponding call on 
the deprecation page [4]. BTW, do I access MainPanel directly 
(MainPanel.addMouseListener()) or what would be the right way to get a 
reference to the MainPanel?


Thanks,
Holger

[1] 
https://josm.openstreetmap.de/doc/org/openstreetmap/josm/gui/MapFrame.html#mapView
[2] 
https://josm.openstreetmap.de/doc/org/openstreetmap/josm/gui/layer/LayerManager.html
[3] 
https://josm.openstreetmap.de/doc/org/openstreetmap/josm/gui/MainPanel.html

[4] https://josm.openstreetmap.de/doc/deprecated-list.html


On 2017-10-19 at 15:22 +0200 Paul Hartmann wrote:
Please update any plugins that you are maintaining! The majority of 
fixes should be not more than replacing one method by another, as 
indicated in the deprecation JavaDoc comment.




Re: Plugins: deprecated API to be removed

2017-10-21 Thread Holger Mappt

Hi,

Is the sonar the right place to see what is deprecated, i.e. what needs 
to be changed? [1]


Can someone who was/is involved in the API update please update the 
plugin developers guide to reflect the changes (e.g. "The JOSM API")? [2]


Thanks,
Holger

[1] 
https://josm.openstreetmap.de/sonar/project/issues?id=josm-plugins&resolved=false&rules=squid%3ACallToDeprecatedMethod

[2] https://josm.openstreetmap.de/wiki/DevelopersGuide/DevelopingPlugins


On 2017-10-19 at 15:22 +0200 Paul Hartmann wrote:

Dear plugin developers,

Recently we have started an effort to make the JOSM source code more 
modular. [1] This requires a lot of refactoring and many of the original 
methods and classes have been deprecated. The work is not finished by 
any means, but we would like to make a cut and remove currently 
deprecated API at the end of 2017. [2]


Please update any plugins that you are maintaining! The majority of 
fixes should be not more than replacing one method by another, as 
indicated in the deprecation JavaDoc comment.


Some notable API changes:
* So far, plugins place all their files in one directory, namely 
Plugin.getPluginDir(). Now there are separate directories for plugin 
user data, preferences, and cache. (The old directory is the same as the 
new plugin user data directory.) Among other things, this allows backup 
processes to ignore possibly large amounts of non-essential data 
(cache). [3]
* The preference interface has been reworked: The field Main.pref is not 
technically deprecated yet, but should be replaced by Config.getPref(). 
The new interface is more restrictive, but sufficient for getting and 
setting preference values.


As most plugin developers are aware, the plugin "Mainversion" needs to 
be updated whenever older versions of JOSM will become incompatible with 
the updated plugin binary (as is usually the case for deprecation 
fixes). [4]


[1] https://josm.openstreetmap.de/ticket/15182 (Standalone JOSM validator),
https://josm.openstreetmap.de/ticket/15229 (modular structure for JOSM 
core)
[2] https://josm.openstreetmap.de/ticket/15310 (The Great Deprecation 
Cleanup)
[3] https://josm.openstreetmap.de/ticket/15436 (Store cache data of 
plugins in cache location)
[4] 
 





Re: Compile problem: package com.sun.javafx.application does not exist

2017-07-19 Thread Holger Mappt

On 2017-07-18 at 10:29 +0200 Dirk Stöcker wrote:

On Mon, 17 Jul 2017, Holger Mappt wrote:

Thank you for the package name. For openSUSE it is java-openjfx. I was 
searching for javafx before, but that results in netbeans-javafx, 
which is not the right thing. I'm able to compile now.


Which RPM did you install?

Ciao


Hi Dirk,

I installed this: 
http://download.opensuse.org/repositories/home:/Herbster0815/openSUSE_Leap_42.2/x86_64/java-openjfx-8u131~b11-7.1.x86_64.rpm 
(https://software.opensuse.org/package/java-openjfx?search_term=openjfx)


Holger




Re: Compile problem: package com.sun.javafx.application does not exist

2017-07-17 Thread Holger Mappt

Hi Eric,

Thank you for the package name. For openSUSE it is java-openjfx. I was 
searching for javafx before, but that results in netbeans-javafx, which 
is not the right thing. I'm able to compile now.


Thanks,
Holger


On 2017-07-17 at 04:00 +0200 Eric Ladner wrote:
OpenJDK likely doesn't include JavaFX.  It would have to be installed 
separately.   e.g. "sudo apt install openjfx" on Debian based systems.


On Sun, Jul 16, 2017 at 11:02 AM Holger Mappt wrote:

Hi,

I guess something is missing in my Java installation, who can point me
into the right direction? javac is 1.8.0_131 (OpenJDK), Apache Ant(TM)
version 1.9.4.

Thanks,
Holger

  > cd /home/josm/core && ant
Buildfile: /home/josm/core/build.xml

  [javac]

/home/josm/core/src/org/openstreetmap/josm/io/audio/JavaFxMediaPlayer.java:15:
error: package com.sun.javafx.application does not exist
  [javac] import com.sun.javafx.application.PlatformImpl;




Compile problem: package com.sun.javafx.application does not exist

2017-07-16 Thread Holger Mappt

Hi,

I guess something is missing in my Java installation, who can point me 
into the right direction? javac is 1.8.0_131 (OpenJDK), Apache Ant(TM) 
version 1.9.4.


Thanks,
Holger

> cd /home/josm/core && ant
Buildfile: /home/josm/core/build.xml

init-properties:

init:
[mkdir] Created dir: /home/josm/core/build
[mkdir] Created dir: /home/josm/core/dist

javacc:
[mkdir] Created dir: 
/home/josm/core/src/org/openstreetmap/josm/gui/mappaint/mapcss/parsergen

 [java] Java Compiler Compiler Version 7.0.2 (Parser Generator)
 [java] (type "javacc" with no arguments for help)
 [java] Reading from file 
/home/josm/core/src/org/openstreetmap/josm/gui/mappaint/mapcss/MapCSSParser.jj 
. . .
 [java] Warning: Line 4, Column 3: Command line setting of 
"OUTPUT_DIRECTORY" modifies option value in file.
 [java] Warning: Line 169, Column 5: Non-ASCII characters used in 
regular expression.
 [java] Please make sure you use the correct Reader when you create 
the parser, one that can handle your character set.

 [java] File "TokenMgrError.java" does not exist.  Will create one.
 [java] File "ParseException.java" does not exist.  Will create one.
 [java] File "Token.java" does not exist.  Will create one.
 [java] File "SimpleCharStream.java" does not exist.  Will create one.
 [java] Parser generated with 0 errors and 2 warnings.

compile:
[javac] Compiling 377 source files to /home/josm/core/build
[javac] Note: 
/home/josm/core/src/oauth/signpost/AbstractOAuthProvider.java uses or 
overrides a deprecated API.

[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] Compiling 54 source files to /home/josm/core/build
[javac] Compiling 1509 source files to /home/josm/core/build
[javac] 
/home/josm/core/src/org/openstreetmap/josm/io/audio/JavaFxMediaPlayer.java:15: 
error: package com.sun.javafx.application does not exist

[javac] import com.sun.javafx.application.PlatformImpl;
[javac]  ^
[javac] 
/home/josm/core/src/org/openstreetmap/josm/io/audio/JavaFxMediaPlayer.java:17: 
error: package javafx.scene.media does not exist

[javac] import javafx.scene.media.Media;
[javac]  ^
[javac] 
/home/josm/core/src/org/openstreetmap/josm/io/audio/JavaFxMediaPlayer.java:18: 
error: package javafx.scene.media does not exist

[javac] import javafx.scene.media.MediaException;
[javac]  ^
[javac] 
/home/josm/core/src/org/openstreetmap/josm/io/audio/JavaFxMediaPlayer.java:19: 
error: package javafx.scene.media does not exist

[javac] import javafx.scene.media.MediaPlayer;
[javac]  ^
[javac] 
/home/josm/core/src/org/openstreetmap/josm/io/audio/JavaFxMediaPlayer.java:20: 
error: package javafx.scene.media.MediaPlayer does not exist

[javac] import javafx.scene.media.MediaPlayer.Status;
[javac]  ^
[javac] 
/home/josm/core/src/org/openstreetmap/josm/io/audio/JavaFxMediaPlayer.java:21: 
error: package javafx.util does not exist

[javac] import javafx.util.Duration;
[javac]   ^
[javac] 
/home/josm/core/src/org/openstreetmap/josm/io/audio/JavaFxMediaPlayer.java:37: 
error: cannot find symbol

[javac] private MediaPlayer mediaPlayer;
[javac] ^
[javac]   symbol:   class MediaPlayer
[javac]   location: class JavaFxMediaPlayer
[javac] 7 errors

BUILD FAILED
/home/josm/core/build.xml:303: Compile failed; see the compiler error 
output for details.




Re: Offline OSM vector file plugin to edit in the field - OBF vector format or other

2017-02-26 Thread Holger Mappt

Hi Pierre,

I can only repeat what the others wrote already, but with different words :)

Even in the "northern countries" internet access can be a problem if you
are in a rural area and have to use your mobile phone to connect to the
internet. JOSM does everything it can to support that.

JOSM caches background tiles (i.e. imagery), but only for the zoom
levels you used before. I have a workflow with Mapserver
(http://mapserver.org/) to calculate tiles from other zoom levels, but
that is complicated and nothing for a plugin.

The OSM data itself is vector data and you need to download some data to 
be able to edit it anyway, so you have everything you need to work 
offline. JOSM has different styles to render that data (Edit - 
Preferences - Map Settings - Map Paint Styles). Is it a certain 
rendering style you are looking for? Or do you want to see an area that 
is too large to download the data upfront?


To implement a rendering engine like your smartphone app in JOSM is not 
feasible. But you can connect to one with WMS or TMS if you find one 
that runs on your local machine. Can someone recommend a local service 
that does that?


Regards,
Holger


On 2017-02-26 at 04:08 +0100 Pierre Béland wrote:

Hi Dirk
What I suggest is that JOSM adapt to different operational
context out of our northern countries with high speed internet. To
navigate with OSM in JOSM should be as easier as smarthpone offline
applications for people that need to work offline because of bad /
expensive access to internet networks.  My experience with
smarthpones applications is that they are reliable, they provide
fluidity. JOSM Caching is surely not as easy and reliable as these
offline maps.  And badly, moving in an area with no internet
connection, you realize that your setups are not ok and you have no
background imagery.

I agree that Obf is not a standard. The best would be that one
standard emerge for offline vector files. In the meantime, what can
we do to adapt to all the countries / areas without high internet
inexpensive bandwith?

regard Pierre


De : Dirk Stöcker Envoyé le : samedi 25 février 2017 16h05 Objet :
Re: Offline OSM vector file plugin to edit in the field - OBF vector
format or other

On Sat, 25 Feb 2017, Pierre Béland wrote:


Smarthphones did provide us access to all of Haiti on OSMAnnd or
Maps.Me. Our team was able to store tracks and waypoints on our
phones. We did also use Mapillary and ODK tools. But at the end of
the day, we could not edit the data in JOSM, bringing in these
various infos to compare with the OSM map as a background. This,
even if I tried previously to cache OSM tiles for the area, I did
not have access to these tiles while in the field with no internet
access. A cache could be a solution. A better solution is to Add an
Offline OSM Vector map plugin to JOSM. This would be a great
enhancement for OSM contributors that experience difficulty to
access data online.


I don't understand what you request at all.

- JOSM has tile caches which usually are small, but you can increase
size - JOSM is an vector map editor - its main task is to display
vector data - JOSM can load stored offline data files in XML and also
PBF format

Everything already there.






Re: JOSM Translations

2017-02-19 Thread Holger Mappt

On 2017-02-19 at 14:19 +0100 Dirk Stöcker wrote:

I had a look at our translation statistics recently and I find it awful,
that there is no real progress to see, compared to the situation a few
years ago.

Does anybody have ideas how more translators could be attracted for the
languages which have many missing texts?

We do daily text uploads and although launchpad has issues from time to
time it usually is stable. The tools exist.

I think the main problem is that people aren't aware they could help and
are needed to do so.


Hi,

It would be interesting to know how important translations are. Maybe it 
is okay for most of the users to use the English version.


I think one of the issues is the enormous number of strings. We reached 
1 a few weeks ago. And there is a pretty high update frequency. You 
need days to catch up if no translation was done for a few months.


Another issue is the quality of the strings. Some source strings are not 
English (but French, Dutch, Polish, etc), have unknown acronyms in it, 
or it's just not clear what the string is about. That mainly affects 
plugins and the imagery. I sometimes open a ticket if the quality is 
bad. JOSM core tickets are resolved promptly, but plugin authors are 
lazy or don't respond at all. There is no good way to address issues 
with the imagery strings (there is actually no way).


Launchpad has issues all the time. It was okay for a while, but now the 
timeout error is back again, I get it every time I translate something. 
What's really missing is the possibility to comment a string to add 
hints for other translators.


One solution could be to separate the JOSM core strings from the plugin 
and imagery strings. Then translators can concentrate on the JOSM core, 
it would reduce the timeout errors, and it becomes doable to actually 
translate all (core) strings.


Plugins are a different topic. I think there is no way to attract people 
to translate a large number of strings that nobody will ever read. An 
idea would be to rank the untranslated strings by the number of plugin 
installations (do we know this?) to start with the important strings. 
But Launchpad sorts them alphabetically, not by importance.


For the imagery strings I opened ticket #12179, but it looks like no one 
is interested to improve the current situation.


Holger





Clustering of overlapping features

2017-01-01 Thread Holger Mappt

Hi,

This question originates from ticket #11189 ([1]): Is there a way or are 
there plans to support some kind of clustering of data in dense regions 
with overlapping features like photos on the map in JOSM? The idea is to 
display the number of overlapping features instead of the actual 
features or an other sign on low zoom levels to indicate that there is 
more data as what can be seen in the map view. This could be useful for 
different layers, not just the GEO image layer. The solution would need 
to support the case that multiple features have the same coordinates. A 
"feature" could be a photo (also from Mapillary, OpenStreetCam, ...), 
POI, node, note, GPX track-point or way-point, way/polygon, etc.


Thanks,
Holger

[1] https://josm.openstreetmap.de/ticket/11189

___
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev


Re: How-To Progress Monitor

2016-10-22 Thread Holger Mappt

Hi Wiktor,

PleaseWaitRunnable does the trick, thank your for pointing me to it. 
Method "cancel" handles the cancel event, I do not need to watch 
progressMonitor.isCancelled().


At the end of my task that is now in realRun() I have a 
Notification(tr("Message")).show() that triggered some EDT violations, 
but I found the GuiHelper.runInEDT() that fixes that.


Thanks,
Holger


Am 22.10.2016 um 18:40 schrieb Wiktor Niesiobedzki:

Hi,

I guess that you may find
org.openstreetmap.josm.gui.layer.gpx.DownloadWmsAlongTrackAction
helpful. This is the class that downloads WMS along GPX track. Let me
give you a short guide around the code:

PrecacheWmsTask is the class that is executed in background. The task
is submitted to background thread for execution as:
Main.worker.execute(task);

It means that task is executed in one shared background thread across JOSM.

PrecacheWmsTask.realRun method implements, what needs to be done in background.

To implement user friendly Progress Monitor you can do as follow:
use: progressMonitor.setTicksCount(int) to set how many units of work
(ex. images) you have at the begging of realRun()
and then, when unit of work is done, use progressMonitor.worked(1) to
notify, that one unit is already done (ex. one image is processed)

You should also watch progressMonitor.isCancelled() to shut down your
background work if user cancels it.

I guess this has helped you.

Cheers,

Wiktor


2016-10-22 17:07 GMT+02:00 Holger Mappt :

Hi,

I'm writing a plugin that processes a number of images after a menu item was
selected.  What is the right way to do that in a way that doesn't block the
GUI with an indication of the progress?  I guess I have to run some kind of
task that updates the progress after every image.  Then some GUI component
displays a progress bar (with an optional cancel button).  I implemented
something that is based on javax.swing.ProgressMonitor and
javax.swing.SwingWorker according to the code sample from the Java tutorial
(https://docs.oracle.com/javase/tutorial/uiswing/examples/components/ProgressMonitorDemoProject/src/components/ProgressMonitorDemo.java),
but it's not working.  The progress window opens after the 101st image and
then blocks the execution of the task.

What is the recommended JOSM way to do that?  Is there a good example where
I can learn from?  JOSM has a ProgressMonitor interface and some classes
that implement it, but there is no documentation and the plugins I looked at
are quite complex with an endless chain of subroutines.  Any help is
appreciated.

Thanks,
Holger

___
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev




___
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev


How-To Progress Monitor

2016-10-22 Thread Holger Mappt

Hi,

I'm writing a plugin that processes a number of images after a menu item 
was selected.  What is the right way to do that in a way that doesn't 
block the GUI with an indication of the progress?  I guess I have to run 
some kind of task that updates the progress after every image.  Then 
some GUI component displays a progress bar (with an optional cancel 
button).  I implemented something that is based on 
javax.swing.ProgressMonitor and javax.swing.SwingWorker according to the 
code sample from the Java tutorial 
(https://docs.oracle.com/javase/tutorial/uiswing/examples/components/ProgressMonitorDemoProject/src/components/ProgressMonitorDemo.java), 
but it's not working.  The progress window opens after the 101st image 
and then blocks the execution of the task.


What is the recommended JOSM way to do that?  Is there a good example 
where I can learn from?  JOSM has a ProgressMonitor interface and some 
classes that implement it, but there is no documentation and the plugins 
I looked at are quite complex with an endless chain of subroutines.  Any 
help is appreciated.


Thanks,
Holger

___
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] How to ask for confirmation at layer deletion or exit?

2016-01-02 Thread Holger Mappt
If we never ask for confirmations then you would be able to quit JOSM 
while it has modified data. There can be no notice about saved changes 
at that point. The earliest time to display that notice would be the 
next JOSM start. But the data might have changed on the server in the 
meantime. In the worst case all your edits are worthless because you get 
too many conflicts. To undo the changesets that cause the conflicts is 
not an option.


I agree with you on the conceptional level, but I don't see how it can 
be implemented in a sensible way.



On 2016-01-01 at 21:37 +0100 Russ Nelson wrote:

Never ask for confirmations. It's never the right thing to do unless
you're very short of resources, which we never are these days.

Instead, provide an undo of a layer delete. When they ask to delete a
layer that has changes in it, simply delete it, and pop up a
non-confirmation notice that says "This layer has changes and may be
restored using File/Open Recent".

The problem with a confirmation is that it *really* deletes the data,
which may be the wrong thing. If you're ever at a confirmation point,
clearly somebody might not be thinking correctly, and their answer to
the confirmation might *also* be wrong.

Undo, undo, undo! Never confirm!


___
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] Layer specific history

2016-01-01 Thread Holger Mappt
I'm in favor of a way that allows to undo layer specific actions.  But 
to have a separate history stack per layer doesn't work well.  Example: 
An OSM data layer, a GPX layer, and a geotagged image

layer are open.  The data layer is active and the images are correlated
to the GPX track.  That action goes into the geo image layer history 
because
that's where the images are.  But an "undo" would not undo the image-GPX 
correlation but the last data layer action because the data layer is 
active.  This might be confusing.


How about a combination of 1) and 2): The history is a linear list of 
actions.  Each action is associated with a layer.  All actions that 
belong to a layer form a virtual history stack.  Each action in the 
history list is either active or undone.  If an action is undone the 
according undone flag is set.  The default is to show/use the linear 
history like it is done now.  With a toggle button it can be switched to 
the (virtual) history of the current layer.  Only the actions of the 
active layer are considered now (history stack display and undo/redo). 
The border between active and undone actions is based on the undone 
flag.  Back to the full linear history: Undone actions that are in the 
active section and active actions in the undone section are grayed out 
to indicate that undo/redo will do nothing with such an action.  Grayed 
out actions are not skipped during undo/redo to keep the history linear. 
 If a grayed out undone action is undone with the linear history the 
color changes back to normal if there is no earlier undone action of the 
same layer because it can be redone now.  Same for the redo direction. 
Actions can be color coded to visualize the layer they belong to.  Each 
layer gets a unique color assigned.  Actions from different layers could 
be displayed like commits in branches are displayed in revision control 
system GUIs.  That will help to understand why grayed out actions cannot 
be undone/redone.


Many ifs and whens, but I think it could work.

Holger


On 2015-12-30 at 19:05 +0100 Vincent Privat wrote:

I think 2) is the best solution. It remains simple for most users who
work on a single modifiable layer at a time, but provides a nice
flexibility for those who work on several layers.
3) is too complex. The less dialogs we have the best it is.


2015-12-29 17:16 GMT+01:00 Holger Mappt:
What is the recommended way to add a command history with undo/redo
functionality to a layer that is not an OSM data layer?  In this
case the GeoImageLayer.

I can imagine three options:
1) One linear history stack for all actions with one interface.
This is what is usually done in other software.  The interface is
the undo/redo in the edit menu and the main toolbar and the command
stack toggle dialog.

2) One history stack per layer with one interface.  Similar to 1),
but undo/redo applies only to the active layer.  This decouples the
actions done in different layers.  It requires that actions done in
one layer do not depend on actions in another layer.  "Layer" can
either be a single layer or one layer type.

To be useful the history needs a concept of "connected actions" and
the possibility to undo unconnected actions independently.  Example:
The key "opening_hours" is added to a POI node, then the key "name"
of an other PI node is changed.  To undo the opening_hours the name
change has to undone too with the current implementation.  But the
two POI nodes are not connected, it should be possible to undo
either change.


___
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] How to ask for confirmation at layer deletion or exit?

2015-12-31 Thread Holger Mappt

Hi Vincent,

The idea behind requiresSomeAction() was to display a message like "use 
the layer context menu to store modified data" to tell the user that 
there is more than "save session", "delete/exit now", and "cancel". 
Kind of an "other ways to handle modified data" information in the 
SaveLayersDialog.  Just as information, not as real Java action.  But it 
might be too much information at that place.


Should I prepare a patch or just create a ticket?

Holger

On 2015-12-30 at 19:08 +0100 Vincent Privat wrote:

isAbleToUploadToServer() and isAbleToSaveToFile() sound fine.

Concerning the "action" string I don't know: what would you propose as
action in your case?

2015-12-28 16:44 GMT+01:00 Holger Mappt:

Would it make sense to add something like requiresSomeAction() to
AbstractModifiableLayer and Main.saveUnsavedModifications()?  The "action"
could be a string that is displayed in the SaveLayersDialog.



___
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev


[josm-dev] Layer specific history

2015-12-29 Thread Holger Mappt

Hi,

See https://josm.openstreetmap.de/ticket/11904.
What is the recommended way to add a command history with undo/redo 
functionality to a layer that is not an OSM data layer?  In this case 
the GeoImageLayer.


The other software I know has one history stack.  Every modification 
generates a history entry.  JOSM default is to have history only for OSM 
data layers.  The Mapillary plugin implements a history as toggle dialog 
with separate undo/redo buttons.


I can imagine three options:
1) One linear history stack for all actions with one interface.  This is 
what is usually done in other software.  The interface is the undo/redo 
in the edit menu and the main toolbar and the command stack toggle dialog.


2) One history stack per layer with one interface.  Similar to 1), but 
undo/redo applies only to the active layer.  This decouples the actions 
done in different layers.  It requires that actions done in one layer do 
not depend on actions in another layer.  "Layer" can either be a single 
layer or one layer type.


3) Each layer implements a custom history.  Similar to 2), but different 
interface for each layer.  Has the advantage that fancy things can be 
done.  E.g. for the GeoImageLayer the history could be per image.  But 
the user is confronted with many history dialogs and undo mechanisms.


To be useful the history needs a concept of "connected actions" and the 
possibility to undo unconnected actions independently.  Example: The key 
"opening_hours" is added to a POI node, then the key "name" of an other 
PI node is changed.  To undo the opening_hours the name change has to 
undone too with the current implementation.  But the two POI nodes are 
not connected, it should be possible to undo either change.


Regards,
Holger

___
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev


[josm-dev] How to ask for confirmation at layer deletion or exit?

2015-12-28 Thread Holger Mappt

Hi,

See https://josm.openstreetmap.de/ticket/12075.
The idea is to ask for confirmation if a GeoImageLayer with modified 
image properties is deleted.  What is the best/right way to do that?


The AbstractModifiableLayer seems to serve that purpose.  GeoImageLayer 
could extend AbstractModifiableLayer instead of Layer.  But there is not 
a single file associated with the layer but one file per modified image. 
 There is not really a "recommended action" for the SaveLayersDialog. 
The AbstractModifiableLayer would need to be extended to have something 
like isAbleToUploadToServer() and isAbleToSaveToFile() to disable the 
according check-boxes of the SaveLayersDialog.  The logic in 
Main.saveUnsavedModifications() would need to be changed to consider the 
layer if neither requiresSaveToFile() nor requiresUploadToServer() 
returns true.  Would it make sense to add something like 
requiresSomeAction() to AbstractModifiableLayer and 
Main.saveUnsavedModifications()?  The "action" could be a string that is 
displayed in the SaveLayersDialog.


Thanks,
Holger

___
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] Image extraction from TMS cache

2015-12-20 Thread Holger Mappt

Hi,

I re-package josm-latest.jar into my cachextractor.jar to have a self 
contained archive. I missed to copy data/preferences.xsd, which killed 
my JOSM preferences. Now I copy directory data in addition to **/*.java 
and the cache read works.


What do I need to do to shut down JOSM if it was started with the 
functions in JOSMFixture.init() (no GUI mode)? Looks like there is a 
background process. I call System.exit(0), but I would like to stop all 
running processes first.


The other thing that caused me some headache was the export disk file 
format. The old cache that wrote tile files to disk wrote *.png files. I 
tried different PNG writers, but my files were always about 8 times 
bigger. It took me some time to figure out that even JPEG files were 
written with the .png file name extension. Now I save the tiles as JPEG 
and everything is fine. Does the current cache have information about 
the original tile file (format, data)?


Regards,
Holger


Am 12.12.2015 um 20:09 schrieb Wiktor Niesiobedzki:

As for your problem - this is kind of the problem we face also writing
the unit tests. It is solved by calling:
org.openstreetmap.josm.JOSMFixture.createUnitTestFixture().init();

Though keep in mind, that this is part of the testing code, so it's
located here:
http://josm.openstreetmap.de/browser/josm/trunk/test/unit/org/openstreetmap/josm/JOSMFixture.java

This should give you a hint, how to initiate "headless" mode.

Cheers,
Wiktor

2015-12-12 18:52 GMT+01:00 Holger Mappt:

My idea was to write a small program that calls TMSLayer.getCache() to get
the TMS cache. But to do that I need to initialize JOSM (preferences, TMS
layer, and tile cache). How would I do that? Is there something like a
headless mode where I can hook into? I tried to call some of the
initialization methods, but there are too many dependencies and I would need
a running JOSM to make that work.


___
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] Image extraction from TMS cache

2015-12-12 Thread Holger Mappt
My idea was to write a small program that calls TMSLayer.getCache() to 
get the TMS cache. But to do that I need to initialize JOSM 
(preferences, TMS layer, and tile cache). How would I do that? Is there 
something like a headless mode where I can hook into? I tried to call 
some of the initialization methods, but there are too many dependencies 
and I would need a running JOSM to make that work.


Does it work to write a plugin that can be called from the command line, 
but without the GUI?


The other option is to re-implement the tile cache code without some of 
the dependencies. That seems to be a lot of work. It needs modifications 
every time the JOSM tile cache is modified.


BTW, was the tile cache code modified recently? My cache was reset 
(erased) yesterday.


Holger

Am 01.06.2015 um 22:20 schrieb Wiktor Niesiobedzki:

So what you could do, is to create small java program, that would
extract all the files from JOSM cache, based on josm.jar. And further
functionality just depends on what you want to do with cache content.

2015-06-01 20:45 GMT+02:00 Holger Mappt:

Is this something I can do on the command line or do I need to write a Java
program?  What would be a good starting point?


Am 28.05.2015 um 22:14 schrieb Wiktor Niesiobedzki:

This is +/- "propietary" standard of Apache Java Caching System
(https://commons.apache.org/proper/commons-jcs/). We are currently
using Indexed Disk Cache as store for tiles, so the easiest way
forward, is just to use JCS, to read the file, and then use keySet()
method, to get all the data that is stored in cache.


2015-05-28 20:30 GMT+02:00 Holger Mappt:

I assume the new TMS cache with the files TMS.data and TMS.key uses some
standard.  What tools can I use to extract the images from that cache? I
do
some post-processing for offline mapping with Mapserver.



___
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] Translation discussions

2015-11-02 Thread Holger Mappt
It's more the admin that wants to set up a new system :) My impression 
is that most translators are not JOSM developers. That might be one 
reason why there is nearly no feedback. You need a copy of the source 
code tree to find the SVN revision a string was committed in. In the 
commit message is the link to the ticked where the feedback should go to 
(at least in my opinion). That's just too complicated for a typical 
translator.


For me any system with more support for communication between 
translators and an option to set a "needs review" flag for the original 
English string will do. Launchpad (and probably other major platforms) 
have an active community that will translate just any string. This will 
not happen if we move to something private/exotic. Good point Simon.


It's a pity that Launchpad needs forever to fix obvious bugs or 
implement helpful features. An other feature that is missing in 
Launchpad is fuzzy search for suggestions. Any tiny change in the source 
string invalidates all translations. That's why I would like to have 
that "source needs review" flag. A string marked with that flag is 
subject to change, it should not be translated until the issue is resolved.


Regards,
Holger


On 2015-11-01 at 09:16 +0100 Simon Poole wrote:


If  the JOSM devs really want to move away from launchpad, surely the
choice should be between an existing service (transifex and others) or
running (and potentially improving if there are missing features) an
existing system (for example Pootle) and not wasting effort on yet
another ..

Simon

Am 31.10.2015 um 17:02 schrieb Vincent Privat:

This is something clearly missing. It is a 10-year old Launchpad bug:
https://bugs.launchpad.net/launchpad/+bug/25

2015-10-20 11:21 GMT+02:00 Dirk Stöcker :


On Sun, 18 Oct 2015, Holger Mappt wrote:

would be good, I think Transifex supports that. Dirk, do you still work on

a Trac based system? Will it support translation discussions? To be able to
discuss the source string would be good too.


A little. It's still my goal. I hope I have some time for this in the
holidays end of the year.

same issue? Should we change more source strings to improve the

translation process? Or is it good as it is?


Clearly a YES, as currently nearly no feedback goes into the source
strings :-)

Ciao




___
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev


[josm-dev] Translation discussions

2015-10-18 Thread Holger Mappt

Hi,

There are sometimes strings used in the JOSM source, the presets, or a 
plugin that are hard to translate. What is the preferred way to discuss 
the translation of such strings? If the origin in the code should be 
changed then the JOSM tickets can be used. But what about the 
translation itself? All you can do in Launchpad is contact the author of 
the current translation or set the "need review" flag. The flag can be 
set only if the string is changed, not for existing translations. If I 
contact the last author then this discussion is invisible for others. A 
discussion attached to each translation would be good, I think Transifex 
supports that. Dirk, do you still work on a Trac based system? Will it 
support translation discussions? To be able to discuss the source string 
would be good too.


Sometimes I think that there should be more context or that strings are 
too specific, e.g. acronyms like "OSMIE EDs" (OpenStreetMap Ireland 
Electoral Districts). Some translators just copy the English string in 
such a case. I try to find a translation that can be understood more 
easily. But every time it takes me more than one hour to find a good 
translation I think the original string should be improved. Or the 
translation gets too long if all relevant information is added. Is it 
just me or do other translators have the same issue? Should we change 
more source strings to improve the translation process? Or is it good as 
it is?


Holger

___
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] Difference in geotagged icons between camera and 'phone?

2015-09-15 Thread Holger Mappt

On 2015-09-14 at 10:18 +0200 Bob Hawkins wrote:

I had tried ‘Show thumbnails’ and, indeed, I see now that the image
next to it actually illustrates a camera and a landscape with two red
rotating arrows.  Nothing changes, however, when I select that
option.  One further point: I have seen two types of camera image; on
occasions, one is black and white only, another has a transparent red
layer on top.


Hi Bob,

If you correlate images with a GPX track there is a checkbox in the 
correlation form to show thumbnails on the map.  I guess this is how you 
got the thumbnails in earlier times.  Now there is that additional 
thumbnail toggle option in the image layer menu.  I checked that 
functionality and found an image where it does not work, see ticket 
11867 (https://josm.openstreetmap.de/ticket/11867).  Do you have a way 
to check if your images have the EXIF orientation field set, e.g. with 
exiftool (look for Orientation)?  Or add one of your images to the ticket.


If the camera icon has the transparent red layer on top then it is 
selected.  The same applies to the thumbnails.


Holger


___
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] Mapillary plugin for JOSM

2015-06-01 Thread Holger Mappt

Hi,

The plugin is in an early stage.  Is there a way to exclude it from the 
build jobs and distribution for a while?


Regards,
Holger


Am 31.05.2015 um 16:13 schrieb Vincent Privat:

Hi,
I see the mapillary plugin is now hosted on OSM SVN but it doesn't compile:
https://josm.openstreetmap.de/jenkins/job/JOSM-Plugins/23/

1) The plugin refers to a missing class "MapillaryImageDisplay". It must
have been forgotten?
2) Please use javax.json API, which is included in JOSM core, instead of
org.json. See https://josm.openstreetmap.de/ticket/9590 about why and how.

Cheers,
Vincent



___
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] Image extraction from TMS cache

2015-06-01 Thread Holger Mappt

Hi,

Is this something I can do on the command line or do I need to write a 
Java program?  What would be a good starting point?  I was assuming that 
there is some kind of cache explorer, but I couldn't find one.


Thanks,
Holger


Am 28.05.2015 um 22:14 schrieb Wiktor Niesiobedzki:

Hi,

This is +/- "propietary" standard of Apache Java Caching System
(https://commons.apache.org/proper/commons-jcs/). We are currently
using Indexed Disk Cache as store for tiles, so the easiest way
forward, is just to use JCS, to read the file, and then use keySet()
method, to get all the data that is stored in cache.

Cheers,

Wiktor

2015-05-28 20:30 GMT+02:00 Holger Mappt :

Hi,

I assume the new TMS cache with the files TMS.data and TMS.key uses some
standard.  What tools can I use to extract the images from that cache? I do
some post-processing for offline mapping with Mapserver.

Thanks,
Holger


___
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev


[josm-dev] Image extraction from TMS cache

2015-05-28 Thread Holger Mappt

Hi,

I assume the new TMS cache with the files TMS.data and TMS.key uses some 
standard.  What tools can I use to extract the images from that cache? 
I do some post-processing for offline mapping with Mapserver.


Thanks,
Holger

___
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev


[josm-dev] Filename path in dialog

2015-03-22 Thread Holger Mappt

Hi,

I'm working on a photo property dialog.  In that dialog I want to 
display the full file path.  What is the best way to do that?  A long 
path should be handled in a reasonable way.  E.g. with dots in the path, 
wrapped into multiple lines, or something similar.  It would be perfect 
if it is possible to select the path to copy it to the clipboard.


So far I use an ExtendedDialog.  For the path I tried JLabel, JTextArea, 
and HtmlPanel.  But the problem is that the path is always shown in one 
line if ExtendedDialog's placeContentInScrollPane is true.  The dialog 
window is very wide if the path is long.  If the dialog width is reduced 
the scroll bars appear, but it would be better if the element with the 
path is scaled.  That scaling works to some extend if the scroll bars 
are disabled, placeContentInScrollPane=false, but it still starts with 
the full width.  Any other ideas?  Is there a good example?


Thanks,
Holger

___
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] Mapillary

2015-02-01 Thread Holger Mappt

Hi Jo,

Do you still think about it or did you start already? I have some ideas 
for a Mapillary plugin. What would be a good place to share them? What 
is the intended functionality of the plugin? Everything that is 
available on the Mapillary website? Do you really want to write it in 
Python first?


I don't think there is a plugin that you can fork.

Holger


On 2015-01-27 at 14:00 +0100 Jo wrote:

I think I'd like to attempt it. The first question that comes to mind is:
build further on the photo mapping plug in or fork it?

Jo
On Jan 26, 2015 11:36 PM, "Jo" wrote:


Hi,

Is somebody already working on a Mapillary plugin for JOSM?

Polyglot



___
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] Problem to compile JOSM since jaxb target exists

2014-05-26 Thread Holger Mappt

Hi,

Ant is "Apache Ant(TM) version 1.9.2 compiled on October 2 2013", JDK is 
"OpenJDK Runtime Environment (IcedTea 2.4.4) (suse-24.13.5-x86_64)", 
java version "1.7.0_51".  OS is Linux 3.11.10, openSUSE 13.1.


The question was more whether this is a common problem.  If I'm the only 
one who gets this error then I'll just wait until the problem is gone, 
i.e. until the affected package was updated.


Regards,
Holger


On 26.05.2014 00:06, Vincent Privat wrote:

Can you please share more information about your environment? OS, Ant and
JDK version?


2014-05-25 22:02 GMT+02:00 Holger Mappt 
:


Hi,

I use the command line to build JOSM from the SVN sources.  Since rev.
7133 the build fails with this error:
[...]

Does someone have the same problem?  Looks like jaxb does something that
breaks ant, but I cannot figure out what is wrong.  What could cause the
build error?



___
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev


[josm-dev] Problem to compile JOSM since jaxb target exists

2014-05-25 Thread Holger Mappt

Hi,

I use the command line to build JOSM from the SVN sources.  Since rev. 
7133 the build fails with this error:


compile:
Caught an exception while logging the end of the build.  Exception was:
java.lang.NoClassDefFoundError: org/apache/tools/ant/util/DateUtils
at 
org.apache.tools.ant.DefaultLogger.formatTime(DefaultLogger.java:330)
at 
org.apache.tools.ant.DefaultLogger.buildFinished(DefaultLogger.java:177)

[...]
There has been an error prior to that:
/home/josm/core/build.xml:215: Problem: failed to create task or type javac
Cause: the class org.apache.tools.ant.taskdefs.Javac was not found.

The workaround is to remove the dependency "jaxb" from the "compile" 
target in build.xml and to run "ant jaxb" (fails after files were 
generated) before "ant".


Does someone have the same problem?  Looks like jaxb does something that 
breaks ant, but I cannot figure out what is wrong.  What could cause the 
build error?


Thanks,
Holger

___
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] Request for a SVN access to publish my plugin

2014-03-13 Thread Holger Mappt

Hi,

That is the piece of research you have to do yourself :)
You might check the talk mailing list and look for postings from Tom [1].

Holger

[1] https://lists.openstreetmap.org/pipermail/talk/2014-March/author.html

On 13.03.2014 20:26, Arnaud Vandecasteele wrote:

Hello,

Thank you for your answer.
A friend of mine (Vincent Privat) told me as well to contact TomH, but
in his OSM web page [1] it's specified:
Please do not message me via the web site if you want an SVN account -
email me with a preferred username instead and I will sort it out

Could someone tell me how to email him ? (I don't have his personal email)

Thanks a lot

Arnaud

[1] http://wiki.openstreetmap.org/wiki/User:TomH



___
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] Request for a SVN access to publish my plugin

2014-03-13 Thread Holger Mappt

On 13.03.2014 18:15, Arnaud Vandecasteele wrote:

Hello,

For my research I've developed a plugin for JOSM.
It's a recommender tags system that help contributors during the
annotation process.
Would it be possible to publish this plugin into the JOSM plugin
repository ?
Could you please let me know who I must contact or what I must do to get
an SVN access.

Thanks a lot

Arnaud



Hi Arnaud,

Yes, it is possible to publish your plugin, see "Publishing a plugin" in 
the JOSM plugin developers guide [1].  It would be an "internal" plugin. 
 See [2] to get an OSM SVN account.  You basically have to ask Tom Hughes.


Regards,
Holger

[1] 
http://josm.openstreetmap.de/wiki/DevelopersGuide/DevelopingPlugins#Publishingaplugin
[2] 
http://wiki.openstreetmap.org/wiki/Accounts#SVN_access_.28OSM_software.29


___
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] Wanted: Plugin Translation With Launchpad HowTo

2013-12-26 Thread Holger Mappt

On 25.12.2013 13:56, Dirk Stöcker wrote:


How should changing the commons file help you to add other languages?


I'm not sure if I understand your question.  The only thing that is left 
to do is to add the translations of the plugin description to the plugin 
MANIFEST.


plugins/build-common.xml is the file where MANIFEST is created.  To get 
the translations of the description into the MANIFEST that creation 
process needs to be extended.  Thus the MANIFEST build rule in 
build-common.xml needs to be extended.  I don't know yet how that could 
be done, I think it is a combination of a script and ANT commands.



I18N is already complete as it is now. What can be done is only a
cleaner interface by storing data at the right place, but it is a lot of
work and no user visible result. And probably some side-effects nobody
knows yet.


You mean the plugin description translations should not be added to the 
MANIFEST because there could be side-effects and it is not user visible? 
 OK, then I will add that just to my plugin.


Regards,
Holger


___
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] Wanted: Plugin Translation With Launchpad HowTo

2013-12-24 Thread Holger Mappt

On 24.12.2013 13:12, Dirk Stöcker wrote:


The build.xml generates the manifest. To add translations to the
manifest, the build.xml file must be changed to add or remove these
lines. That is not so easy, as the build.xml files still do not follow a
common style (although we try to unify them).


Actually, it's just plugins/build-common.xml that needs to be changed. 
I would not change plugins that don't use that file.  It's most 
beneficial for new plugins anyway.



* Translations for plugin description are extracted from PO files and
added to plugin MANIFEST.


No. This is not done. The server adds these texts to the downloadable
manifest extract, but the manifests itself don't contain these (yet).


Sorry, I mean the right way is to add the translations to the MANIFEST. 
 It's not the way it is done now, but I plan to implement it.



While placing them in the manifest would actually be the PROPER way I
never really found the energy to do so, as there is no real benefit.


It's hard to measure the benefit of internationalization.  But that 
doesn't mean it shouldn't be done.


Regards,
Holger



___
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] Wanted: Plugin Translation With Launchpad HowTo

2013-12-23 Thread Holger Mappt

On 22.12.2013 13:19, Dirk Stöcker wrote:

On Sat, 21 Dec 2013, Holger Mappt wrote:


I copy the development.jar in the JOSM plugin directory
(~/.josm/plugins) and JOSM extracts some data like the icon.  It
doesn't extract the translation (yet) if the plugin is not
installed


You need to supply the translation in MANIFEST to make translation
work in this case as well.

http://josm.openstreetmap.de/wiki/DevelopersGuide/DevelopingPlugins#ThemanifestfileforaJOSMplugin

Note, that actually the entry in the manifest is the only required
one. Text in translation area for core or plugin are a workaround.
OTOH the manifest entry is the only one, which gets not updated, as
that would mean automatic changes to the build.xml and nobody wrote
code to do so.


It's amazing how much details there are.  I will look into the MANIFEST
translation update.  What do you mean with "automatic changes to the
build.xml"?  The file build.xml is changed automatically or something 
should be added to build.xml that changes the MANIFEST?


I think the flow is like this:

* The description is added to the plugin josm.pot (taken from build.xml)
to add it to the translation chain.  This is not necessary for automatic
translations (they could work with two runs, one for the strings
extracted from the code and one for the translation of the description),
but it's easier to have all strings together, e.g. in case someone wants
to do a manual translation (this is how you start before the plugin is
released).

* Merge with the JOSM PO files, strings needed for plugin remain.

* Translations for plugin description are extracted from PO files and
added to plugin MANIFEST.

* PO to *.lang conversion.  The description could be removed before this
is done.  But that removal would add more complexity with little gain.

Regards,
Holger


___
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] Wanted: Plugin Translation With Launchpad HowTo

2013-12-21 Thread Holger Mappt

On 20.12.2013 23:14, Simon Legner wrote:

The plugin descriptions are part of the JOSM core language file since
the plugin descriptions are shown in the plugin list in the preference
dialog. I don't see why one would need them also in the plugin language
file.


The plugin descriptions are part of the official JOSM after the plugin 
is ready and released.  But I want to test everything including the 
translations *before* I release the plugin.  I copy the development.jar 
in the JOSM plugin directory (~/.josm/plugins) and JOSM extracts some 
data like the icon.  It doesn't extract the translation (yet) if the 
plugin is not installed, but I don't see why that functionality could 
not be added.  The translated description is shown after the 
private/development plugin is installed, I think that's enough reason to 
add that translation to the plugin.


I think it is not feasible for a plugin developer to run the JOSM core 
translation tool chain just to get that one translation into JOSM.


The plugin list from the JOSM server is the other place that needs the 
translation.  That makes me wonder why the JOSM core would need it.



Please be cautious when modifying i18n/build.xml since that is used
automatically update/upload the translation template every night!


I promise to be cautious.


What is the rational of having
https://translations.launchpad.net/josmphotoadjustplugin when those
strings are part of the normal JOSM translation process?


The normal JOSM translation process includes 8526 strings in 77 
languages.  That is a 20MB tarball.  For my plugin I need 8 strings, 
there are currently 6 languages.  That's 3.7kB, 5500 times less than the 
full JOSM tarball.  My download volume is limited, I try to avoid 
unnecessary downloads.  So I was looking for a way to get just the 
strings I'm interested in.  I did experiment with a separate Launchpad 
project because I was hoping that it is easy to copy my 8 strings from 
JOSM to my plugin.  Then I could work with just that 3.7kB tarball.  But 
it turned out that it is not that easy.  I dropped that idea.


The JOSM (core) translation tool chain might be clear to an active JOSM 
developer.  But it took me several days to figure out all the details 
and to experiment with different options.  That's why I started this 
thread and documented my findings.  But maybe it's just me who had such 
an issue.  It's also my first Java and Launchpad project.


Regards,
Holger

___
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] Wanted: Plugin Translation With Launchpad HowTo

2013-12-20 Thread Holger Mappt

On 20.12.2013 10:01, Dirk Stöcker wrote:

On Thu, 19 Dec 2013, Holger Mappt wrote:


3a) My first idea was to check out that branch.  ...  I stopped the "bzr branch
lp:~openstreetmap/josm/josm_trans" operation after 600MB were
downloaded.  There is no point in downloading and keeping gigabytes of
repository data for just a few translations.


Hmm. I get a 149MB directory when using the tools in i18n.


I was referring to "bzr branch lp:~openstreetmap/josm/josm_trans".  That 
command is shown on the Launchpad josm_trans code page. 
i18n/launchpad.pl does a "bzr export -v josm_trans 
lp:~openstreetmap/josm/josm_trans" which exports the data.  The export 
is equivalent to the revision tarball download that I mentioned as best 
way, 3b.



This is my translation flow for the PhotoAdjust plugin.

ant pot
./poimport.pl 749
./pomerge.pl
ant lang


All this is already done in the tasks of i18n.

I added a task "singleplugintrans", which does all this only for a
single plugin.

ant -Dplugin=gpxfilter singleplugintrans


Ah, thanks.  I fixed build.xml to make it work.  A plugin is translated 
with the commands:


./launchpad.pl bzronly
ant -Dplugin=gpxfilter singleplugintrans

The original i18n tasks did not add the plugin description (property 
plugin.description in plugin build.xml) to the plugin POT/*.lang files. 
 I changed that, the plugin description is now part of the plugin 
template josm.pot.  That translation is used once the plugin is 
installed.  Please revert revision 30143 if that change is not right.


Regards,
Holger


___
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] Wanted: Plugin Translation With Launchpad HowTo

2013-12-19 Thread Holger Mappt

Hi,

I think I figured this out now.  As Simon pointed out, there are 
infrequent plugin i18n updates, so you don't need to do anything at all. 
 But if you want to update the translations of a plugin more frequently:


There is an automatic process that extracts the language strings from 
the JOSM core and all plugins that are committed to [2].  That process 
is run once a day and the language strings are uploaded to Launchpad. 
See the Launchpad import queue [3] for the last upload/import.  After 
the upload to Launchpad the strings are available for translation. 
Thus, all you need to do to start the translation is to commit the code.


There are several ways to download the translations.

1) Create a new Launchpad project for the plugin.  Launchpad has a 
global pool of translations and all strings that are translated for JOSM 
can be copied to the plugin project and vice versa.  The advantage is 
that you can download only the translated strings needed for the plugin. 
 But the big disadvantage is that the translations need to be copied 
manually within Launchpad.  I.e. you need to copy the translation of 
every string in every language separately.  And there is no way to know 
when a translations changes in JOSM, so you cannot update the 
translation in the plugin project.


If you copy translations you are asked to make sure that you comply to 
the license of the other project, JOSM in our case.  That means the 
plugin projects needs the same license that JOSM has.  Or Launchpad's 
BSD license.


It's interesting that people will actively search for new projects and 
untranslated strings.  My plugin project was translated to Ukrainian 
shortly after I uploaded the POT file.


2) Use the "download translation tarballs" link [4].  You need a 
Launchpad account to do that.  After about 20 minutes you get an email 
with a download link.


3) The JOSM translations are synchronized with a Bazaar branch [5] once 
a day.


3a) My first idea was to check out that branch.  Then it is easy to 
update to the latest version of the translations.  But Bazaar is one of 
those revision control systems where you get the complete repository in 
your working copy.  I stopped the "bzr branch 
lp:~openstreetmap/josm/josm_trans" operation after 600MB were 
downloaded.  There is no point in downloading and keeping gigabytes of 
repository data for just a few translations.


3b) The nice thing about the Launchpad Bazaar branch is that you can 
download a tarball for a revision.  E.g. [6] for the current revision 
749.  This is the best way to download the translations, no need for a 
Launchpad account, no need to wait for emails.


Once you have the translations downloaded the next steps are straight 
forward: Update the translation template (*.pot, xgettext), merge the 
translations (msgmerge), remove unnecessary translations (msgattrib), 
and generate the *.lang files in the data directory.


This is my translation flow for the PhotoAdjust plugin [7].  It assumes 
that all translations are done at Launchpad.  The POT and PO files are 
stored on the directory po:


ant pot
./poimport.pl 749
./pomerge.pl
ant lang

The first step creates/updates the translation template 
po/photoadjust.pot.  It uses the gettext-ant-tasks.jar from the i18n 
directory ([8]).
The second step (poimport.pl) downloads all JOSM translations for 
revision 749 (see [5] for latest revision) as tarball.  The PO files are 
extracted from the tarball and copied into the po directory next to the 
translation template.
The third step (pomerge.pl) runs msgmerge and msgattrib.  I added 
msgattrib because I need just the 8 strings in the 6 available languages 
and not all 8526 string in 77 languages.  Fuzzy strings are removed 
because i18n.pl will do the same.
The last step runs "../../i18n/i18n.pl data po/*.po".  That generates 
the data/*.lang files.


The complete flow runs a few seconds plus the time to download all JOSM 
translations.  It is much faster than to run the complete translation 
process in directory i18n ([8], ./launchpad.pl 
http://launchpadlibrarian.net//launchpad-export.tar.gz).


Regards,
Holger

[2] http://svn.openstreetmap.org/applications/editors/josm/plugins/
[3] https://translations.launchpad.net/josm/trunk/+imports
[4] https://translations.launchpad.net/josm/trunk/+export
[5] https://code.launchpad.net/~openstreetmap/josm/josm_trans
[6] http://bazaar.launchpad.net/~openstreetmap/josm/josm_trans/tarball/749
[7] 
http://svn.openstreetmap.org/applications/editors/josm/plugins/photoadjust/

[8] http://svn.openstreetmap.org/applications/editors/josm/i18n/

Am 22.11.2013 14:02, schrieb Holger Mappt:

Hi,

JOSM core and all plugins from the JOSM plugins SVN repository are
translated with Launchpad.  There is documentation how to to work with
the complete set of strings (some 8000+).  But how do I get the
translation for the 10 strings of a single plugin?  Is there a
description how to g

Re: [josm-dev] Wanted: Plugin Translation With Launchpad HowTo

2013-11-22 Thread Holger Mappt

On 22 Nov 2013 17:24, Simon Legner wrote:

Which plugin are you referring to?


The plugin implements ticket #7712 [1].  It's not yet released.

[1] http://josm.openstreetmap.de/ticket/7712


See
https://trac.openstreetmap.org/browser/subversion/applications/editors/josm/i18n/build.xml#L81
how the language files are generated for the plugins in the SVN repository.
You'd have to make sure that the strings of your plugin get translated.


I guess I can just commit the plugin and wait until someone triggers the 
translation process.  But I would like to bundle the plugin myself 
without the need to download all 8404 strings in all languages 
(150MByte).  Is that possible?  I figured out most of the steps, just 
the upload/download of my 10 strings is not clear to me.  I don't think 
that I will get it right to upload all JOSM strings to Launchpad.  There 
is too much magic involved.


BTW, how frequently is the string extraction/upload/download/*.lang 
generation usually done?


I don't see an SVN commit in i18n/build.xml.  Is that done manually? 
Always or on request only?



That means the plugin would need to be release under one of the two
licenses


See
http://josm.openstreetmap.de/wiki/DevelopersGuide/DevelopingPlugins#LegalstuffImisopinion


My question was related to the translated strings.  They have a license 
that affects the license of the plugin.  Launchpad makes them available 
under the same license as the original "project" the sources were 
extracted from.  What counts as project in this context, JOSM (GPL v2+) 
or the plugin (more or less any license)?


Thanks,
Holger

___
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev


[josm-dev] Wanted: Plugin Translation With Launchpad HowTo

2013-11-22 Thread Holger Mappt

Hi,

JOSM core and all plugins from the JOSM plugins SVN repository are 
translated with Launchpad.  There is documentation how to to work with 
the complete set of strings (some 8000+).  But how do I get the 
translation for the 10 strings of a single plugin?  Is there a 
description how to get a small subset of the translations?  Would it 
make sense to create a new Launchpad project for the plugin as it would 
share the translations with JOSM?


If I understand it correctly, the license of the translations will be 
Launchpad's BSD license or JOSM's license, GPL v2+.  JOSM's license 
because it is the registered Launchpad project and according to the 
Launchpad Terms of Use: "Translations of groups of strings from the same 
project ... are made available ... to you under the licence applicable 
to the project" [1].  That means the plugin would need to be release 
under one of the two licenses as it includes the translations in the JAR 
file.  Or does the plugin itself count as "project"?


Thanks,
Holger

[1] https://help.launchpad.net/TermsofUse#Translations_copyright

___
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev


[josm-dev] MapMode Button State

2013-10-24 Thread Holger Mappt

Hi,

I created a map mode based on MapMode and an IconToggleButton that is 
added to the MapFrame.  The map mode works with objects on an overlay 
layer (photos of the GeoImageLayer).  The goal is to enable the button 
if there is at least one GeoImageLayer with at least one photo loaded 
and to disable/hide it otherwise.  The button method 
setAutoHideDisabledButton(true) is called to hide the button if there is 
nothing to do for my map mode.  Depending on the MapMode methods that I 
implement the button state can be enabled, disabled but visible, or hidden.


Question: How can I implement the intended map mode button behavior?  Is 
there a good example?


MapMode.layerIsSupported() seems to be the only method that JOSM 
supports to set the button state.  But it doesn't work in my case 
because the active layer doesn't matter.  MapMode.updateEnabledState() 
is implemented by some other MapModes, but I don't understand how it is 
connected to the button.  The MapMode is the button action, but I want 
to disable the button, not the action.  I can call 
IconToggleButton.setEnabled(), but MapView.setActiveLayer() overwrites 
it if the layer is switched.  What else can I do?


Thanks,
Holger

___
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev


Re: [josm-dev] MapMode, GeoImageLayer, mouseAdapter, Flags, Undo

2013-09-20 Thread Holger Mappt

Hi,

So a MapMode is one of the modes that I usually use to modify the OSM 
data.  Makes sense.  That means I could implement a MapMode to move the 
photos.  So far I was just thinking to enable my addition if the 
GeoImageLayer is active.


I started with a plug-in (the first I did was an option to toggle 
between thumbnails and icons for the photos) and will continue with it. 
 A plug-in has the advantage that others can improve it or fork it to 
implement other or better concepts.  E.g. the plug-in photo_geotagging 
is related to what I do.  Once everything is mature it could be added to 
the core.


Thanks,
Holger

Am 16.09.2013 23:36, schrieb Paul Hartmann:

On 09/16/2013 10:31 PM, Holger Mappt wrote:

Hi,

I have a proof of concept for my ticket 7712.  Until now I changed the
GeoImageLayer directly to keeps things simple.  Now I want to move the
additional code into a plug-in.  That raises a few questions.

The GeoImageLayer uses a MouseAdapter that is added and removed by a
MapModeChangeListener.  But what exactly is a MapMode?


Select, Draw, Zoom, ... (The buttons on the upper left)


 I can click on a
photo whenever it is displayed.  How is that related to the MapMode?


In certain MapModes (e.g. Draw) the mouse click is deactivated.


I want to be able to move photos of the active GeoImageLayer.  Can I use
a LayerChangeListener to register my MouseMotionAdapter or do I need a
MapModeChangeListener too?


You probably also want to turn this off in Draw mode, so yes.


Right now I do the same what the
GeoImageLayer does, i.e. use the MapModeChangeListener.

What is the best way to add a MouseMotionAdapter to the active
GeoImageLayer from a plug-in?  Do I just implement the right
ChangeListener and use it to add/remove the MouseMotionAdapter?  Or
would I register the MouseMotionAdapter in the GeoImageLayer?  Or
something else?  What plug-in would be a good example?
I want to mark an image as moved to be able to save the new coordinates
afterwards.  What is the recommended way to implement such a flag?  Is
there a type for flags, how do I name the set/get methods?


It seems somewhat cumbersome to implement this as a plugin. Why not
continue your work as a core enhancement? If it integrates well, we
could apply the patch directly. I think this would be a nice new feature
for the JOSM's geotagging support!


The undo/redo seems to work with OSM data only.  Is there a way to have
a separate undo buffer for the GeoImageLayer?  How would it work?


Sorry, no idea.

Paul



___
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev


[josm-dev] MapMode, GeoImageLayer, mouseAdapter, Flags, Undo

2013-09-16 Thread Holger Mappt

Hi,

I have a proof of concept for my ticket 7712.  Until now I changed the 
GeoImageLayer directly to keeps things simple.  Now I want to move the 
additional code into a plug-in.  That raises a few questions.


The GeoImageLayer uses a MouseAdapter that is added and removed by a 
MapModeChangeListener.  But what exactly is a MapMode?  I can click on a 
photo whenever it is displayed.  How is that related to the MapMode?


I want to be able to move photos of the active GeoImageLayer.  Can I use 
a LayerChangeListener to register my MouseMotionAdapter or do I need a 
MapModeChangeListener too?  Right now I do the same what the 
GeoImageLayer does, i.e. use the MapModeChangeListener.


What is the best way to add a MouseMotionAdapter to the active 
GeoImageLayer from a plug-in?  Do I just implement the right 
ChangeListener and use it to add/remove the MouseMotionAdapter?  Or 
would I register the MouseMotionAdapter in the GeoImageLayer?  Or 
something else?  What plug-in would be a good example?


I want to mark an image as moved to be able to save the new coordinates 
afterwards.  What is the recommended way to implement such a flag?  Is 
there a type for flags, how do I name the set/get methods?


The undo/redo seems to work with OSM data only.  Is there a way to have 
a separate undo buffer for the GeoImageLayer?  How would it work?


Thanks,
Holger

___
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev