Modify

Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#18845 closed enhancement (fixed)

reorganization of data(_nodist), images(_nodist), styles(_nodist), IDE and native files in a more practical file tree

Reported by: simon04 Owned by: team
Priority: major Milestone: 20.03
Component: Core Version:
Keywords: repository resources Cc: Don-vip, skyper, stoecker, Klumbumbus, leni, DiGro

Description

Replying to Don-vip:

In 16006/josm:
see #18140 - reorganization of data(_nodist), images(_nodist), styles(_nodist), IDE and native files in a more practical file tree.

  • Everything belonging to the jar is now in resources (data, images, styles)
  • Everything not belonging to the jar is now in nodist (data, images, styles)
  • Everything related to OS native functions is now in native (linux, macosx, windows)
  • Everything related to an IDE is now in ide (eclipse, netbeans)

Attachments (1)

wiki_HelpWindow.png (32.5 KB ) - added by leni 4 years ago.
differents Rules Validator - wiki and JOSM Help browser

Download all attachments as: .zip

Change History (109)

comment:1 by simon04, 4 years ago

Awesome! This layout is imposed by Maven or Gradle and makes setting up an IDE much easier. Thank you!

comment:2 by simon04, 4 years ago

Keywords: repository resources added

Since we have to update the i18n process (i18n.install.dir in i18n/build.xml) anyways, should we move the .lang files to a separate directory, such as resources/data/i18n?

comment:3 by simon04, 4 years ago

skyper in 18140#comment:36:

So all icon pathes in the wiki need to be adjusted.

stoecker in 18140#comment:37:

We probably can do this semi-automatic.

Also, the Trac logo URL needs to be updated.

in reply to:  2 ; comment:4 by stoecker, 4 years ago

Replying to simon04:

Since we have to update the i18n process (i18n.install.dir in i18n/build.xml) anyways, should we move the .lang files to a separate directory, such as resources/data/i18n?

That would be bad as it would affects all plugins.

in reply to:  3 ; comment:5 by stoecker, 4 years ago

Cc: Klumbumbus added

Replying to simon04:

skyper in 18140#comment:36:

So all icon pathes in the wiki need to be adjusted.

stoecker in 18140#comment:37:

We probably can do this semi-automatic.

Question is: Do we want to take that chance to replace the image macro with an JOSM specific one, so that it auto-detects PNG/SVG and references directly to the JOSM image dir?

Also, the Trac logo URL needs to be updated.

Done.

comment:6 by Hb---, 4 years ago

Main logo on front page is currently 404.

comment:7 by stoecker, 4 years ago

Cc: leni added

comment:8 by stoecker, 4 years ago

Main logo on front page is currently 404.

Fixed.

@Vincent: I hope you know what a can of worms you opened with the reorganisation?

comment:9 by stoecker, 4 years ago

@leni: Please use tickets and not the SPAM report feature to report issues with the wiki.

comment:10 by leni, 4 years ago

@stoecker someone told me to use SPAM report for image... when to use it? only for attachments?

in reply to:  10 comment:11 by stoecker, 4 years ago

Replying to leni:

@stoecker someone told me to use SPAM report for image... when to use it? only for attachments?

SPAM report should be used when the result is an admin deleting the "offending" stuff (i.e. you may also use it e.g. for accidentially created pages or obsolete images to get rid off or alike). Deleting is the only possible action. Everything else which may need feedback is better done via ticket.

comment:12 by Don-vip, 4 years ago

@Dirk yes I know. This is something I wanted to do for a long time and never did because of fear of the worms. I have found enough courage to do it now Did I broke the i18n or not? I forgot about it yesterday.

comment:13 by GerdP, 4 years ago

The command

ant clean dist 

no longer works with r16010 or newer, probably one of the recent changes made for this ticket.

epsg-compile:
    [mkdir] Created dir: C:\josm\core\build2
    [javac] Compiling 1 source file to C:\josm\core\build2

