external instead of internal icon used

[skyper]

What steps will reproduce the problem?

1. Additionally, to josm-latest package from this site, have a josm package from your distribution installed. Second shares the icons under /usr/share/josm/images/
2. Start latest
3. Look at the View menu

What is the expected result?

The new .svg icon for History is displayed

What happens instead?

The old .png icon is still displayed from /usr/share/josm/images/dialogs/history.png

Please provide any additional information below. Attach a screenshot if possible.

Please, prefer the icons within the .jar file over system icons.

Relative:URL: ^/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2020-08-22 22:13:32 +0200 (Sat, 22 Aug 2020)
Revision:16903
Build-Date:2020-08-23 01:30:51
URL:https://josm.openstreetmap.de/svn/trunk

VM arguments: [-Djosm.restart=true, -Djosm.dir.name=JOSM-latest, -Djava.net.useSystemProxies=true]

[simon04]

Please share a full status report. Plenty of data is missing (in particular "Identification").

[skyper]

Sorry.
There is not difference between the .jar file from this website and the.jar file in the package. It also happens if I manually start the .jar file with java -jar ….
Additionally, I have the josm debian backport package from buster-backports installed which has all icons extracted from the .jar file. That is where the icon comes from, but it lies under /usr/share/josm/images/ and not /usr/share/josm-latest/images/.
Just put some icons in the mentioned path with the same name as the icons in the .jar file and you should notice the problem.

Relative:URL: ^/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2020-08-25 23:27:27 +0200 (Tue, 25 Aug 2020)
Revision:16932
Build-Date:2020-08-26 01:30:48
URL:https://josm.openstreetmap.de/svn/trunk

Identification: JOSM/1.5 (16932 en) Linux Debian GNU/Linux 10 (buster)
Java version: 11.0.8+10-post-Debian-1deb10u1, Debian, OpenJDK 64-Bit Server VM
Look and Feel: javax.swing.plaf.metal.MetalLookAndFeel
Desktop environment: GNOME
Java package: openjdk-11-jre:amd64-11.0.8+10-1~deb10u1
VM arguments: [-Djosm.home=<josm.pref>]

[stoecker]

If you have a debian system with the debian concept of providing images in the system then that's a desired behaviour. Installed files override files included in JAR.

Simply remove the JOSM installation and thus the /usr/share/josm directory.

[skyper]

Why is this a wontfix. It is not a issue of a certain setup.

1. Icons within the .jar file should be chosen prior of any other icon.
2. josm-latest should use /usr/share/josm-latest/, at least that is the path the ubuntu package from this site is installed to. Only fallback to /usr/share/josm/

There is nothing wrong with my setup and there should be no problem to have a latest and a tested version installed at the same time.

This is similar to the problems with the correct plugin path, see #19006. Just use the right order of paths and I am happy.

I did not demand to have the images excluded from the .jar file which would be the correct handling for a .deb-packages.

[stoecker]

Replying to skyper:

1. Icons within the .jar file should be chosen prior of any other icon.

No. Icons on disk are priority. That's simple, as disk icons can be replaced by the user, icons in JAR not. So the other way round makes no sense.

[skyper]

Replying to stoecker:

Replying to skyper:

1. Icons within the .jar file should be chosen prior of any other icon.

No. Icons on disk are priority. That's simple, as disk icons can be replaced by the user, icons in JAR not. So the other way round makes no sense.

So where can I set the paths and the order? How can I exclude paths? At least the ubuntu package should have an option for that.

[sebastic]

The underlying problem seems to be that two josm packages are installed.

Adding Conflicts: josm to the josm-latest package may suffice.

This is what the josm-installer package in Debian does to ensure it's not co-installed with the regular josm package.

[skyper]

Replying to sebastic:

The underlying problem seems to be that two josm packages are installed.

This should not be a problem as long as they packages respect their own path. tested: /usr/share/josm/ and latest: /usr/share/josm-latest/

Adding Conflicts: josm to the josm-latest package may suffice.

This is what the josm-installer package in Debian does to ensure it's not co-installed with the regular josm package.

This is ok for tested but not for latest.

Just, try any .jar from this website with the debian package installed and you will get the icons from the debian package. So I do not need to install two packages to raise this problem.

[sebastic]

The upstream josm & josm-latest packages don't need to conflict as they don't provide the same files.

Looking at the source /usr/share/josm/ is only used to look for preferences. So it seems that josm-latest wouldn't use images available there. There may be something I'm missing, though.

The josm package in Debian contains a patch to load files from /usr/share/josm instead of from the JAR as the upstream package does, which further seems to support that the upstream packages don't use /usr/share/josm.

From the ImageProvider sources I get the impression that not the file from /usr/share/josm is used but the one from the cache which was created by the josm package.

Mixing the upstream and distribution josm packages is a bad idea. As long as Conflicts don't cause apt to remove the installed package once you install the other, you'll need to do this yourself, e.g.:

apt install josm-latest josm-

Or:

apt purge josm josm-latest+

[skyper]

As I already mentioned, you do not need the upstream package. Starting josm-latest.jar with java -Dhome=/tmp/josm -jar josm-latest.jar with the debian package installed leads to the same situation. Probably, even any icon under /usr/share/josm/image/ with the same name as within the .jar file will lead to problems.

How about offering the paths as preferences?
That way, I could add and delete paths and even define the order of it. This might help with the plugins, too, thought the situation there is more tricky as new plugins need to be saved to the correct, local folder.

Did not test /usr/local/share/josm/, yet.

[simon04]

See ​https://github.com/openstreetmap/josm/blob/8aac05557b708a9b1ffa91b7d8e8e1ec722e656e/src/org/openstreetmap/josm/tools/ImageProvider.java#L1219-L1278 for JOSM's image search sequence.

[skyper]

See #19756 for a follow-up requesting a preference setting for the image paths.