[patch] Autoresize Tags/Memberships table to fit content?

[bagage]

What steps will reproduce the problem?

1. Select a node/way that has a long value for any key (let's say for "source" attribute)

What is the expected result?

You can see list of keys/values.

What happens instead?

You can see all keys easily but longer values are not visible even if there is a lot of space available. Because the table splits width 50%/50% between the 2 columns.

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

It would be awesome if the table could be automatically resized so that the first column (keys)'s width matched the biggest one, leaving all remaining width for values which may (usually) be bigger than keys anyway.

Build-Date:2017-04-10 14:26:00
Revision:11883
Is-Local-Build:true

Identification: JOSM/1.5 (11883 SVN en) Linux Debian GNU/Linux 9.0 (stretch)
Memory Usage: 983 MB / 1760 MB (372 MB allocated, but free)
Java version: 1.8.0_121-8u121-b13-4-b13, Oracle Corporation, OpenJDK 64-Bit Server VM
Screen: :0.0 1920x1080
Maximum Screen Size: 1920x1080
Java package: openjdk-8-jre:amd64-8u121-b13-4
Java ATK Wrapper package: libatk-wrapper-java:all-0.33.3-13
Program arguments: [--language=en, ${HOME}/majcadastre/CL322-SAINT-PANTALEON-LES-VIGNES/CL322-SAINT-PANTALEON-LES-VIGNES-houses-prediction_segmente.osm, ${HOME}/majcadastre/CL322-SAINT-PANTALEON-LES-VIGNES/CL322-SAINT-PANTALEON-LES-VIGNES-houses-simplifie.osm]
Dataset consistency test: No problems found

Plugins:
+ OpeningHoursEditor (33185)
+ PicLayer (33148)
+ buildings_tools (33004)
+ conflation (0.5.3)
+ jts (32699)
+ rex (26)
+ todo (30000)
+ utilsplugin2 (33212)

Last errors/warnings:
- W: No configuration settings found.  Using hardcoded default values for all pools.
- W: Old style SideButton usage for action org.openstreetmap.josm.plugins.todo.TodoDialog$SelectAction@49a746c2
- W: Old style SideButton usage for action org.openstreetmap.josm.plugins.todo.TodoDialog$AddAction@7c630f15
- W: Old style SideButton usage for action org.openstreetmap.josm.plugins.todo.TodoDialog$PassAction@261cc5f4
- W: Old style SideButton usage for action org.openstreetmap.josm.plugins.todo.TodoDialog$MarkAction@6fbf9f8e
- W: Old style SideButton usage for action org.openstreetmap.josm.plugins.todo.TodoDialog$MarkSelectedAction@21039601

[bagage]

screenshot of the issue

[bagage]

patch proposal

[bagage]

Hello,

Here's an attempt to fix that issue by using TableColumnAdapter class found here (license: "use at your own risk"): ​https://tips4java.wordpress.com/2008/11/10/table-column-adjuster/

Everytime tags table data changes (eg when selection changes), columns width is recomputed so that "tag" column is the minimal size while beeing totally displayed.

[bagage]

Hello, anynews on that one?

[Don-vip]

That's a lot of code, I'm not convinced we need this full class. Can you please check if ​https://stackoverflow.com/a/17627497/2257172 is enough?

[bagage]

patch version 2 (simplified version)

[bagage]

Here's a simplified version which recompute tables width on selection change so that it always fit content as effective as possible. Does it look OK?

[Don-vip]

looks much better! I will review it later (beginning of next week likely)

[Don-vip]

We already have org.openstreetmap.josm.gui.util.TableHelper.adjustColumnWidth.

Can you please check is it can be reused? Otherwise your new method could maybe replace it.

[anonymous]

Oh indeed, I didn't know it was here. I added another method TableHelper.computeColumnsWidth which uses adjustColumnWidth, I did not modify the code that used it because I'm not sure how to test it.

[bagage]

patch version 3

[bagage]

patch version 3

[Don-vip]

In 14476/josm:

fix #14666 - Autoresize Tags/Memberships table to fit content (patch by bagage)

[Don-vip]

Thanks! :)

[Klumbumbus]

I think this needs some more fine tuning. E.g. load ​https://www.openstreetmap.org/way/360601777 and select it which results in this view:

• The key column is unnecessary wide (no long key) which hides the values column.
• Even if there is a long key or a long relation membership I think the other columns should be displayed anyway. I.e. I would like to always see the value, role and position columns without the need to scoll horizontally.

URL:https://josm.openstreetmap.de/svn/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2018-12-09 02:19:41 +0100 (Sun, 09 Dec 2018)
Build-Date:2018-12-09 02:32:25
Revision:14530
Relative:URL: ^/trunk