epsg:
    [touch] Creating C:\josm\core\resources\data\projection\custom-epsg
     [java] Exception in thread "main" java.lang.ExceptionInInitializerError
     [java]     at BuildProjectionDefinitions.initMap(BuildProjectionDefinitions.java:91)
     [java]     at BuildProjectionDefinitions.buildList(BuildProjectionDefinitions.java:109)
     [java]     at BuildProjectionDefinitions.main(BuildProjectionDefinitions.java:77)
     [java] Caused by: org.openstreetmap.josm.tools.JosmRuntimeException: java.io.IOException: Failed to open input stream for resource 'resource://data/projection/custom-epsg'
     [java]     at org.openstreetmap.josm.data.projection.Projections.<clinit>(Projections.java:175)
     [java]     ... 3 more
     [java] Caused by: java.io.IOException: Failed to open input stream for resource 'resource://data/projection/custom-epsg'
     [java]     at org.openstreetmap.josm.io.CachedFile.lambda$getInputStream$0(CachedFile.java:231)
     [java]     at java.util.Optional.orElseThrow(Optional.java:290)
     [java]     at org.openstreetmap.josm.io.CachedFile.getInputStream(CachedFile.java:231)
     [java]     at org.openstreetmap.josm.io.CachedFile.getContentReader(CachedFile.java:258)
     [java]     at org.openstreetmap.josm.data.projection.Projections.loadProjectionDefinitions(Projections.java:301)
     [java]     at org.openstreetmap.josm.data.projection.Projections.<clinit>(Projections.java:170)
     [java]     ... 3 more

BUILD FAILED
C:\josm\core\build.xml:1046: Java returned: 1
Last edited 4 years ago by GerdP (previous) (diff)

in reply to:  5 comment:14 by stoecker, 4 years ago

Question is: Do we want to take that chance to replace the image macro with an JOSM specific one, so that it auto-detects PNG/SVG and references directly to the JOSM image dir?

comments?

in reply to:  5 ; comment:15 by skyper, 4 years ago

Replying to stoecker:

Question is: Do we want to take that chance to replace the image macro with an JOSM specific one, so that it auto-detects PNG/SVG and references directly to the JOSM image dir?

+1

  • there is no image dir but some within trunk, some in the wiki like (external) presets and many elsewhere, including (external) presets and plugins.
  • personally the name of the icon is my major problem when searching, the path is only minor priority.

in reply to:  5 ; comment:16 by Klumbumbus, 4 years ago

Replying to stoecker:

Question is: Do we want to take that chance to replace the image macro with an JOSM specific one, so that it auto-detects PNG/SVG and references directly to the JOSM image dir?

Yes, that would definitely reduce work load after changes of #15240.
Would the internal help browser manage it well? Would it create lots of more work if we leave trac one day?

in reply to:  16 ; comment:17 by stoecker, 4 years ago

Replying to Klumbumbus:

Replying to stoecker:

Question is: Do we want to take that chance to replace the image macro with an JOSM specific one, so that it auto-detects PNG/SVG and references directly to the JOSM image dir?

Yes, that would definitely reduce work load after changes of #15240.

I'll have a look then.

Would the internal help browser manage it well?

Yes. It does not know of the wiki language, it reads HTML.

Would it create lots of more work if we leave trac one day?

Well, that would be so much work, that I don't consider it at all. Staying on an old trac version is the much easier choice.

in reply to:  15 comment:18 by stoecker, 4 years ago

Replying to skyper:

Replying to stoecker:

Question is: Do we want to take that chance to replace the image macro with an JOSM specific one, so that it auto-detects PNG/SVG and references directly to the JOSM image dir?

+1

  • there is no image dir but some within trunk, some in the wiki like (external) presets and many elsewhere, including (external) presets and plugins.

This is only for JOSM images, i.e. these which are accessed with "source:...". The main idea is to make them behave like JOSM does with auto-detection of image extension. Everything else will be unchanged.

in reply to:  17 comment:19 by Klumbumbus, 4 years ago

Replying to stoecker:

Would it create lots of more work if we leave trac one day?

Well, that would be so much work, that I don't consider it at all. Staying on an old trac version is the much easier choice.

OK (I thought if we switch from svn to git we would leave trac entirely.)

in reply to:  3 ; comment:20 by Klumbumbus, 4 years ago

stoecker in 18140#comment:37:

We probably can do this semi-automatic.

Rather are forced to as updating the links is not doable manually https://josm.openstreetmap.de/search?q=Image%28source%3Atrunk%2Fimages
1k pages, so probably 10k links :)

in reply to:  4 ; comment:21 by simon04, 4 years ago

Replying to stoecker:

Replying to simon04:

Since we have to update the i18n process (i18n.install.dir in i18n/build.xml) anyways, should we move the .lang files to a separate directory, such as resources/data/i18n?

That would be bad as it would affects all plugins.

The Ant task plugintrans runs i18n.pl [...] --basedir=${plugin.dir}/${dir}/data/, thus, plugins are unaffected from changing ${i18n.install.dir} which is only used in the task coretrans.

in reply to:  12 ; comment:22 by stoecker, 4 years ago

Replying to Don-vip:

Did I broke the i18n or not?

What do you think?
[o35345:35346]

