Height adjustable panels (allow saving/locking of panel height persistently)

[dimazcor@…]

Hi!
Every run in JOSM have to adjust the height of panel plugins, which is inconvenient.
It would be great if it was possible to save user preferences.
​http://s.qip.ru/2049IHX.jpg

[Don-vip]

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

[aceman]

In ticket #8555 stoecker had this comment:
The problem is that these windows are permanently added and removed which makes saving height impossible. When you find a way how to keep the height even under such conditions, improvements are welcome.

[aceman]

In my use case, I only need some panels to have a fixed size (e.g. history) and I want all the others to be maxed out (fill in the height). I think that could work. Most panels would be automatically resized as today and only some would be locked.
The algorithm would look if some panels have fixed height, then lay them out and then add those that are not locked and adjust them automatically (as today). Yes, there is still the case of what happens if by accident all panels are fixed.
I propose in that case to resize all panels automatically to fill the vertical height (determined the surplus height (or missing height) and distribute to all panels proportionally). But still keep the wished height of all panels and obey them the next time any resizable panel becomes enabled.

As not all panels would be saved automatically, it would need new UI to allow the user to select which panels to lock. But there already is a toolbar of icons per panel where such a new action could be added.

[Don-vip]

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

[simon04]

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

[Klumbumbus]

Replying to aceman:

In ticket #8555 stoecker had this comment:
The problem is that these windows are permanently added and removed which makes saving height impossible. When you find a way how to keep the height even under such conditions, improvements are welcome.

I could imagine the implementation this way: When JOSM closes the height of all the panels is saved and at next launch the heights are restored. In case that a panel is missing after the restart (due to a plugin uninstallation) the available space could be allocated to the other panels.

[Don-vip]

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

[GerdP]

Replying to Klumbumbus:

I could imagine the implementation this way: When JOSM closes the height of all the panels is saved and at next launch the heights are restored. In case that a panel is missing after the restart (due to a plugin uninstallation) the available space could be allocated to the other panels.

edit: In case the screen resolution changed before the restart then the heights must be changed accordingly.

Sounds easy enough. Why wasn't it done so far? I'd also like to have this chage. The default layout is not good for a laptop with a rather small screen, so I also rearrange windows when I map with the laptop.

[smaprs]

Just to add a vote for it, I'd like much to have this possibility to auto-save panel heights, since having to adjust it again every new session sums an amount of time spent in all the sessions history. It would help much to jump directly into mapping. Thank you anyway for considering this.

[aceman]

This is not only once per session, but many times. E.g. when you check or try to upload a changeset and the validator results open in a panel, or the conflicts panel opens. Or when ju temporarily open e.g. Mapillary panel.
All of that may kill your setup and you need to tweak the heights anew.

[stoecker]

Replying to aceman:

This is not only once per session, but many times. E.g. when you check or try to upload a changeset and the validator results open in a panel, or the conflicts panel opens. Or when ju temporarily open e.g. Mapillary panel.
All of that may kill your setup and you need to tweak the heights anew.

As already said above it's impossible to keep the heights when the layout changes. To solve that you first need to propose a way. Klumbumbus solution is for an unchanged setup.

[GerdP]

In my typical work flow I don't see a change in the number of panels. I use the validator very often so that panel is always open.
My understanding is that #16980 wants to store the layout when you close JOSM and restore it when it is opened next. This sounds reasonable and easy enough.
Once JOSM is open the layout can change when panels are added, closed or minimized. In this case I'd prefer to keep the layout of the panel with the tags unless the user changes it explicitely because that is the most important for me, followed by the layers panel. Maybe other users prefer other panels, so I'd suggest to add an (expert) option to store this preference order.

BTW: Is there a way to suppress the icons for the presets in the tags panel? I never use them and rarely understand them. Up to now I only found an option to place them at the bottom of the list.

[anonymous]

"My understanding is that #16980 wants to store the layout when you close JOSM and restore it when it is opened next. This sounds reasonable and easy enough."

Exactly. For a beggining that would be good enough. If that could be done, auto-saving in the end of the session, a bunch of the times one has to reposition panel heights would be solved.

[stoecker]

Replying to GerdP:

In my typical work flow I don't see a change in the number of panels. I use the validator very often so that panel is always open.
My understanding is that #16980 wants to store the layout when you close JOSM and restore it when it is opened next. This sounds reasonable and easy enough.

I agree. Patches welcome. I'd store percentage instead of absolute values, so window size changes will survive.

Once JOSM is open the layout can change when panels are added, closed or minimized. In this case I'd prefer to keep the layout of the panel with the tags unless the user changes it explicitely because that is the most important for me, followed by the layers panel. Maybe other users prefer other panels, so I'd suggest to add an (expert) option to store this preference order.

Prefering a certain type is not good, but a better logic could try to keep the appearance as much as possible, which could improve situation in most cases, if not all. I.e. the largest one should stay large, empty space reduced first and similar things.

