[patch] Inconsistent notification position

[gaben]

What steps will reproduce the problem?

1. Do something which produces a notification (upload, tool error etc.)
2. Pay attention of the notification position
3. Repeat steps 1-2 with full screen mode

What is the expected result?

Notification position is consistent among viewing modes.

What happens instead?

Full screen messes up the notifications position and also in normal mode the position is a bit off.

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

Revision:18750
Is-Local-Build:true
Build-Date:2023-06-11 16:13:37

Identification: JOSM/1.5 (18750 SVN en) Linux Ubuntu 20.04.6 LTS
Memory Usage: 236 MB / 2480 MB (75 MB allocated, but free)
Java version: 11.0.19+7-post-Ubuntu-0ubuntu120.04.1, Ubuntu, OpenJDK 64-Bit Server VM
Look and Feel: javax.swing.plaf.metal.MetalLookAndFeel
Screen: :0.0 1918×1020 (scaling 1.00×1.00)
Maximum Screen Size: 1918×1020
Best cursor sizes: 16×16→16×16, 32×32→32×32
Environment variable LANG: hu_HU.UTF-8
System property file.encoding: UTF-8
System property sun.jnu.encoding: UTF-8
Locale info: en_HU
Numbers with default locale: 1234567890 -> 1234567890
Desktop environment: ubuntu:GNOME
Java package: openjdk-11-jre:amd64-11.0.19+7~us1-0ubuntu1~20.04.1
Java ATK Wrapper package: libatk-wrapper-java:all-0.37.1-1
fonts-noto: fonts-noto:-
VM arguments: [-Dfile.encoding=UTF-8]
Program arguments: [--debug, ${HOME}/Letöltések/Teleki_cycle.osm.gz]
Dataset consistency test: No problems found

Plugins:
+ utilsplugin2 (36079)

Validator rules:
+ https://josm.openstreetmap.de/josmfile?page=Rules/Runways&zip=1

[gaben]

fix gif position

[gaben]

Just noticed #22751 which can mess up the positions (therefore this patch) a little bit.

[taylor.smock]

I just merged #22751. Let me know if/when you've checked to make certain it hasn't borked your patch.

[gaben]

It did, completely.

Honestly, I've spent too much time on this and it's going nowhere.

Edit: It does affect Linux when the notification has more than one line (as on the animation).

[taylor.smock]

Replying to gaben:

It did, completely.

Sorry about that.

Honestly, I've spent too much time on this and it's going nowhere.

The hard part will be figuring out how to test it so that we don't regress.

[gaben]

No probs, it happens.

So if you set notification's y-axis via y = mapViewPos.y here source:josm/trunk/src/org/openstreetmap/josm/gui/NotificationManager.java?rev=18763#L143​, it should show up touching the map view's top.

Instead, this is what you get after applying #22751:

[gaben]

There is a visual debugger, that may help ​https://netbeans.apache.org/kb/docs/java/debug-visual.html

Unfortunately, I wasn't able to get JOSM run in Netbeans :(

[gaben]

I'm uploading the new patch next week.

[gaben]

The patch is bigger than expected, due to the findings along the way.

First of all, the notification position was computed in the main frame's coordinate system, while the panel goes into the frame's layered pane. The two differ by the window decoration insets, which are only there outside fullscreen mode, hence the different spot depending on whether the window is fullscreen. It is now computed against the container the panel is actually added to, and recomputed while the notification is up, so it also follows window resizes and layout changes.

Also fixed along the way:

• a deadlock, when a notification is shown from a worker thread
• an NPE in mouseEntered() after the panel was removed
• the hide timer restarted by the mouse exit event of that very panel
• duplicates queued again, unless they matched the last queued notification
• the same message dropped as a duplicate when triggered right after it disappeared
• replacing a notification hiding an unrelated one
• a notification left sitting over the status line, when a layer is opened while it is up
• an antialiasing hint leaking out of RoundedPanel
• the close button and the panel margin ignoring the interface scale, and
• long notifications starting above the top of the window.

NotificationManagerTest covers most of these.

[gaben]

Oh I didn't know Trac can autoversion the uploads.

Anyway, testers needed! :)

In my own testing, it worked perfectly on both Windows and Linux.

[stoecker]

I'd say: Do checkin.

[gaben]

One remark: the Wikipedia plugin has a large icon (128*128 pixels [added by me years ago]) and when this is displayed, the notification becomes huge to accommodate the icon. This is the current behaviour, both with and without the patch, so there is no fix yet.

[stoecker]

Simply reduce the maximum icon size?

[gaben]

I'd like a proper fix because I'm switching to 4K soon and I prefer high resolution :)

Looking into it now and will commit once I've found a solution.

[stoecker]

We have an IconSizes class, which should allow to change sizes for higher DPI at a single place. Restricting size with this class should be a proper solution.

[gaben]

In 19643/josm:

fix #23002 - keep notifications aligned to the map view

• follow the map view on fullscreen toggle, maximize and other layout changes
• scale down icons larger than ImageSizes.NOTIFICATION (new, 32px)
• fix a possible deadlock when a notification is shown from a worker thread
• drop duplicates anywhere in the queue, not only the last one
• remove the transparent margins that blocked clicks on the map

[gaben]

Compared to the patch:

• I found out that the border wasn't exactly as specified in the code, so I fixed it.
• ImageSizes.NOTIFICATION was added to the ImageProvider.

I also tried mocking, but reflection based tests are faster and still catch the issues.

Hopefully nobody will have to touch these classes for 10 years.