I forgot about it yesterday.

And many many more... :-)

in reply to:  21 ; comment:23 by stoecker, 4 years ago

Replying to simon04:

Replying to stoecker:

Replying to simon04:

Since we have to update the i18n process (i18n.install.dir in i18n/build.xml) anyways, should we move the .lang files to a separate directory, such as resources/data/i18n?

That would be bad as it would affects all plugins.

The Ant task plugintrans runs i18n.pl [...] --basedir=${plugin.dir}/${dir}/data/, thus, plugins are unaffected from changing ${i18n.install.dir} which is only used in the task coretrans.

Please stop thinking only from source side. If we change the directory where translations are stored then we also need to do this for the plugins, as core and plugins use the same mechanisms. And having different places for source and final jar would actually be opposite to what is the goal of this directory change so that's also no option.

comment:24 by simon04, 4 years ago

In 16012/josm:

see #18845 - Move lang to resources/data/trans/

comment:25 by simon04, 4 years ago

In 16013/josm:

see #18845 - I18n update

in reply to:  23 ; comment:26 by simon04, 4 years ago

Replying to stoecker:

Please stop thinking only from source side.

Ups, I was just preparing my commits and overlooked your reply…

If we change the directory where translations are stored then we also need to do this for the plugins, as core and plugins use the same mechanisms.

Actually not, see https://josm.openstreetmap.de/changeset/16012/josm/trunk/src/org/openstreetmap/josm/tools/I18n.java

If the move to resources/data/trans/ is not an option, I'm going to revert my changes.

For i18n: [o35347], [o35348].

Last edited 4 years ago by simon04 (previous) (diff)

in reply to:  20 ; comment:27 by Klumbumbus, 4 years ago

Replying to Klumbumbus:

stoecker in 18140#comment:37:

We probably can do this semi-automatic.

Rather are forced to as updating the links is not doable manually https://josm.openstreetmap.de/search?q=Image%28source%3Atrunk%2Fimages
1k pages, so probably 10k links :)

Another thing to consider: even if all image paths were updated semi automatic then the revision of all translated pages will be outdated. In best case the revision of the translated page would be increased by one during the image path update in case the translated page was up to date before. And do not increase if the page was outdated already before. Not sure if this is possible.

Last edited 4 years ago by Klumbumbus (previous) (diff)

comment:28 by stoecker, 4 years ago

In 16014/josm:

revert translation file move, see #18845

comment:29 by stoecker, 4 years ago

In 16015/josm:

move nodist/data/trans one level up, see #18845

comment:30 by Klumbumbus, 4 years ago

JOSM imagery pages can't be edited.
Warnung: Ungültige Wiki-Seite: XML validation for map failed: [Errno 2] No such file or directory: '/home/josm/auto/svn_josm/core/data/maps.xsd'

in reply to:  30 ; comment:31 by stoecker, 4 years ago

Replying to Klumbumbus:

JOSM imagery pages can't be edited.
Warnung: Ungültige Wiki-Seite: XML validation for map failed: [Errno 2] No such file or directory: '/home/josm/auto/svn_josm/core/data/maps.xsd'

Yes. Found it a few seconds ago. Fixed?

comment:32 by stoecker, 4 years ago

I think the important parts on the server side should be fixed now. We'll see tomorrow when latest is built.

comment:33 by stoecker, 4 years ago

[o35349]

in reply to:  13 comment:34 by GerdP, 4 years ago

Replying to GerdP:

The command

ant clean dist 

no longer works with r16010 or newer, probably one of the recent changes made for this ticket.

epsg-compile:
    [mkdir] Created dir: C:\josm\core\build2
    [javac] Compiling 1 source file to C:\josm\core\build2

epsg:
    [touch] Creating C:\josm\core\resources\data\projection\custom-epsg
     [java] Exception in thread "main" java.lang.ExceptionInInitializerError
     [java]     at BuildProjectionDefinitions.initMap(BuildProjectionDefinitions.java:91)
     [java]     at BuildProjectionDefinitions.buildList(BuildProjectionDefinitions.java:109)
     [java]     at BuildProjectionDefinitions.main(BuildProjectionDefinitions.java:77)
     [java] Caused by: org.openstreetmap.josm.tools.JosmRuntimeException: java.io.IOException: Failed to open input stream for resource 'resource://data/projection/custom-epsg'
     [java]     at org.openstreetmap.josm.data.projection.Projections.<clinit>(Projections.java:175)
     [java]     ... 3 more
     [java] Caused by: java.io.IOException: Failed to open input stream for resource 'resource://data/projection/custom-epsg'
     [java]     at org.openstreetmap.josm.io.CachedFile.lambda$getInputStream$0(CachedFile.java:231)
     [java]     at java.util.Optional.orElseThrow(Optional.java:290)
     [java]     at org.openstreetmap.josm.io.CachedFile.getInputStream(CachedFile.java:231)
     [java]     at org.openstreetmap.josm.io.CachedFile.getContentReader(CachedFile.java:258)
     [java]     at org.openstreetmap.josm.data.projection.Projections.loadProjectionDefinitions(Projections.java:301)
     [java]     at org.openstreetmap.josm.data.projection.Projections.<clinit>(Projections.java:170)
     [java]     ... 3 more

