Modify

Opened 21 months ago

Closed 3 weeks ago

Last modified 7 days ago

#14666 closed enhancement (fixed)

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

Reported by: bagage Owned by: team
Priority: normal Milestone: 18.12
Component: Core Version:
Keywords: template_report Cc:

Description (last modified by skyper)

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.

screenshot of the issue

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

Attachments (9)

poc2.png (47.9 KB) - added by bagage 21 months ago.
screenshot of the issue
0001-Key-column-minimal-possile-width.patch (16.3 KB) - added by bagage 17 months ago.
patch proposal
0002-Automatically-recompute-tags-and-membership-tables-c.patch (2.2 KB) - added by bagage 2 months ago.
patch version 2 (simplified version)
0002-Automatically-recompute-tags-and-membership-tables-c.2.patch (2.2 KB) - added by bagage 7 weeks ago.
patch version 3
Add_TableHelper_computeColumnsWidth_helper_and_use_it_for_tags_and_membership_tables.patch (3.1 KB) - added by bagage 7 weeks ago.
patch version 3
14666a.png (10.3 KB) - added by Klumbumbus 6 weeks ago.
Do_not_resize_membership_table.patch (1.2 KB) - added by bagage 3 weeks ago.
patch to fix size issue
Screenshot from 2019-01-08 01-13-19.png (124.1 KB) - added by johnparis 11 days ago.
screen shot of keys not being fully visible
Add_propertiesdialog_autoresizeTagTable_option_to_disable_autoresize1.patch (2.5 KB) - added by bagage 7 days ago.
patch: add settings option to disable autoresize

Download all attachments as: .zip

Change History (38)

Changed 21 months ago by bagage

Attachment: poc2.png added

screenshot of the issue

comment:1 Changed 21 months ago by bagage

Description: modified (diff)

comment:2 Changed 21 months ago by skyper

Description: modified (diff)

Changed 17 months ago by bagage

patch proposal

comment:3 Changed 17 months ago by 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.

comment:4 Changed 17 months ago by Klumbumbus

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

comment:5 Changed 2 months ago by bagage

Hello, anynews on that one?

comment:6 Changed 2 months ago by 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?

Changed 2 months ago by bagage

patch version 2 (simplified version)

comment:7 Changed 2 months ago by bagage

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

Last edited 2 months ago by bagage (previous) (diff)

comment:8 Changed 2 months ago by Don-vip

Milestone: 18.11
Type: defectenhancement

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

comment:9 Changed 8 weeks ago by Don-vip

Milestone: 18.1118.12

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.

comment:10 Changed 7 weeks ago by 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.

Changed 7 weeks ago by bagage

patch version 3

comment:11 Changed 7 weeks ago by Don-vip

Resolution: fixed
Status: newclosed

In 14476/josm:

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

comment:12 Changed 7 weeks ago by Don-vip

Thanks! :)

comment:13 Changed 6 weeks ago by Klumbumbus

Resolution: fixed
Status: closedreopened

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
Last edited 6 weeks ago by Klumbumbus (previous) (diff)

Changed 6 weeks ago by Klumbumbus

Attachment: 14666a.png added

comment:14 Changed 5 weeks ago by 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!

comment:15 Changed 4 weeks ago by Don-vip

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

comment:16 Changed 4 weeks ago by bagage

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

comment:17 Changed 4 weeks ago by 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?

comment:18 Changed 4 weeks ago by Don-vip

+1 for 1 :)

comment:19 Changed 4 weeks ago by GerdP

Yes, 1) sounds good.

Changed 3 weeks ago by bagage

patch to fix size issue

comment:20 Changed 3 weeks ago by 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.

comment:21 Changed 3 weeks ago by Don-vip

Resolution: fixed
Status: reopenedclosed

In 14613/josm:

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

comment:22 Changed 2 weeks ago by 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.

comment:23 Changed 12 days ago by 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 :)

comment:24 in reply to:  23 Changed 11 days ago by 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... :)

Changed 11 days ago by johnparis

screen shot of keys not being fully visible

comment:25 Changed 11 days ago by 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).


Last edited 11 days ago by johnparis (previous) (diff)

Changed 7 days ago by bagage

patch: add settings option to disable autoresize

comment:26 Changed 7 days ago by 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 :-(.

Last edited 7 days ago by Don-vip (previous) (diff)

comment:27 Changed 7 days ago by 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.

comment:28 Changed 7 days ago by Don-vip

In 14677/josm:

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

comment:29 Changed 7 days ago by bagage

Sounds good, thanks Don-vip :)

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.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.