Modify

Opened 12 years ago

Closed 5 years ago

#7561 closed enhancement (fixed)

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

Reported by: dimazcor@… Owned by: team
Priority: normal Milestone: 18.11
Component: Core Version: tested
Keywords: Cc: smarties, pegeka, smaprs, Klumbumbus

Description

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

Attachments (1)

7561_storeHeight.patch (3.8 KB ) - added by GerdP 5 years ago.

Download all attachments as: .zip

Change History (39)

comment:1 by Don-vip, 10 years ago

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

comment:2 by Don-vip, 10 years ago

Cc: smarties added

comment:3 by aceman, 10 years ago

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.

comment:4 by aceman, 10 years ago

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

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.

comment:5 by Don-vip, 8 years ago

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

comment:6 by simon04, 7 years ago

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

comment:7 by simon04, 7 years ago

Cc: pegeka smaprs Klumbumbus added

in reply to:  3 ; comment:8 by Klumbumbus, 7 years ago

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.

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

Last edited 7 years ago by Klumbumbus (previous) (diff)

comment:9 by Don-vip, 5 years ago

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

in reply to:  8 comment:10 by GerdP, 5 years ago

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.

comment:11 by smaprs, 5 years ago

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.

comment:12 by aceman, 5 years ago

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.

in reply to:  12 ; comment:13 by stoecker, 5 years ago

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.

comment:14 by GerdP, 5 years ago

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.

comment:15 by anonymous, 5 years ago

"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.

in reply to:  14 comment:16 by stoecker, 5 years ago

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.

comment:17 by GerdP, 5 years ago

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

in reply to:  13 comment:18 by aceman, 5 years ago

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.

in reply to:  15 comment:19 by smaprs, 5 years ago

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.

comment:20 by GerdP, 5 years ago

In 14423/josm:

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

comment:21 by Klumbumbus, 5 years ago

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

comment:22 by GerdP, 5 years ago

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.

comment:23 by GerdP, 5 years ago

In 14424/josm:

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

by GerdP, 5 years ago

Attachment: 7561_storeHeight.patch added

comment:24 by GerdP, 5 years ago

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.

comment:25 by stoecker, 5 years ago

Sounds ok to me. Try it.

comment:26 by GerdP, 5 years ago

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.

comment:27 by stoecker, 5 years ago

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

comment:28 by GerdP, 5 years ago

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.

comment:29 by GerdP, 5 years ago

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.

comment:30 by stoecker, 5 years ago

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

comment:31 by GerdP, 5 years ago

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

in reply to:  31 ; comment:32 by stoecker, 5 years ago

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

comment:33 by GerdP, 5 years ago

In 14426/josm:

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

in reply to:  32 comment:34 by Don-vip, 5 years ago

Replying to stoecker:

To make Vincent happy: :-)

Thanks! :)

comment:35 by stoecker, 5 years ago

Milestone: 18.11

comment:36 by Klumbumbus, 5 years ago

Works fine for me.

comment:37 by smaprs, 5 years ago

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!

comment:38 by stoecker, 5 years ago

Resolution: fixed
Status: newclosed

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.