BUILD FAILED
C:\josm\core\build.xml:1046: Java returned: 1

Probably caused by me: I've manually removed \data\projection\custom-epsg
With a clean checkout you should see the same problem.

in reply to:  26 comment:35 by simon04, 4 years ago

Replying to simon04:

Replying to stoecker:

Please stop thinking only from source side.

Ups, I was just preparing my commits and overlooked your reply…

@stoecker, I didn't mean to overrule you. After investigating comment:21, I was preparing my commits and didn't check for new comments on this issue. Only after committing, I've read your reply.

comment:36 by stoecker, 4 years ago

@Vincent: Most of the big worm are back inside, happy hunting for the smaller ones ;-)

in reply to:  31 comment:37 by Klumbumbus, 4 years ago

Replying to stoecker:

Replying to Klumbumbus:

JOSM imagery pages can't be edited.
Warnung: Ungültige Wiki-Seite: XML validation for map failed: [Errno 2] No such file or directory: '/home/josm/auto/svn_josm/core/data/maps.xsd'

Yes. Found it a few seconds ago. Fixed?

Yes.

comment:38 by simon04, 4 years ago

In 16017/josm:

revert translation file move, see #18845 (update CORE_TRANS_DIRECTORY)

comment:39 by Don-vip, 4 years ago

In 16018/josm:

see #18845 - fix epsg and taginfo goals

in reply to:  22 comment:40 by Don-vip, 4 years ago

Replying to stoecker:

Replying to Don-vip:

Did I broke the i18n or not?

What do you think?

By "broken" I was afraid to have uploaded to Launchpad incomplete translations, thus deleting thousands of translated strings. I'm relieved it didn't happen this way.

And many many more... :-)

Thanks for the help! :)

in reply to:  36 comment:41 by Don-vip, 4 years ago

Replying to stoecker:

@Vincent: Most of the big worm are back inside, happy hunting for the smaller ones ;-)

Thanks! I'm on it :)

comment:42 by simon04, 4 years ago

There are two failing tests, https://josm.openstreetmap.de/jenkins/job/JOSM/lastCompletedBuild/testReport/:

  • org.openstreetmap.josm.data.VersionTest.testGetAgentString
  • org.openstreetmap.josm.data.validation.tests.MapCSSTagCheckerTest.testPreprocessing

comment:43 by Don-vip, 4 years ago

I'm on it

comment:44 by Don-vip, 4 years ago

In 16019/josm:

see #18845 - fix unit test

in reply to:  42 ; comment:45 by Don-vip, 4 years ago

Replying to simon04:

  • org.openstreetmap.josm.data.VersionTest.testGetAgentString

Fixed, my fault.

  • org.openstreetmap.josm.data.validation.tests.MapCSSTagCheckerTest.testPreprocessing

This one I don't understand. The test is OK for me. Do you have an idea?

in reply to:  39 comment:46 by GerdP, 4 years ago

Replying to Don-vip:

In 16018/josm:

see #18845 - fix epsg and taginfo goals

Thanks,

ant clean dist

works again on Windows system.

in reply to:  45 comment:47 by GerdP, 4 years ago

Replying to Don-vip:

Replying to simon04:

  • org.openstreetmap.josm.data.VersionTest.testGetAgentString

Fixed, my fault.

  • org.openstreetmap.josm.data.validation.tests.MapCSSTagCheckerTest.testPreprocessing

This one I don't understand. The test is OK for me. Do you have an idea?

IIGTR target test is missing a dependency on create-revision.
I can reproduce the problem with a clean checkout and

ant compile-test
ant -Ddefault-junit-includes="**/**/MapCSSTag*Test.class" test

After this the needed file REVISION is missing in the build directory.

Last edited 4 years ago by GerdP (previous) (diff)

comment:48 by GerdP, 4 years ago

In 16028/josm:

see #18845: fix target compile-test dependencies

in reply to:  27 comment:49 by Hb---, 4 years ago

