TextEdits should not resize on tag dialog resize

[Larry0ua]

Actually there are two bugs at the same place.

1. Open josm, load some area, select an object, call new tag dialog.
2. Change dialog height - see that the text edit boxes are resized vertically and look weird. (see screenshot 1)

Another scenario:

1. Run josm in debug mode, select an object, call new tag dialog.
2. On my system default dialog is less than it should be and edit boxes are not capable to show the text. (see screenshot 2)

[Larry0ua]

Regarding the debug mode - I am not sure if it is reproducible outside of my env, but still there could be something wrong with default dialog size values or like that.

[stoecker]

The second one seems to be a bug of your Look&Feel, doesn't happen on mine. The first is simple. The text boxes are the only resizable elements. :-)

[Larry0ua]

I believe it could be. Anyway for those who starts josm with debug it should not be an issue.

[Don-vip]

Can you please attach your status report?

[Larry0ua]

As for item 2 - today it reproduced on both debug and non-debug only when jvisualvm was started (even not connected). So I believe it interferes with some behavior in java swing apps... or not. Anyway, if no one can reproduce the same behavior on their Win8.1 with Java8, it's ok.

[mdk]

See also #11254, which is about using a too small hight for the dialog. I'm also a victim, that some times all dialogs have too low height and some times everything is fine. I'm also using Ubuntu 14.10.
Perhaps this has to do with some kind of automatic placement of new windows / dialogs. Normally new windows are placed with a little offset lower and more left than the last dialog. BTW: Is this a feature of Java or from the windows management of Linux?.
On the other hand JOSM try to remember dialog positions and size for next usage (as far as I understand). Perhaps this methods interact, so that the dialogs get lower and lower up to the point where the TextEdits has height 0.

[Larry0ua]

Now when I look at them thoroughly, I see that the same dialog may have different height when called multiple times in a row (like repeating alt+a, esc). However, screenshot like in #11254 I've never seen yet locally.

Debugging this thing requires more knowledge of swing, GridBag and other stuff of that area, which I (un)fortunately don't know :)

[mdk]

I don't know the details too. Actually I was not able to reproduce too low dialogs.
But I found an interesting detail: The "Add" Dialog ("Add value?") scales the TextEdit height. But the "Edit" ("change value?") has the same TextEdits for key and value, but with constant height. At least this should be unified!

[mdk]

Looking into the code:
Tag "Add" and "Edit" Dialog based on TagEditHelper.AbstractTagsDialog.

In EditTagDialog.setupDialog() a default size is calculated (in the super class ExtendedDialog) and used for

getSize() == getMinimumSize() == getPrefferedSize() == java.awt.Dimension[width=325,height=204]

This size is also stored as defaultWindowGeometry in the dialog (but not written to Prefs-file):

setRememberWindowGeometry({topLeft=java.awt.Point[x=833,y=436],extent=java.awt.Dimension[width=325,height=204]})

in AbstractTagsDialog.setVisible() the geometry is read from Prefs-file:

initWindowGeometry(pref=org.openstreetmap.josm.gui.dialogs.properties.TagEditHelper$EditTagDialog.geometry, 
   defaultWindowGeometry={topLeft=java.awt.Point[x=833,y=436],extent=java.awt.Dimension[width=325,height=204]})

(in my case) with the result from Prefs-file:

setVisible().storedSize=java.awt.Dimension[width=1437,height=204]

because actual size (which is the calculated default size)

setVisible().size=java.awt.Dimension[width=325,height=204]

and size in Prefs-file are different, a new resulting size will be calculated (simplified code):

storedSize.width = max(size.width, storedSize.width);
storedSize.height = size.height;

Even if nothing changes in this case, the "new" (unchanged) value is physically stored in the prefs file:

rememberWindowGeometry(pref=org.openstreetmap.josm.gui.dialogs.properties.TagEditHelper$EditTagDialog.geometry,
   geometry=WindowGeometry{topLeft=java.awt.Point[x=85,y=56],extent=java.awt.Dimension[width=1437,height=204]})

Now we reach the point where the dialog really should be shown, but instead of using all the stuff before, the size is read again from Prefs-file:

initWindowGeometry(pref=org.openstreetmap.josm.gui.dialogs.properties.TagEditHelper$EditTagDialog.geometry)
   defaultWindowGeometry={topLeft=java.awt.Point[x=833,y=436],extent=java.awt.Dimension[width=325,height=204]})

which results in java.awt.Dimension[width=1437,height=204]

When the dialog is closed, the possibly changed geometry is always stored again (even if the user has nothing changed):

rememberWindowGeometry(pref=org.openstreetmap.josm.gui.dialogs.properties.TagEditHelper$EditTagDialog.geometry,
   geometry=WindowGeometry{topLeft=java.awt.Point[x=85,y=56],extent=java.awt.Dimension[width=1437,height=204]})

Besides the unnecessary complex way of calculating the dialog dimensions, I didn't found the reason for too low dialogs, which I had often in the past, but can't reproduce right now.

But if the calculations done in ExtendedDialog.setupDialog() may result (depending of the Java version and/or the OS / Windowsmanager) in different heights, this value will override the stored value in Prefs-file all the time. If the re-calculated hight is some how a little bit smaller then the last time, this could explain the successively lowering of all dialogs, which I observed in the past. I found a JVM bug description which would match all my observed problems except of it's for the wrong Java version: ​https://bugs.openjdk.java.net/browse/JDK-8073710

A general question: Is there a single build server for JOSM or does different developers generate latest builds and load them up? If so, does all these developers are using the same Java version? If not, this could explain why I got the problem on some days and have no problems on other days (I automatically update to JOSM-latest every day).

[Don-vip]

Closed as duplicate of #11384.
Replying to mdk:

Looking into the code:

Thanks for this analysis, I'll use it to investigate this bug in #11384 course.

A general question: Is there a single build server for JOSM or does different developers generate latest builds and load them up? If so, does all these developers are using the same Java version? If not, this could explain why I got the problem on some days and have no problems on other days (I automatically update to JOSM-latest every day).

All developers use their own setup.