BTW: Is there a way to suppress the icons for the presets in the tags panel? I never use them and rarely understand them. Up to now I only found an option to place them at the bottom of the list.

No. Make a change adding expert
properties.presets.visable
and default it to true, then you can disable it for yourself :-)

What they are: These are the presets matching the current selection. That's a shortcut to the presets: if you want to find one for the current element you don't need to go through the menu.

[GerdP]

OK, I'll try to find a solution that works for me. If I find someting I'll post a patch here.

[aceman]

Replying to stoecker:

As already said above it's impossible to keep the heights when the layout changes. To solve that you first need to propose a way. Klumbumbus solution is for an unchanged setup.

I have described my idea of an algorithm in comment 4.

[smaprs]

Replying to anônimo:

Exactly...(Sorry, forgot to sign it - OSMuser:smaprs) PS: I don't know coding to help in patching it. If I knew certainly would help, that would benefit me too.

[GerdP]

In 14423/josm:

see #7561 comment 16
add new expert preference properties.presets.visable to hide preset icons in properties dialg

[Klumbumbus]

Please document new preference keys in the table at wiki:/Help/Preferences/Advanced#Explanation.
And the typo in "visable" should be fixed.

[GerdP]

Arg, it looked strange when I used copy+paste, but I did not see the typo.
I'll also correct the description for properties.presets.top.

[GerdP]

In 14424/josm:

see #7561 comment 21
Fix typo properties.presets.visable -> properties.presets.visible

[GerdP]

Please review and let me know if that is a good approach:
Each of the dialogs on the right side has a hard coded "preferred height". This value is used to calculate the real height in pixels when the real screen resolution and the wanted dialogs are known, means, the preferred height is scaled so that they fit.

7561_storeHeight.patch implements two ideas:
1a) When JOSM is closed or all layers are removed so that the "splash screen" is showed, the current height of each dialog is stored in the preferences file. The values are stored in preferencePrefix+".lastHeight".
1b) When JOSM is started or a first layer is opened, the previously stored values are restored.
2) The hard coded preferredHeight values are now also stored in preferencePrefix+".preferredHeight". The expert can change that value to a higher or lower value. When the sizes are refreshed because a dialog is added, removed or minimized the modified value is taken into account. With the current implementation the change is only taken into account when JOSM is stopped/started.

There are a few more points to look at, for example this doesn't work yet when you unlock a dialog.

[stoecker]

Sounds ok to me. Try it.

[GerdP]

OK, lock / unlock is only a problem in this case :
1) change the heights
2) unlock a dialog and close the unlocked version again so that the panel is added to the others again.
In this case the changes from 1) get lost and calculations are done based on the preferred height.
So, I think it works already quite good. I think I should commit it after removing the debug code so that users can test it?

Just a thought for a comfortable solution:
In Eclipse I can rearrange my dialogs and the position is stored on exit. I can also create different "Perspectives" and store them with a name. When I want to restore the factory settings I have an option Windows|Perspective|Reset Perspective.
Eclipse switches to the Debug perspective when I start to debug. Not sure if that would help here? We might introduce perspectives for validation or conflict resolution.

[stoecker]

... Perspectives...

Don't overdo it. We already have a state in JOSM where most users don't known the majority of functionality. No need to add other unknown functionality for a few. An automatic best guess approach is better.

[GerdP]

In 14425/josm:

see #7561 comment 24
slightly modified 7561_storeHeight.patch,

1a) When JOSM is closed or all layers are removed so that the "splash screen" is showed, the current height of each dialog is stored in the preferences file. The values are stored in preferencePrefix+".lastHeight".
1b) When JOSM is started or a first layer is opened, the previously stored values are restored.
2) The hard coded preferredHeight values are now also stored in preferencePrefix+".preferredHeight". The expert can change that value to a higher or lower value. When the sizes are refreshed because a dialog is added, removed or minimized the modified value is taken into account. With the current implementation the change is only taken into account when JOSM is stopped/started.

[GerdP]

Please test version 14425 or later and let me know if this works for you. If yes, I'll try to add documentation in the wiki.

[stoecker]

Hmm, you forgot the @since for new public functions :-)

[GerdP]

Done with r14426. This time I forgot to add the ref to trac in the commit message ;-)

[stoecker]

Replying to GerdP:

Done with r14426. This time I forgot to add the ref to trac in the commit message ;-)

To make Vincent happy: :-)

​https://stackoverflow.com/questions/304383/how-to-edit-log-message-already-committed-in-subversion

[GerdP]

In 14426/josm:

see #7561 comment 30 add javadoc @since to new public methods and new enum

[Don-vip]

Replying to stoecker:

To make Vincent happy: :-)

Thanks! :)

[Klumbumbus]

Works fine for me.

[smaprs]

Thank you much! I've tested the latest version josm-latest.jar 14444 and it saves all the default panels heights and widths for the next session (Windows 7)! That's really great, it eases a lot, thanks!