Replying to

stoecker: ... replace the image macro with an JOSM specific on ?

Replying to Klumbumbus:

1k pages, so probably 10k links :)

if all image paths were updated semi automatic, then the revision of all translated pages will be outdated. ...

A semiautomated solution for the wiki image source links seems fine. The active translators can handle this. For the non active it is unimportant if a page is 20 or 21 versions behind.

Please inform how the decision is. If it is still open, please give notice too.

in reply to:  27 comment:50 by stoecker, 4 years ago

My plan currently is:

  • Get the new link-variant working for tests (today)
  • extract the what-to-change list from the SQL directly
  • update my "automatically overflood trac with hundred requests script" to change the pages accordingly (As requested updating the translated pages revsion by one when applicable)
  • start the script
  • present all the broken links found during this process for manual fixing.

comment:51 by stoecker, 4 years ago

Please try:

[[JOSMImage(openlocation)]] [[JOSMImage(audio-fwd)]]

source:trunk/resources/images/openlocation.svg source:trunk/resources/images/audio-fwd.svg

See docs at WikiMacros#JOSMImage-macro

Please test.

in reply to:  48 comment:52 by Don-vip, 4 years ago

Replying to GerdP:

In 16028/josm:

see #18845: fix target compile-test dependencies

I removed the test-compile dependency on "dist" especially to avoid the call to create-revision, as it causes problems with the server Makefile. I will try to see why this test needs the REVISION file, it's strange.

comment:53 by GerdP, 4 years ago

OK. See also #18858.

comment:54 by Don-vip, 4 years ago

In 16033/josm:

see #18845 - make MapCSSTagCheckerTest work without REVISION file

comment:55 by Don-vip, 4 years ago

In 16036/josm:

see #18845, fix #18858 - fix ant build

in reply to:  51 ; comment:56 by Klumbumbus, 4 years ago

Replying to stoecker:

Please test.

inline seems to not work:

heading source:trunk/resources/images/presets/shop/beauty.svg text

heading source:trunk/resources/images/presets/shop/beauty.svg text

Can't really test @rev as all images were moved, however I think there is not a single usage of that code in the wiki anyway.

in reply to:  56 comment:57 by stoecker, 4 years ago

Replying to Klumbumbus:

Replying to stoecker:

Please test.

inline seems to not work:

heading source:trunk/resources/images/presets/shop/beauty.svg text

heading source:trunk/resources/images/presets/shop/beauty.svg text

Really :-)

Can't really test @rev as all images were moved, however I think there is not a single usage of that code in the wiki anyway.

That makes no sense anyway. If you have a specific revision you can use the normal macro, as this revision will never change.

comment:58 by Klumbumbus, 4 years ago

Great. From my POV the JOSMImage macro is fine.

in reply to:  51 ; comment:59 by Hb---, 4 years ago

Replying to stoecker:

source:trunk/resources/images/openlocation.svg source:trunk/resources/images/audio-fwd.svg

The png is fine, but the svg image audio-fwd is not shown in JOSM Help browser, neither as block nor inline. But this may be related to the help system and not to the new macro.

in reply to:  59 comment:60 by Klumbumbus, 4 years ago

Replying to Hb---:

Replying to stoecker:

source:trunk/resources/images/openlocation.svg source:trunk/resources/images/audio-fwd.svg

The png is fine, but the svg image audio-fwd is not shown in JOSM Help browser,

These and the ones in the headings are displayed fine for me in the josm internal help browser.

in reply to:  51 ; comment:61 by skyper, 4 years ago

Replying to stoecker:

...
Please test.

Mmh, should [[JOSMImage(relation)]] work (source:trunk/resources/images/relation.png) or only [[JOSMImage(data/relation)]] (source:trunk/resources/images/data/relation.svg) ?

Last edited 4 years ago by skyper (previous) (diff)

in reply to:  61 ; comment:62 by stoecker, 4 years ago

Replying to skyper:

Mmh, should [[JOSMImage(relation)]] work (source:trunk/resources/images/relation.png) or only [[JOSMImage(data/relation)]] (source:trunk/resources/images/data/relation.svg) ?

See docs: WikiMacros#JOSMImage-macro: The first parameter is a path inside trunk/resources/images/ without the extension. So the first can't work, as there is no relation.xxx inside the path.

in reply to:  62 ; comment:63 by Hb---, 4 years ago

Replying to Klumbumbus:
All image types are fine after updating to 1.8.0_242-b08, AdoptOpenJDK, OpenJDK 64-Bit Server VM.

Replying to stoecker:

