Needs vertical scrollbar when deleting a lot of data

[naoliv]

I am trying to delete a lot of relations and I got a very tall screen that doesn't fit my screen (nor I can see the OK and other buttons):

We need a vertical scrollbar for cases like this.

JOSM:

URL:http://josm.openstreetmap.de/svn/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2016-01-08 10:43:21 +0100 (Fri, 08 Jan 2016)
Build-Date:2016-01-09 02:34:54
Revision:9345
Relative:URL: ^/trunk

Identification: JOSM/1.5 (9345 pt_BR) Linux Debian GNU/Linux unstable (sid)
Memory Usage: 2046 MB / 3641 MB (1504 MB allocated, but free)
Java version: 1.8.0_72-internal-b05, Oracle Corporation, OpenJDK 64-Bit Server VM
VM arguments: [-Dawt.useSystemAAFontSettings=on]
Dataset consistency test: No problems found

Plugins:
- AddrInterpolation (31772)
- Create_grid_of_ways (31772)
- FastDraw (31895)
- FixAddresses (31772)
- OpeningHoursEditor (31772)
- PicLayer (31895)
- SimplifyArea (31895)
- apache-commons (31895)
- buildings_tools (31895)
- download_along (31772)
- editgpx (31772)
- ejml (31895)
- geotools (31895)
- graphview (31895)
- jts (31772)
- log4j (31895)
- measurement (31895)
- merge-overlap (31772)
- opendata (31937)
- pdfimport (31895)
- photo_geotagging (31895)
- poly (31772)
- reverter (31926)
- tagging-preset-tester (31895)
- todo (29154)
- turnrestrictions (31895)
- undelete (31895)
- utilsplugin2 (31895)

[Don-vip]

or do not list such many items. Something like:

• 1
• 2
• 3
• ...
• 373
• 374
• 375

[simon04]

In 9473/josm:

fix #12343 - Display at most 20 primitives for some confirmation dialogs (e.g., deletion of relations)

[Don-vip]

In 9475/josm:

see #12343 - add unit test

[simon04]

Ticket #11042 has been marked as a duplicate of this ticket.

[anonymous]

Limuiting the lsit to 20 items is not the best solution. The content text of the dialog should better be auto scrollable (if its height does not fit the constrint set by the window container, allow the scrollbars to appear in that content part, so that the content part can be restricted.
It makes sense to display the full list (and still allow some fragments to be copy-pasted into some external text editor to allow managing and cheking the items one by one, after checking them). But truncating the text is not so helpful: when the dislog contains a confirmation, we cannot really decide if we can apply the change (deleting objects, or merging them) with just partial information, insufficient to decide. The decision will be "biased".

The alternative is to post the large text into a separate log pane in the interface, where the log will be scrollable: make sure when displaying the dialog that this will open the log pane, and allow the confirmation dialog to instruct the user to look at the complete text in the log pane.
Such generic log pane would have lot of uses, including to see some warning messages or debugging/tracing texts generated by tools/plugins.