Modify

Opened 7 years ago

Closed 5 years ago

Last modified 5 years 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 7 years ago.
screenshot of the issue
0001-Key-column-minimal-possile-width.patch (16.3 KB ) - added by bagage 7 years ago.
patch proposal
0002-Automatically-recompute-tags-and-membership-tables-c.patch (2.2 KB ) - added by bagage 5 years ago.
patch version 2 (simplified version)
0002-Automatically-recompute-tags-and-membership-tables-c.2.patch (2.2 KB ) - added by bagage 5 years ago.
patch version 3
Add_TableHelper_computeColumnsWidth_helper_and_use_it_for_tags_and_membership_tables.patch (3.1 KB ) - added by bagage 5 years ago.
patch version 3
14666a.png (10.3 KB ) - added by Klumbumbus 5 years ago.
Do_not_resize_membership_table.patch (1.2 KB ) - added by bagage 5 years ago.
patch to fix size issue
Screenshot from 2019-01-08 01-13-19.png (124.1 KB ) - added by johnparis 5 years ago.
screen shot of keys not being fully visible
Add_propertiesdialog_autoresizeTagTable_option_to_disable_autoresize1.patch (2.5 KB ) - added by bagage 5 years ago.
patch: add settings option to disable autoresize

Download all attachments as: .zip

Change History (41)

by bagage, 7 years ago

Attachment: poc2.png added

screenshot of the issue

comment:1 by bagage, 7 years ago

Description: modified (diff)

comment:2 by skyper, 7 years ago

Description: modified (diff)

by bagage, 7 years ago

patch proposal

comment:3 by bagage, 7 years ago

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 by Klumbumbus, 7 years ago

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

comment:5 by bagage, 5 years ago

Hello, anynews on that one?

comment:6 by Don-vip, 5 years ago

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?

by bagage, 5 years ago

patch version 2 (simplified version)

comment:7 by bagage, 5 years ago

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?

Version 0, edited 5 years ago by bagage (next)

comment:8 by Don-vip, 5 years ago

Milestone: 18.11
Type: defectenhancement

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

comment:9 by Don-vip, 5 years ago

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 by anonymous, 5 years ago

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.

comment:11 by Don-vip, 5 years ago

Resolution: fixed
Status: newclosed

In 14476/josm:

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

comment:12 by Don-vip, 5 years ago

Thanks! :)

comment:13 by Klumbumbus, 5 years ago

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 5 years ago by Klumbumbus (previous) (diff)

by Klumbumbus, 5 years ago

Attachment: 14666a.png added

comment:14 by bagage, 5 years ago

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 by Don-vip, 5 years ago

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

comment:16 by bagage, 5 years ago

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 by bagage, 5 years ago

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 by Don-vip, 5 years ago

+1 for 1 :)

comment:19 by GerdP, 5 years ago

Yes, 1) sounds good.

by bagage, 5 years ago

patch to fix size issue

comment:20 by bagage, 5 years ago

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 by Don-vip, 5 years ago

Resolution: fixed
Status: reopenedclosed

In 14613/josm:

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

comment:22 by johnparis, 5 years ago

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 by anonymous, 5 years ago

@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 :)

in reply to:  23 comment:24 by Don-vip, 5 years ago

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... :)

by johnparis, 5 years ago

screen shot of keys not being fully visible

comment:25 by johnparis, 5 years ago

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 5 years ago by johnparis (previous) (diff)

by bagage, 5 years ago

patch: add settings option to disable autoresize

comment:26 by bagage, 5 years ago

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 5 years ago by Don-vip (previous) (diff)

comment:27 by Don-vip, 5 years ago

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 by Don-vip, 5 years ago

In 14677/josm:

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

comment:29 by bagage, 5 years ago

Sounds good, thanks Don-vip :)

comment:30 by Roadsguy, 5 years ago

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

comment:31 by GerdP, 5 years ago

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.

comment:32 by Roadsguy, 5 years ago

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

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.