The first parameter is a path inside trunk/resources/images/ without the extension.

I chocked on that sentence too. Suggestion:

The first parameter is a file path starting at trunk/resources/images/ without the extension.

in reply to:  63 ; comment:64 by stoecker, 4 years ago

Replying to Hb---:

The first parameter is a file path starting at trunk/resources/images/ without the extension.

Well, saying "file path" is same for me as saying "female woman". That's implied. I changed the inside: The first parameter is a path in the directory

Last edited 4 years ago by stoecker (previous) (diff)

comment:65 by Klumbumbus, 4 years ago

We should probably not change image links like in https://josm.openstreetmap.de/wiki/Help/Menu/Help?action=diff&version=38 and https://josm.openstreetmap.de/wiki/De%3AHelp/Menu/Help?action=diff&version=23 as this might complicate the planned semiautomatic update. The goal is anyway not source:/trunk/resources/images/dialogs/search.png[[Image(source:/trunk/resources/images/dialogs/search.png)]] but source:trunk/resources/images/dialogs/search.svg [[JOSMImage(dialogs/search)]]

Dirk?

in reply to:  65 comment:66 by stoecker, 4 years ago

Replying to Klumbumbus:

We should probably not change image links like in https://josm.openstreetmap.de/wiki/Help/Menu/Help?action=diff&version=38 and https://josm.openstreetmap.de/wiki/De%3AHelp/Menu/Help?action=diff&version=23 as this might complicate the planned semiautomatic update.

I have no issue with that. Manual fixes simply mean that the script has to do less ;-)

The goal is anyway not source:/trunk/resources/images/dialogs/search.png[[Image(source:/trunk/resources/images/dialogs/search.png)]]

These case will also be converted to JOSMImage macro when found.

but source:trunk/resources/images/dialogs/search.svg [[JOSMImage(dialogs/search)]]

Dirk?

I hope I find time this weekend for this task.

comment:67 by Klumbumbus, 4 years ago

I get Warnung: Ungültige Wiki-Seite: XML validation for style failed: [Errno 2] No such file or directory: '/home/josm/auto/svn_josm/core/resources/data/mappaint-style.xsd'
when trying to edit wiki:/Styles/LegacyStandard

comment:68 by skyper, 4 years ago

[[BadReport]] needs to be updated.

comment:69 by Don-vip, 4 years ago

In 16050/josm:

see #18845 - see #16860 - directory cleanup

comment:70 by Don-vip, 4 years ago

In 16051/josm:

see #18845 - integration tests need REVISION file

in reply to:  67 comment:71 by stoecker, 4 years ago

Replying to Klumbumbus:

I get Warnung: Ungültige Wiki-Seite: XML validation for style failed: [Errno 2] No such file or directory: '/home/josm/auto/svn_josm/core/resources/data/mappaint-style.xsd'
when trying to edit wiki:/Styles/LegacyStandard

Oh, that bug must be there for a long time. Fixed it.

comment:72 by Don-vip, 4 years ago

In 16064/josm:

see #18845 - see #18880 - update Netbeans files

comment:73 by leni, 4 years ago

there are two different images for the validator: in dialogs directory source:trunk/resources/images/dialogs/validator.svg and in preferences directory source:trunk/resources/images/preferences/validator.svg

I modified https://josm.openstreetmap.de/wiki/Rules by changing the macro for the Validator image; I replaced the "image" macro by the "JOSMImage" macro without modifying either the directory or the original parameters:

at the top of the page from dialogs directory source:trunk/resources/images/dialogs/validator.svg with parameter (dialogs/validator,middle,margin-right=20)
and after the table from preferences directory source:trunk/resources/images/preferences/validator.svg with parameter (preferences/validator,15)

but the display is different between wiki and JOSM Help browser :
in the wiki page the result is as above; when in JOSM Help browser first image is smaller than the second one.

I use W10 and Firefox

in reply to:  64 comment:74 by Hb---, 4 years ago

Replying to leni:
On the Rules page the first occurrence of the image had no width attribute.
But it did have a style attribute (middle) which the second has not. This may be the cause. Additionally the image resizing in the Help browser has at least one bug #15864.

Replying to stoecker:

... saying "file path" is same for me as saying "female woman". That's implied.

Well, that Redmond OS had blown this fact away from me.

by leni, 4 years ago

Attachment: wiki_HelpWindow.png added

differents Rules Validator - wiki and JOSM Help browser

comment:75 by leni, 4 years ago

Replying to Hb---:

Replying to leni:
On the Rules page the first occurrence of the image had no width attribute.
But it did have a style attribute (middle) which the second has not. This may be the cause.

