Preferences changeListener broken, triggered multiple times when switching to a net-yet-created pref tab

[xeen]

I added debug output to the plugin prefs because the plugin list was loaded twice when switching to the tab and then again when navigation away from it. It only adds one change listener, so the problem is "further up".

Adding listener
Selected paneNo : 3
Selected paneNo : 4
Selected paneNo : 3
Selected paneNo : 3

Selected paneNo : 2
Selected paneNo : 3
Selected paneNo : 2
Selected paneNo : 2

Selected paneNo : 1
Selected paneNo : 2
Selected paneNo : 1
Selected paneNo : 1

I added the newlines for readability, each block is executed when switching the tab. The order is 3, 2, 1 with 3 being the plugins tab and none of the tabs having been loaded so far. After that, it works as expected:

Selected paneNo : 3
Selected paneNo : 2
Selected paneNo : 1

Probably broke due to the work in r4968, r4969 and r4970.

[Don-vip]

In 5117/josm:

see #7541 - Plugins list built only at first tab selection

[Don-vip]

How did you add your debug code ? I have fixed the problem with plugins list but I'm not sure there is not a remaining problem in change events.

[xeen]

I added it in stateChanged method in PluginPreferenceActivationListener. Your patch fixes the problem, but the superfluous change events remain.

I did a quick check and it appears the plugin pref is the only plugin listening for tab switch to find out it’s been activated. Given that now each tab is only generated after it has been selected, wouldn’t it be better to simply remove the listener and comment-in the line you commented out in r5117? This doesn’t fix the superfluous events, but since we don’t actually care anymore about them…

[xeen]

I haven’t checked the history of the pref plugins… but do we actually need to re-read the local plugin data on tab switch? Before r5117 they would be read on every "show", now only once. I don’t know about before that, though.

[xeen]

This works for me. Plugin list is only loaded once and properly displayed. The progress bar probably needs to be reworked though since it hides even when the list is still being rendered. This patch only applies if it’s enough to read the plugin data once.

[Don-vip]

Much nicer :) Note the second call to refreshView() is not even needed. I commit it with another patch to keep scrollbar position when we really refresh the list by clicking the Download button.

[Don-vip]

In 5120/josm:

fix #7541 - clean plugin list initialization + keep scrollbar position when refreshing the list