Identification: JOSM/1.5 (14530 en) Windows 10 64-Bit
OS Build number: Windows 10 Pro 1803 (17134)
Memory Usage: 1374 MB / 1820 MB (998 MB allocated, but free)
Java version: 1.8.0_191-b12, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM
Screen: \Display0 1680x1050
Maximum Screen Size: 1680x1050
VM arguments: [-Djava.security.manager, -Djava.security.policy=file:<java.home>\lib\security\javaws.policy, -DtrustProxy=true, -Djnlpx.home=<java.home>\bin, -Djnlpx.origFilenameArg=%UserProfile%\Desktop\josm-latest.jnlp, -Djnlpx.remove=false, -Djava.util.Arrays.useLegacyMergeSort=true, -Djnlpx.heapsize=NULL,2048m, -Djnlpx.splashport=49247, -Djnlpx.jvm=<java.home>\bin\javaw.exe]
Dataset consistency test: No problems found

[bagage]

Indeed there seems to be a bug when computing the width of columns, I'll take a look.

Regarding the second issue (all columns being always displayed), I think we might be able to work around it by setting different values for minWidth and preferredWidth. I'll look at that too.

Thanks!

[Don-vip]

@bagage With the holidays, do you think you can take a look before the end of the month?

[bagage]

I cannot say it for sure, but I hope so. Or if you prefer, maybe revert it and I'll redo it totally?

[bagage]

I took a moment to look at that - The first point can be fixed.

However it looks like "Even if there is a long key or a long relation membership I think the other columns should be displayed anyway." is not an easy thing doable with Swing (at least at my level). So either:

1) only tags/values table should be automatically resized.
2) revert the patch
3) add an option in settings to let user choose what behavior is best for him

I think 1) is what makes the most sense, since tags are supposed to be short and concise compared with relations' name.

What do you think?

[Don-vip]

+1 for 1 :)

[GerdP]

Yes, 1) sounds good.

[bagage]

patch to fix size issue

[bagage]

I've attached a patch to disable the resize of membership table. It will actually solve point 1, because currently both tables share the same width: when membership table becomes huge (for instance due to long relation's name + autoresizing), it will also increase tag/value table's width, which makes it unnecessary wide.

[Don-vip]

In 14613/josm:

fix #14666 - Do not resize membership table (patch by bagage)

[johnparis]

I greatly prefer the old behavior. Now the column widths change constantly, and worse, when they go beyond the width of the window, I am constantly having to scroll right and left to see anything!

Can a preference option be set to disable this behavior? Or at the very least, never overflow the window?

Thanks.

[anonymous]

@johnparis what do you mean by "column widths go beyond the width of the window"?

If a key is very wide, indeed you'll have to scroll to see the associated value. But I think there are no much wide key, am I wrong?

If a value is very wide, indeed the table will be horizontally scrollable to see the whole value, but it's equivalent to the older version behavior where the end of the value would be truncated, isn't it? At least you can now scroll horizontally to see the end of it. Thus I don't see the point behind "never overflow the window", I'd be happy to know why this is important/better for you (different setup maybe?).

BTW thanks for the feedback :)

[Don-vip]

Replying to anonyme:

If a value is very wide, indeed the table will be horizontally scrollable to see the whole value, but it's equivalent to the older version behavior where the end of the value would be truncated, isn't it? At least you can now scroll horizontally to see the end of it. Thus I don't see the point behind "never overflow the window", I'd be happy to know why this is important/better for you (different setup maybe?).

bagage speaking I assume?

Some reasons:

• Horizontal scrollbar is a poor UI: in small dialogs like this it takes a lot of vertical space for limited added value
• Human brain can often guess the hidden part without having to scroll
• It's ugly :)
• People simply don't like change, don't forget ;)

I think we should indeed avoid horizontal scrollbars. If you can come up with a solution... :)

[johnparis]

screen shot of keys not being fully visible

[johnparis]

Don-vip's second point is the most important to me ...

• Human brain can often guess the hidden part without having to scroll

Reason: I need to always see all the keys (left-aligned) at a glance. I don't really care what the values are, so long as they meet certain criteria, which I can tell from just seeing a few characters.

However, with the new UI, the keys often are off the screen, just leaving the values. Also, because they auto-resize, it is very annoying because the ratio between key and value real estate is constantly shifting (points 3 and 4 from Don-vip).

[bagage]

patch: add settings option to disable autoresize

[bagage]

Here's a patch to add propertiesdialog.autoresizeTagsTable option, which defaults is enabled but can be disabled to restore previous state.

Regarding the horizontal scrollbar, it does not seem easily doable without too much code :-(.

[Don-vip]

Thanks. I will apply it but being disabled by default. It will give us time to find a solution to avoid horizontal scroll.

[Don-vip]

In 14677/josm:

see #14666 - add propertiesdialog.autoresizeTagsTable option, disabled by default (patch by bagage)

[bagage]

Sounds good, thanks Don-vip :)

[Roadsguy]

Has that patch made it into stable version 14760 released today? I don't see a setting by that name in the advanced preferences.

[GerdP]

Yes, I see it when I search for propertiesdialog.autoresizeTagsTable in the dialog. You will not find it in the preferences.xml unless you change it.

[Roadsguy]

Huh, I see it now. I must have been typing it wrong... Thanks!