The change you made in the rules page didn't change anything, it wasn't meant to be that.

Additionally the image resizing in the Help browser has at least one bug #15864.

Sorry, it must be a duplicate with #15864 (I joined image)

Last edited 4 years ago by leni (previous) (diff)

comment:76 by leni, 4 years ago

Cc: DiGro added

comment:77 by skyper, 4 years ago

@ Dirk:

Sorry, totally forgot about it but it would be nice if link= could be automatically set and be overridden with a value if needed. Also middle would be nice as default. Right now, you have to added it to almost every image.

comment:78 by stoecker, 4 years ago

All Updates

Report any errors (I hope none :-)

in reply to:  77 ; comment:79 by stoecker, 4 years ago

Replying to skyper:

@ Dirk:

Sorry, totally forgot about it but it would be nice if link= could be automatically set and be overridden with a value if needed. Also middle would be nice as default. Right now, you have to added it to almost every image.

I'm no magician. I can do straightforward changes with such a script, but no complicated argument handling. Now it's to late anyway.

comment:80 by stoecker, 4 years ago

Either my script had an error in the detection or there are really no dead image links anywhere (any png/svg issue was fixed automatically).

in reply to:  78 ; comment:81 by Klumbumbus, 4 years ago

Replying to stoecker:

All Updates

Hah, even that 1430 points cheat code didn't bring you the first place at https://josm.openstreetmap.de/stats/wiki#EditsByAuthor ;)

in reply to:  79 ; comment:82 by stoecker, 4 years ago

Replying to stoecker:

Replying to skyper:

@ Dirk:

Sorry, totally forgot about it but it would be nice if link= could be automatically set and be overridden with a value if needed. Also middle would be nice as default. Right now, you have to added it to almost every image.

I'm no magician. I can do straightforward changes with such a script, but no complicated argument handling. Now it's to late anyway.

I can add "middle,link=" as default argument to JOSMImage() when no arguments are given. Would that be fine? Klumbumbus?

in reply to:  81 ; comment:83 by stoecker, 4 years ago

Replying to Klumbumbus:

Replying to stoecker:

All Updates

Hah, even that 1430 points cheat code didn't bring you the first place at https://josm.openstreetmap.de/stats/wiki#EditsByAuthor ;)

Well, in the second column I am :-)

in reply to:  82 ; comment:84 by Klumbumbus, 4 years ago

Replying to stoecker:

I can add "middle,link=" as default argument to JOSMImage() when no arguments are given. Would that be fine? Klumbumbus?

I think so.

in reply to:  84 ; comment:85 by skyper, 4 years ago

Replying to Klumbumbus:

Replying to stoecker:

I can add "middle,link=" as default argument to JOSMImage() when no arguments are given. Would that be fine? Klumbumbus?

I think so.

That is what I had in mind.

in reply to:  83 comment:86 by skyper, 4 years ago

Replying to stoecker:

Replying to Klumbumbus:

Replying to stoecker:

All Updates

Hah, even that 1430 points cheat code didn't bring you the first place at https://josm.openstreetmap.de/stats/wiki#EditsByAuthor ;)

Well, in the second column I am :-)

Would you mind, to give me the user right to view the stats, again. Thanks

in reply to:  85 comment:87 by stoecker, 4 years ago

Replying to skyper:

Replying to Klumbumbus:

Replying to stoecker:

I can add "middle,link=" as default argument to JOSMImage() when no arguments are given. Would that be fine? Klumbumbus?

I think so.

That is what I had in mind.

Done.

comment:88 by Don-vip, 4 years ago

In 16126/josm:

see #18845 - fix build.xml for script targets, jar file is not required

comment:89 by Don-vip, 4 years ago

Is everything fixed, or do we still need to do something?

comment:90 by simon04, 4 years ago

In 16140/josm:

see #18140 - build.xml: use ${resources.dir}

comment:91 by Don-vip, 4 years ago

Resolution: fixed
Status: newclosed

comment:92 by leni, 4 years ago

thank you for this work and stay safe.

comment:93 by skyper, 4 years ago

@Dirk:
The defaults for [[JOSMImage()]] are lost, if you add another option.

source:trunk/resources/images/dialogs/delete.svg [[JOSMImage(dialogs/delete,64)]] should be the same as source:trunk/resources/images/dialogs/delete.svg [[JOSMImage(dialogs/delete,64,middle,link=)]] but it is not.

in reply to:  93 ; comment:94 by stoecker, 4 years ago

Replying to skyper:

@Dirk:
The defaults for [[JOSMImage()]] are lost, if you add another option.

