Решение должно быть универсальным для любых возможных ситуаций. Причины могут быть самые разные - отключил/подключил плагины → перегрузился, сменил верисию JOSM → упал какой-то плагин и т.д.
Может, лучше сделать решение для одного случая, чем *джва года *ждать универсальное?
P.S. Ни в коем случае не претензия к соавторам JOSM, просто обсуждение подхода
Давайте придумаем что-то более-менее универсальное и протолкнем…
В карточке предлагалось сделать в заголовке каждой панели кнопку фиксации высоты, а остальные распределять пропорционально (как сейчас).
Проблема только в том, что панелей может стать слишком много (или окно уменьшится). Пропорционально уменьшать, чтобы все влезло?
если я правильно понял вопрос, который поддерживаю двумя руками - необходимо сохранить размер и расположение как основного окна так и боковой панелей при выходе и последующем запуске JOSM. просто сохранить состояние, хоть как-нибудь…
UPD: как вариант - сделать пункт меню или кнопку, по которой JOSM записывает в файл текущие параметры и расположение окна, при запуске проверяется на наличие файла и читает параметры. Частота сохранения в файл регулировать через настройки по таймеру или оставить на совести пользователя…
Или действительно доработать функционал сохранения сеанса.
…а ещё надо отслеживать изменение разрешения экрана…
Я посмотрел код и, кажется, понял, почему эту карточку никто не трогает:
Чтобы всё работало нормально, надо встроить правильные костыли вот в это и это.
Туда и смотреть-то никому не хочется 
P.S. Хотя, если удастся обойтись изменениями файла по первой ссылке - разобраться при желании можно.
Обязательно. У меня на рабочем месте один монитор 19201080, а второй 16001200. А когда я выдёргиваю их из ноута , то 1366*768. И это будет изменение между запусками JOSM.
Поэтому предлагаю делать только пропорционально. А потом продумывать поведение в “нештатных” ситуациях.
ага, вот как выглядит типичная конфигурация… вариант с 1 монитором является “нештатной” ситуацией, понятное дело )))
Согласен, пока сделать хотя бы сохранение пропорций, а в случае нештатных ситуаций оставить текущее поведение (равномерно распределять высоту на все панели).
^-)
Под нештатной понимаю:
Сейчас там не просто поровну. Оно, теоретически, распределяет пропорционально предпочитаемым размерам, при этом учитывает какие-то “большие” и “маленькие” панели (ну и сворачивание диалогов).
Как это взаимодействует потом с движением разделителей мышкой - никому не ведомо. В коде все гораздо хуже, чем просто массив чисел-размеров. Там два наложенных друг на друга самописных автовыравнивателя (DialogsPanel.reconstruct и MultiSplitLayout) плюс отдельный код для движения разделителей (в MultiSplitPanel).
Работает всё это как придётся. Сдвинуть-свернуть-развернуть диалог - и размер уже забыт.
Пытаться вставлять костыли в это зоопарк - значит что-нибудь порушить (т.е. панели спрячутся насовсем или начнут ползать куда попало). Переписать так, чтобы всё работало и было просто - тоже малореально.
Все переписать на eclipse RCP
И сколько оно будет памяти кушать, если туда 20 МБ .osm-ник загрузить? 
Примерно как джосм, прибавка на RCP, даже если она и будет, на фоне кеша геометрии потеряется.
Прикол то ведь не в этом, а в невозвратных потерях.
Можно ещё JOSM сделать плагином для Eclipse.
Причем в соседней вкладке редактировать его код
В вики давно идёт перенаправление с color → colour, а в пресетах type=route до сих пор по-старому.
вопрос о поиске в JOSM
например есть запрос:
building=* user:Xmypblu
как я понимаю, сейчас по имени ищется только последний автор, а как найти по первому автору?
есть параметр для поиска в истории объекта? что-то вроде version:1 - только для авторов правок?
Есть подозрение, что JOSM хранит только последнюю версию объекта. А история в соотв. диалоге для каждого отображения дёргается с сервера.
А вот можно ли через search выбрать точки, входящие в 2 или более линий? Те, которые JOSM “квадратиком” рисует.