Upload window is messed up (after Re-organization?)

[mdk]

What steps will reproduce the problem?

1. Open upload window after changes

What is the expected result?

Clean upload window with only one input field for imagery.

What happens instead?

Two imagery input fields.

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

When I open the upload window, I get:

When I change one imagery entry, the second input field vanish, but still some glitches:

When I resize the window, it looks fine:

But when I close and open the window again, I get the first version again.

Relative:URL: ^/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2021-04-09 23:18:01 +0200 (Fri, 09 Apr 2021)
Revision:17736
Build-Date:2021-04-10 01:30:58
URL:https://josm.openstreetmap.de/svn/trunk

Identification: JOSM/1.5 (17736 en) Linux Ubuntu 20.10
Memory Usage: 1149 MB / 1980 MB (158 MB allocated, but free)
Java version: 15+36-Ubuntu-1, Private Build, OpenJDK 64-Bit Server VM
Look and Feel: javax.swing.plaf.metal.MetalLookAndFeel
Screen: :0.0 3840×2160 (scaling 2.00×2.00)
Maximum Screen Size: 3840×2160
Best cursor sizes: 16×16→16×16, 32×32→32×32
Environment variable LANG: de_CH.UTF-8
System property file.encoding: UTF-8
System property sun.jnu.encoding: UTF-8
Desktop environment: ubuntu:GNOME
Java ATK Wrapper package: libatk-wrapper-java:all-0.38.0-1
libcommons-compress-java: libcommons-compress-java:all-1.20-1
libcommons-logging-java: libcommons-logging-java:all-1.2-2
fonts-noto: fonts-noto:all-20200323-1build1
VM arguments: [--add-modules=java.scripting,java.sql, -Djosm.restart=true, -Djosm.dir.name=JOSM-latest, -Djava.net.useSystemProxies=true]
Dataset consistency test: No problems found

Plugins:
+ FastDraw (35640)
+ HouseNumberTaggingTool (35640)
+ OpeningHoursEditor (35640)
+ RoadSigns (35640)
+ SimplifyArea (35640)
+ buildings_tools (35669)
+ contourmerge (v0.1.6)
+ imagery-xml-bounds (35723)
+ imagery_offset_db (35640)
+ pbf (35720)
+ poly (35640)
+ public_transport (35640)
+ reltoolbox (35640)
+ reverter (35732)
+ terracer (35640)
+ turnrestrictions (35640)
+ utilsplugin2 (35691)
+ wikipedia (1.1.4)

Tagging presets:
+ https://josm.openstreetmap.de/josmfile?page=Presets/OneClick&zip=1
+ https://josm.openstreetmap.de/josmfile?page=Presets/LaneAttributes&preset&zip=1

Map paint styles:
+ https://josm.openstreetmap.de/josmfile?page=Styles/Lane_and_Road_Attributes&zip=1
+ https://josm.openstreetmap.de/josmfile?page=Styles/Maxspeed&style&zip=1

[mdk]

Maybe a false report. After restarting JOSM, the problem is gone.

The problem just occur after updating. This was the first start after Ro-organizing the window. Perhaps reading and applying the old preferences for this window on the new layout cause this "confusion".

[skyper]

I had a problem with the slider in the middle of the divider but also only on first startup after upgrade.

[simon04]

Sorry, I cannot reproduce. Also tried setting org.openstreetmap.josm.gui.io.UploadDialog.geometry to the value prior to the re-organization...

Revision:17825
Is-Local-Build:true
Build-Date:2021-04-26 20:20:43

Identification: JOSM/1.5 (17825 SVN en) Mac OS X 11.2.3
OS Build number: macOS 11.2.3 (20D91)
Memory Usage: 260 MB / 2048 MB (86 MB allocated, but free)
Java version: 16+36, Azul Systems, Inc., OpenJDK 64-Bit Server VM
Look and Feel: javax.swing.plaf.metal.MetalLookAndFeel
Screen: Display 1 1440×900 (scaling 2.00×2.00) Display 2 3008×1692 (scaling 2.00×2.00)
Maximum Screen Size: 3008×1692
Best cursor sizes: 16×16→16×16, 32×32→32×32
Environment variable LANG: en_IE.UTF-8
System property file.encoding: UTF-8
System property sun.jnu.encoding: UTF-8
Locale info: en_AT
Numbers with default locale: 1234567890 -> 1234567890
Dataset consistency test: No problems found

org.openstreetmap.josm.gui.io.UploadDialog.geometry=x=0,y=0,width=600,height=600

[skyper]

Please, test it with an upgrade of preferences from tested to latest. I think this is a problem of the first startup with the new layout and previously created preferences.

[simon04]

I still cannot reproduce.

Relative:URL: ^/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2021-04-01 23:17:01 +0200 (Thu, 01 Apr 2021)
Revision:17702
Build-Date:2021-04-01 21:46:03
URL:https://josm.openstreetmap.de/svn/trunk

Identification: JOSM/1.5 (17702 en) Mac OS X 11.2
OS Build number: macOS 11.2.3 (20D91)
Memory Usage: 230 MB / 2048 MB (41 MB allocated, but free)
Java version: 16.0.1+9, AdoptOpenJDK, OpenJDK 64-Bit Server VM
Look and Feel: javax.swing.plaf.metal.MetalLookAndFeel
Screen: Display 1 1440×900 (scaling 2,00×2,00) Display 2 3008×1692 (scaling 2,00×2,00)
Maximum Screen Size: 3008×1692
Best cursor sizes: 16×16→16×16, 32×32→32×32
Environment variable LANG: en_IE.UTF-8
System property file.encoding: UTF-8
System property sun.jnu.encoding: UTF-8
VM arguments: [-Djosm.dir.name=JOSM.xxx]
Dataset consistency test: No problems found

Relative:URL: ^/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2021-04-25 09:16:28 +0200 (Sun, 25 Apr 2021)
Revision:17821
Build-Date:2021-04-26 01:31:00
URL:https://josm.openstreetmap.de/svn/trunk

Identification: JOSM/1.5 (17821 en) Mac OS X 11.2
OS Build number: macOS 11.2.3 (20D91)
Memory Usage: 190 MB / 2048 MB (91 MB allocated, but free)
Java version: 16.0.1+9, AdoptOpenJDK, OpenJDK 64-Bit Server VM
Look and Feel: javax.swing.plaf.metal.MetalLookAndFeel
Screen: Display 1 1440×900 (scaling 2.00×2.00) Display 2 3008×1692 (scaling 2.00×2.00)
Maximum Screen Size: 3008×1692
Best cursor sizes: 16×16→16×16, 32×32→32×32
Environment variable LANG: en_IE.UTF-8
System property file.encoding: UTF-8
System property sun.jnu.encoding: UTF-8
Locale info: en_AT
Numbers with default locale: 1234567890 -> 1234567890
VM arguments: [-Djosm.dir.name=JOSM.xxx]

[skyper]

Well, could be related to the OS and even Gnome or some lafs. Let's see if the release next week will lead to many tickets.

[richlv]

For the record, not seeing this with 17833 on a Mac.

[simon04]

Closing as irreproducible. Please reopen if the problem reoccurs and/or can be reproduced. Thanks!