As documented, read WikiMacros#JOSMImage-macro.

source:trunk/resources/images/dialogs/delete.svg [[JOSMImage(dialogs/delete,64)]] should be the same as source:trunk/resources/images/dialogs/delete.svg [[JOSMImage(dialogs/delete,64,middle,link=)]] but it is not.

No, as it would be impossible to get rid of the two options if needed.

in reply to:  94 comment:95 by skyper, 4 years ago

Replying to stoecker:

No, as it would be impossible to get rid of the two options if needed.

I see, thanks. Might need to set a default size once we have more bigger .svg icons.

in reply to:  80 ; comment:96 by Klumbumbus, 4 years ago

Replying to stoecker:

Either my script had an error in the detection or there are really no dead image links anywhere

I just noticed a broken image link on wiki:/Help/Action/About and its translated pages. (No big deal to fix this by hand though. Just in case you want to investigate.)

in reply to:  96 ; comment:97 by skyper, 4 years ago

Replying to Klumbumbus:

Replying to stoecker:

Either my script had an error in the detection or there are really no dead image links anywhere

I just noticed a broken image link on wiki:/Help/Action/About and its translated pages. (No big deal to fix this by hand though. Just in case you want to investigate.)

This is one rare special case. In general, everything went smooth. Found more broken links to source than images. Thanks

Last edited 4 years ago by skyper (previous) (diff)

in reply to:  97 comment:98 by stoecker, 4 years ago

Replying to skyper:

Replying to Klumbumbus:

Replying to stoecker:

Either my script had an error in the detection or there are really no dead image links anywhere

I just noticed a broken image link on wiki:/Help/Action/About and its translated pages. (No big deal to fix this by hand though. Just in case you want to investigate.)

This is one rare special case. In general, everything went smooth. Found more broken links to source than images. Thanks

Probably because of the "josm" at the beginning of the link. I'll have to rerun the script to fix these cases as well. I'll try tomorrow, don't have the necessary software here ATM.

comment:99 by skyper, 4 years ago

If rerun, please:

  • remove default values from [[JOSMImage()]] if no other option is present. That are most changes regarding images, atm.
  • additionally, look for ^source: in links and adjust them.
Last edited 4 years ago by skyper (previous) (diff)

in reply to:  99 ; comment:100 by stoecker, 4 years ago

Replying to skyper:

If rerun, please:

  • remove default values from [[JOSMImage()]] if no other option is present. That are most changes regarding images, atm.

I'll only change links I forgot, not the ones I already changed. But I'll keep this in mind.

  • additionally, look for ^source: in links and adjust them.

I have no idea what that means.

Last edited 4 years ago by stoecker (previous) (diff)

in reply to:  100 comment:101 by skyper, 4 years ago

Replying to stoecker:

Replying to skyper:

If rerun, please:

  • remove default values from [[JOSMImage()]] if no other option is present. That are most changes regarding images, atm.

I'll only change links I forgot, not the ones I already changed. But I'll keep this in mind.

Ok.

  • additionally, look for ^source: in links and adjust them.

I have no idea what that means.

See search and the first change in Styles, e.g. [source:trunk/styles/standard/elemstyles.mapcss JOSM standard] to [source:/trunk/resources/styles/standard/elemstyles.mapcss JOSM standard]

in reply to:  96 comment:102 by stoecker, 4 years ago

Replying to Klumbumbus:

Replying to stoecker:

Either my script had an error in the detection or there are really no dead image links anywhere

I just noticed a broken image link on wiki:/Help/Action/About and its translated pages. (No big deal to fix this by hand though. Just in case you want to investigate.)

Fixed with 1 and 2

Search for source links results in following remaining errors:

They are not easily fixed, but need updates of the texts.

comment:103 by simon04, 4 years ago

On Plugins, the yes/no icons are missing.

comment:104 by GerdP, 4 years ago

I've fixed the words.cfg problems

in reply to:  103 comment:105 by stoecker, 4 years ago

Replying to simon04:

On Plugins, the yes/no icons are missing.

Fixed.

in reply to:  104 comment:106 by stoecker, 4 years ago

Replying to GerdP:

I've fixed the words.cfg problems

Hmm, I was SURE this file was gone. Probably mass-edits after a long work-day are a bit sub-optimal :-)

comment:107 by GerdP, 4 years ago

It's still used in TagChecker

comment:108 by Don-vip, 4 years ago

In 16239/josm:

see #18845 - adapt relative paths in Windows installer scripts

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain team.
as The resolution will be set.
The resolution will be deleted. Next status will be 'reopened'.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.