Комментарии 120
Все замечательно до тех пор пока вы не измените размер окна и не начнете изобретать свой лэйаут для красивой отрисовки всего этого богатсва
Иногда абсолютно не нужно изменять размеры окна, иногда нужно сделать прототип, который просто нужно показать заказчику.
В любом случае layout на такую форму можно повесить в любой момент, когда это действительно понадобиться.
В любом случае layout на такую форму можно повесить в любой момент, когда это действительно понадобиться.
Если Вам нужно сделать «просто простотип» (даже если только для начала) — чем плох тот же редактор NetBeans'а, который вы описали? Вам и так и так в итоге придётся лэйаут переписывать, если это был просто «статичный» прототип.
Формочка сделанная в NetBeans мышкой при наличии layout может выглядеть абсолютно иначе в откомпилированном и запущенном виде нежели, когда вы её разрабатывали. А показывать прямо в IDE бывает не удобно. Иногда нужно просто послать jar с формочкой, что бы кнопки нажимались и что то делалось.
Конечно такой стиль создания формочек абсолютно не годится для приложения, но прототип надо делать быстро и практически не задумываясь, иначе заказ уйдет тем кто быстрее.
Конечно такой стиль создания формочек абсолютно не годится для приложения, но прототип надо делать быстро и практически не задумываясь, иначе заказ уйдет тем кто быстрее.
Иногда пользователи меняют DPI экрана и в результате абсолютная привязка элементов управления уезжает в тартарары. Layout manager'ы — это хорошо, правильно и удобно.
А на Ubuntu надпись в кнопочку не помещается. Для таких формочек как по мне, то лучше запретить развертывание на весь экран.
В студенческие годы программировать приходилось на Delphi. Начав знакомство со Swing тоже недоумевал почему я не могу задать координаты компонентов как в Delphi. Построение форм казалось очень сложным занятием.
Потом под руки попалась кника «ПОРТЯНКИН И. Swing: Эффектные пользовательские интерфейсы». Она открыла для меня всю прелесть и элегантность Layout подхода.
Сейчас, используя преимущественно BoxLayout, строю формы практически любой сложности. Генераторы форм не использую вообще и не знаю зачем они нужны.
Потом под руки попалась кника «ПОРТЯНКИН И. Swing: Эффектные пользовательские интерфейсы». Она открыла для меня всю прелесть и элегантность Layout подхода.
Сейчас, используя преимущественно BoxLayout, строю формы практически любой сложности. Генераторы форм не использую вообще и не знаю зачем они нужны.
есть выбор — можно изучать менеджеры компоновки, можно сразу начинать работать. Тем кто часто и много рисует формы эта библиотека, вероятно, упростит часть работы.
Есть выбор — можно начать изучать программирование, а можно сразу начинать работать.
пс. ничего не имею против библиотеки.
пс. ничего не имею против библиотеки.
Есть выбор — или учить программирование, в том числе layout'ы anchor'ы и иже с ними или сразу идти работать на завод. Бесят проги с прибитыми гвоздями размерами окон!
что ж такого ужасного на заводе. Я работал на заводе слесарем в 90-х, когда всё началось рушиться и работы не было никакой вообще. Ничё особенного.
Кроме того, по скриншоту несложно догадаться что контролы на форме динамически меняют размер/положение в зависимости от размеров окна т.е. никаких «прибитых гвоздями» размеров там нет.
Кроме того, по скриншоту несложно догадаться что контролы на форме динамически меняют размер/положение в зависимости от размеров окна т.е. никаких «прибитых гвоздями» размеров там нет.
Ну, кстати, в нэтбинсе с GroupLayout неплхой редактор интерфейсов. Порой когда нужно быстро накидать какой-нибудь диаложек, приходится делать компромис между опрятностью и быстротой написания. А тут можно быстро, и, что самое главное, без левых зависимостей сделать неплохой GUI.
GridBagLayout мне как-то симпатичнее BoxLayout'a. Но таки согласен — когда разбираешься — чувствуешь себя властелином — куда скажешь компоненту лечь, там и будет лежать! Все настраивается так как этого хочешь ты.
А у меня наоборот было, когда переходил с C++ Builder на Qt. Как только увидел компоновку с помощью слоев, сразу в нее влюбился. До сих пор не пользуюсь визуальными конструкторами — быстрее и точнее получается в коде реализовать компоновку.
Вроде же что-то было для декларативного xml, описывающего интерфейс?
AbsolutLayout, например, чем не нравится?
Для макета должно быть самое оно и быстро и понятно, нет?
Вообще думаю при большой сложной форме разобраться будет сложно, я во всяком случае предпочитаю использовать GridBagLayout да мне не лень посидеть подольше и получить в точности то что я хочу:)
Ну и да насчёт того, что рисовалка генерит сложный код и в нём потом сложно разобраться… а зачем? Если есть рисовалка, то и правьте через неё, в NetBeans сгенерированный код вообще заботливо заблокирован и подправить его без рисовалки в самой IDE невозможно (ну если стереть теги сторонним редактором, то конечно возможно).
int labelsWidth=150;
getContentPane().setLayout(new AbsoluteLayout());
getContentPane().add(jLabel1, new AbsoluteConstraints(0, 8, 100, -1));
getContentPane().add(jTextField1, new AbsoluteConstraints(110, 8, 100, -1));
Для макета должно быть самое оно и быстро и понятно, нет?
Вообще думаю при большой сложной форме разобраться будет сложно, я во всяком случае предпочитаю использовать GridBagLayout да мне не лень посидеть подольше и получить в точности то что я хочу:)
Ну и да насчёт того, что рисовалка генерит сложный код и в нём потом сложно разобраться… а зачем? Если есть рисовалка, то и правьте через неё, в NetBeans сгенерированный код вообще заботливо заблокирован и подправить его без рисовалки в самой IDE невозможно (ну если стереть теги сторонним редактором, то конечно возможно).
getContentPane().add(jTextField1, new AbsoluteConstraints(110, 8, 100, -1));
— тут заданы константные координаты
.item(new ComponentBox()
.component(jTextField1)
.width(layoutless.width().minus(labelsWidth).minus(16))
.height(22)
.x(labelsWidth+8)
.y(8+25*0)
)
— тут ширина поля меняется при изменении размеров окошка. Из кода layoutless.width().minus(labelsWidth).minus(16) понятно что это
ширина — отступ — 16
— тут заданы константные координаты
.item(new ComponentBox()
.component(jTextField1)
.width(layoutless.width().minus(labelsWidth).minus(16))
.height(22)
.x(labelsWidth+8)
.y(8+25*0)
)
— тут ширина поля меняется при изменении размеров окошка. Из кода layoutless.width().minus(labelsWidth).minus(16) понятно что это
ширина — отступ — 16
В NetBeans рисовалка очень часто выдает не то, что хотелось.
Например создаю форму кидаю на нее 3 текста и 3 лабела.
Мышкой выстраиваю их вертикально один надо другим, в общем делаю форму как в статье.
Потом запускаю ее и разворачиваю на весь экран… в результате верхний текст смещается в право до конца, а остальные остаются с лева и не двигаются.
Открываю снова редактор. Пытаюсь подвигать элементы по форме в лево — в право.
В результате при перемещении одних одних элементв, другие (которые я даже не трогал) самопроизвольно меняют свою форму и положение на экране.
В общем при перемещении элементов по форме нетбинс сам их по каким-то своим внутренним законам перепривязывает перемещает и меняет размеры…
Поэтому многие вещи рисую руками…
Например создаю форму кидаю на нее 3 текста и 3 лабела.
Мышкой выстраиваю их вертикально один надо другим, в общем делаю форму как в статье.
Потом запускаю ее и разворачиваю на весь экран… в результате верхний текст смещается в право до конца, а остальные остаются с лева и не двигаются.
Открываю снова редактор. Пытаюсь подвигать элементы по форме в лево — в право.
В результате при перемещении одних одних элементв, другие (которые я даже не трогал) самопроизвольно меняют свою форму и положение на экране.
В общем при перемещении элементов по форме нетбинс сам их по каким-то своим внутренним законам перепривязывает перемещает и меняет размеры…
Поэтому многие вещи рисую руками…
Для «почти абсолютного» позиционирования можно, как вариант, использовать GraphPaperLayout. Тоже абсолютное позиционирование, только в условных единицах (если выставить 100х100, то, получается, в процентах). А при изменении размера контейнера все контролы перепозиционируются.
Хотя я лично предпочитаю писать код руками, как раз чтобы:
— не зависеть от рисовалки
— получать понятный, поддерживаемый код
— не зависеть от рисовалки
— получать понятный, поддерживаемый код
Ну, когда у вас в проекте 2 окна, то это может и прокатит
Около сотни окон в проекте, если не больше. Интерфейс только руками делаю.
Могу вас только пожалеть, что еще сказать…
Представляете как жить html верстальщикам? :)
Не даром Портянкин в своей книге называет процесс «Искусством расположения». Кому-то нравится ковыряться руками в этом, а кому-то хочется побыстрее накидать компонентов мышкой на форму.
www.ipsoftware.ru/books/swing_book_2/chapters/ch05.html
www.ipsoftware.ru/books/swing_book_2/chapters/ch05.html
Я не кидаю руками на форму, пишу в разметке. Я не к тому, что плохо писать код разметки руками, а к тому, что императивно это писать — мУка, декларативно — в разы удобнее и нагляднее.
Ну а разметку множества похожих окон с повторяющимися группами элементов руками нормальные люди не делают. Есть куда более подходящие для этого инструменты.
Ну а разметку множества похожих окон с повторяющимися группами элементов руками нормальные люди не делают. Есть куда более подходящие для этого инструменты.
Не скажите :)
Уже сказал :)
меня опередили :)
Проще писать лейаут декларативно на WPF/Silverlight/XAML и не заниматься ковырянием старых костылей
это блог по Java
Ну и что. Наверняка и под Java есть аналоги XAML-овской верстки
Поменять простую и понятную яву на очередной нечеловечий xml? Данунафиг!
Да вы просто не пробовали. Не знаю ни одного программиста среди своих знакомых, кто с разметки в XAML вернулся бы к раскидыванию компонентов в визуальном дизайнере и уж тем более к прописыванию лэйаута процедурно.
То, что вы предлагаете — это просто как каменный век какой-то…
То, что вы предлагаете — это просто как каменный век какой-то…
Каменный век — это использование технологии, разработанной для обмена данными с целью описания конфигураций. Нечитабельная, неписабельная, нечеловекопонятная технология. Для компьютера, тоже не сказать, что сильно понятная. Понятно, что в тех областях, для которых она была разработана чем-то приходится жертвовать. Но в данном случае жертвы совершенно бессмысленны.
«процедурное» решение не так плохо, а если его обернуть в какой-никакой DSL, получится вообще конфетка.
«процедурное» решение не так плохо, а если его обернуть в какой-никакой DSL, получится вообще конфетка.
Вы как-то слишком узко на XML смотрите. XML — это язык разметки. И то, что разметить можно структуры данных совершенно не означает, что он только для этого годится.
Насчет нечитабельности и неписабельности — бред. XML достаточно информативен для описания структуры интерфейса. Впрочем, если информативности не хватает — есть всевозможные инструменты, чтобы лучше ее визуализировать — Document Outline в VS, например.
Нечитабельно и нечеловекопонятно — последовательное описание интерфейсв процедурным способом, где не видна ни структура, ни порядок расположения элементов, ничего, невозможно отделить код от представления, сделовательно отделить работу программиста от работы дизайнера.
Я еще понимаю, когда такой подход использовался много лет назад за неимением других средств. Но сегодня я такие предпочтения могу обьяснить только ограниченностью и паталогической консервативностью человека, такие предпочтения имеющего.
Я уж не говорю, что таких людей не возьмут делать UI ни в один сколь либо серьезный проект. На вас там просто как на дурачка посмотрят. И правильно сделают.
Я не знаю, может вы последние лет 5-10 прожили в информационном вакууме, потому предлагаю вам просто посмотреть какой-нибудь видеоурок по WPF или статью про WPF нагуглить.
Насчет нечитабельности и неписабельности — бред. XML достаточно информативен для описания структуры интерфейса. Впрочем, если информативности не хватает — есть всевозможные инструменты, чтобы лучше ее визуализировать — Document Outline в VS, например.
Нечитабельно и нечеловекопонятно — последовательное описание интерфейсв процедурным способом, где не видна ни структура, ни порядок расположения элементов, ничего, невозможно отделить код от представления, сделовательно отделить работу программиста от работы дизайнера.
Я еще понимаю, когда такой подход использовался много лет назад за неимением других средств. Но сегодня я такие предпочтения могу обьяснить только ограниченностью и паталогической консервативностью человека, такие предпочтения имеющего.
Я уж не говорю, что таких людей не возьмут делать UI ни в один сколь либо серьезный проект. На вас там просто как на дурачка посмотрят. И правильно сделают.
Я не знаю, может вы последние лет 5-10 прожили в информационном вакууме, потому предлагаю вам просто посмотреть какой-нибудь видеоурок по WPF или статью про WPF нагуглить.
>Я не знаю, может вы последние лет 5-10 прожили в информационном вакууме, потому предлагаю вам просто посмотреть какой-нибудь видеоурок по WPF
MS-фаги — они такие, MS-фаги :). Да высуньте уже нос из своего болота. Мир гораздо шире того, что вам навязывает ваша любимая контора. Из того, что в вашем мире наиболее пригодным для использования оказался совершенно не предназначенный для этого инструмент, вовсе не следует, что это лучший инструмент. Скорее следует, что все прочие инструменты из _вашего_ инструментария ещё хуже. Из вариантов забить гвоздь сотовым телефоном или микроскопом, я бы, да, пожалуй, выбрал микроскоп. Но молоток-то всё-равно лучше!
MS-фаги — они такие, MS-фаги :). Да высуньте уже нос из своего болота. Мир гораздо шире того, что вам навязывает ваша любимая контора. Из того, что в вашем мире наиболее пригодным для использования оказался совершенно не предназначенный для этого инструмент, вовсе не следует, что это лучший инструмент. Скорее следует, что все прочие инструменты из _вашего_ инструментария ещё хуже. Из вариантов забить гвоздь сотовым телефоном или микроскопом, я бы, да, пожалуй, выбрал микроскоп. Но молоток-то всё-равно лучше!
Вы не переживайте, видите же, что у него карма в минусе. Это MSер не первый день троллит Java-блоги своим «Попробуйте WPF, он круче всего, а на линух мне насрать!»
При чем тут МС-фаги. Я вам пример WPF привожу только потому, что сам на нем пишу. Как я уже выше упоминал, в Java наверняка есть что-то сходное.
Совершенно непредназначенным для проектирования UI инструментом является тот, который вы с непонятным упорством отстаиваете. И вы не приведете ни одного весомого контрдовода по этому утверждению. Чушь про ресурсоемкость и нечитабельность я даже не рассматриваю.
А вот я вам привожу конкретные доводы:
-куда лучшая читабельность, т.к. видна структура UI, а не процесс ее сборки
-куда лучшая поддерживаемость, т.к. быстрее можно понять что есть что и как работает
-адаптируемость к глобальным изменениям в множестве подобных форм при помощи паттернов типа MVVM
-отделение кода от представления — возможность каждому заниматься своей работой — дизайнеру интерфейсом, программисту — кодом
-облегчение кроссплатформенности
-возможность работы с представлением программистам, работающим с разными ЯП, например C#, VB.NET, Делфи и т.д.
-куда более легкая работа над стилизацией компонентов, над их шаблонами и т.д.
Это самые очевидные преимущества.
А что может предложить ваш подход? Да ничего.
Совершенно непредназначенным для проектирования UI инструментом является тот, который вы с непонятным упорством отстаиваете. И вы не приведете ни одного весомого контрдовода по этому утверждению. Чушь про ресурсоемкость и нечитабельность я даже не рассматриваю.
А вот я вам привожу конкретные доводы:
-куда лучшая читабельность, т.к. видна структура UI, а не процесс ее сборки
-куда лучшая поддерживаемость, т.к. быстрее можно понять что есть что и как работает
-адаптируемость к глобальным изменениям в множестве подобных форм при помощи паттернов типа MVVM
-отделение кода от представления — возможность каждому заниматься своей работой — дизайнеру интерфейсом, программисту — кодом
-облегчение кроссплатформенности
-возможность работы с представлением программистам, работающим с разными ЯП, например C#, VB.NET, Делфи и т.д.
-куда более легкая работа над стилизацией компонентов, над их шаблонами и т.д.
Это самые очевидные преимущества.
А что может предложить ваш подход? Да ничего.
>-куда лучшая читабельность, т.к. видна структура UI, а не процесс ее сборки
Видна структура XML, а не UI. И структура эта совершенно не читабельна. Я ради интереса специально нагуглил несколько примеров. Даже учебные примеры — это что-то с чем-то. Нагромождения тегов стопиццотой степени вложенности. Ага, хорошо видна структура…
>-куда лучшая поддерживаемость, т.к. быстрее можно понять что есть что и как работает
Из XML-я понять как работает? Не лазя в код? И что вы, в таком случае, подразумеваете под работой??? :)
>-адаптируемость к глобальным изменениям в множестве подобных форм при помощи паттернов типа MVVM
Нихт ферштейн. Наверное, это круто. Как это связано с xml-ем?
>-отделение кода от представления — возможность каждому заниматься своей работой — дизайнеру интерфейсом, программисту — кодом
Вы заставляете дизайнеров писать вот эти самые xml-ные портянки? Да, это посильнее фауста-гёте.
>-облегчение кроссплатформенности
С мс-вынь на мс-вынь? Тоже сильно, да.
>-возможность работы с представлением программистам, работающим с разными ЯП, например C#, VB.NET, Делфи и т.д.
А зачем?
>-куда более легкая работа над стилизацией компонентов, над их шаблонами и т.д.
Прописыванием атрибутов в тегах? :)
>А что может предложить ваш подход? Да ничего.
Разукрасить как угодно, работать как угодно не прибегая к уродскому костылю XML. Всего-то.
Я понимаю, мс-фаги настолько привыкли к «ресурсам» описания гуя, что считают невозможным обходиться без них. А когда вместо бинарных им предложили хоть с трудом, но таки читаемые xml-портянки, радости не было предела :). См выше высказывание микроскоп vs телефон. Да. лучше, но намного ли?
Видна структура XML, а не UI. И структура эта совершенно не читабельна. Я ради интереса специально нагуглил несколько примеров. Даже учебные примеры — это что-то с чем-то. Нагромождения тегов стопиццотой степени вложенности. Ага, хорошо видна структура…
>-куда лучшая поддерживаемость, т.к. быстрее можно понять что есть что и как работает
Из XML-я понять как работает? Не лазя в код? И что вы, в таком случае, подразумеваете под работой??? :)
>-адаптируемость к глобальным изменениям в множестве подобных форм при помощи паттернов типа MVVM
Нихт ферштейн. Наверное, это круто. Как это связано с xml-ем?
>-отделение кода от представления — возможность каждому заниматься своей работой — дизайнеру интерфейсом, программисту — кодом
Вы заставляете дизайнеров писать вот эти самые xml-ные портянки? Да, это посильнее фауста-гёте.
>-облегчение кроссплатформенности
С мс-вынь на мс-вынь? Тоже сильно, да.
>-возможность работы с представлением программистам, работающим с разными ЯП, например C#, VB.NET, Делфи и т.д.
А зачем?
>-куда более легкая работа над стилизацией компонентов, над их шаблонами и т.д.
Прописыванием атрибутов в тегах? :)
>А что может предложить ваш подход? Да ничего.
Разукрасить как угодно, работать как угодно не прибегая к уродскому костылю XML. Всего-то.
Я понимаю, мс-фаги настолько привыкли к «ресурсам» описания гуя, что считают невозможным обходиться без них. А когда вместо бинарных им предложили хоть с трудом, но таки читаемые xml-портянки, радости не было предела :). См выше высказывание микроскоп vs телефон. Да. лучше, но намного ли?
Видна структура XML, а не UI. И структура эта совершенно не читабельна.
Очень даже читабельна. Видно что и в каком порядке идет, какой компонент внутри какого находится и т.д. Если у вас все же проблемы с этим, в VS есть инструмент Document Outline.
Из XML-я понять как работает? Не лазя в код? И что вы, в таком случае, подразумеваете под работой??? :)
Очень даже можно, когда элемент к чему-либо биндится, когда у него прописан шаблон или стиль, например. Разумеется, обработчики событий там не располагаются физически, но к ним оттуда легко перейти. Плюс в стилях можно посмотреть на реакцию на те или иные воздействия — установка/потеря фокуса и все в таком духе.
Нихт ферштейн. Наверное, это круто. Как это связано с xml-ем?
ru.wikipedia.org/wiki/MVVM
Вы заставляете дизайнеров писать вот эти самые xml-ные портянки? Да, это посильнее фауста-гёте.
У дизайнеров есть Expression Blend и Expression Design. Им совершенно не требуется иметь дело с кодом, хотя при желании, конечно, можно.
С мс-вынь на мс-вынь? Тоже сильно, да.
А что, парсить XML возможно только на мс-вынь?
А зачем?
Чтобы иметь меньшую зависимость от кодера и его привязанности к тому или иному языку
Прописыванием атрибутов в тегах? :)
Да, это весьма удобно и наглядно. Так же позволяет легко делиться шаблонами компонентов и стилями, переключать их на лету без перекомпиляции и т.д. и т.п.
К тому же, в ручную прописывать тоже не обязательно — для этого есть удобные инструменты.
Разукрасить как угодно, работать как угодно не прибегая к уродскому костылю XML.
Ага, только я сделаю это в несколько раз быстрее и возможностей стилизации у меня будет на несколько порядков больше. Это к вопросу о том, что считать костылем.
Я понимаю, мс-фаги настолько привыкли к «ресурсам» описания гуя, что считают невозможным обходиться без них.
А зачем обходиться без них, если они повышают в разы скорость разработки и поддерживаемость кода?
Впрочем, суровые мазохисты могут абсолютно все делать в коде процедурно. Только зачем?
См выше высказывание микроскоп vs телефон. Да. лучше, но намного ли?
Я не знаю, что навеяло вам такие сравнения, но сказать могу однозначно, что да, на много.
Очень даже читабельна. Видно что и в каком порядке идет, какой компонент внутри какого находится и т.д. Если у вас все же проблемы с этим, в VS есть инструмент Document Outline.
Из XML-я понять как работает? Не лазя в код? И что вы, в таком случае, подразумеваете под работой??? :)
Очень даже можно, когда элемент к чему-либо биндится, когда у него прописан шаблон или стиль, например. Разумеется, обработчики событий там не располагаются физически, но к ним оттуда легко перейти. Плюс в стилях можно посмотреть на реакцию на те или иные воздействия — установка/потеря фокуса и все в таком духе.
Нихт ферштейн. Наверное, это круто. Как это связано с xml-ем?
ru.wikipedia.org/wiki/MVVM
Вы заставляете дизайнеров писать вот эти самые xml-ные портянки? Да, это посильнее фауста-гёте.
У дизайнеров есть Expression Blend и Expression Design. Им совершенно не требуется иметь дело с кодом, хотя при желании, конечно, можно.
С мс-вынь на мс-вынь? Тоже сильно, да.
А что, парсить XML возможно только на мс-вынь?
А зачем?
Чтобы иметь меньшую зависимость от кодера и его привязанности к тому или иному языку
Прописыванием атрибутов в тегах? :)
Да, это весьма удобно и наглядно. Так же позволяет легко делиться шаблонами компонентов и стилями, переключать их на лету без перекомпиляции и т.д. и т.п.
К тому же, в ручную прописывать тоже не обязательно — для этого есть удобные инструменты.
Разукрасить как угодно, работать как угодно не прибегая к уродскому костылю XML.
Ага, только я сделаю это в несколько раз быстрее и возможностей стилизации у меня будет на несколько порядков больше. Это к вопросу о том, что считать костылем.
Я понимаю, мс-фаги настолько привыкли к «ресурсам» описания гуя, что считают невозможным обходиться без них.
А зачем обходиться без них, если они повышают в разы скорость разработки и поддерживаемость кода?
Впрочем, суровые мазохисты могут абсолютно все делать в коде процедурно. Только зачем?
См выше высказывание микроскоп vs телефон. Да. лучше, но намного ли?
Я не знаю, что навеяло вам такие сравнения, но сказать могу однозначно, что да, на много.
Я извиняюсь, цитаты помечал болдом, почему-то слетели
>Очень даже читабельна.
Да, после бинарных, наверное, даже xml-уродство — за счастье :)
>У дизайнеров есть Expression Blend и Expression Design. Им совершенно не требуется иметь дело с кодом, хотя при желании, конечно, можно.
Тогда зачем вы включили это как плюс, если оно не имеет отношения к делу?
>А что, парсить XML возможно только на мс-вынь?
Парсить можно везде, но какой в этом смысл? Ну, отпарсю я ваш xml на линуксе и что?
>Чтобы иметь меньшую зависимость от кодера и его привязанности к тому или иному языку
У вас реально есть такие многоязыковые проекты? Круто. Реально круто.
>Ага, только я сделаю это в несколько раз быстрее и возможностей стилизации у меня будет на несколько порядков больше. Это к вопросу о том, что считать костылем.
Пардон, поменять атрибуты в сотне мест это быстрее, чем поменять один класс? Да, это тоже сильно.
>А зачем обходиться без них, если они повышают в разы скорость разработки и поддерживаемость кода?
Не вижу в каком месте. По сравнению с бинарными ресурсами, наверное, да. Но по сравнению с нормальными средствами — смех один.
Я понимаю ваш восторг когда после совсем убогого инструмента вам дали чуть менее убогий. Но писать об этом в теме про яву?.. Видите ли в чём дело, — в явском мире xml уже давно запихали куда только можно, где надо и где не надо. Чаще где не надо, тк мест где он действительно необходим не так уж и много. И явские разработчики уже нахлебались с этим xml-ем по самое нехочу. Слава аллах-акбару, тенденция ухода от этих костылей на более удобные инструменты таки наметилась, хотя процесс и идёт со скрипом. Вам это ещё предстоит осознать, похоже. Что ж, учитесь на своих ошибках, раз людей, которые через это уже прошли слушать не хотите. Ваш путь.
Да, после бинарных, наверное, даже xml-уродство — за счастье :)
>У дизайнеров есть Expression Blend и Expression Design. Им совершенно не требуется иметь дело с кодом, хотя при желании, конечно, можно.
Тогда зачем вы включили это как плюс, если оно не имеет отношения к делу?
>А что, парсить XML возможно только на мс-вынь?
Парсить можно везде, но какой в этом смысл? Ну, отпарсю я ваш xml на линуксе и что?
>Чтобы иметь меньшую зависимость от кодера и его привязанности к тому или иному языку
У вас реально есть такие многоязыковые проекты? Круто. Реально круто.
>Ага, только я сделаю это в несколько раз быстрее и возможностей стилизации у меня будет на несколько порядков больше. Это к вопросу о том, что считать костылем.
Пардон, поменять атрибуты в сотне мест это быстрее, чем поменять один класс? Да, это тоже сильно.
>А зачем обходиться без них, если они повышают в разы скорость разработки и поддерживаемость кода?
Не вижу в каком месте. По сравнению с бинарными ресурсами, наверное, да. Но по сравнению с нормальными средствами — смех один.
Я понимаю ваш восторг когда после совсем убогого инструмента вам дали чуть менее убогий. Но писать об этом в теме про яву?.. Видите ли в чём дело, — в явском мире xml уже давно запихали куда только можно, где надо и где не надо. Чаще где не надо, тк мест где он действительно необходим не так уж и много. И явские разработчики уже нахлебались с этим xml-ем по самое нехочу. Слава аллах-акбару, тенденция ухода от этих костылей на более удобные инструменты таки наметилась, хотя процесс и идёт со скрипом. Вам это ещё предстоит осознать, похоже. Что ж, учитесь на своих ошибках, раз людей, которые через это уже прошли слушать не хотите. Ваш путь.
JavaFX? Но она вроде бы рипнулась.
С другой стороны, парсинг даже небольшого XML-файла для того, чтобы просто создать окно — достаточно затратная по времени и памяти операция.
> Библиотека Swing появилась примерно 15 лет назад и все эти 15 лет КАЖДЫЙ кто начинает программировать на Java задаёт один и тот же вопрос:
> — Почему я не могу просто добавить кнопки с полями на форму без изучения всех этих LayoutManager'ов?
Я не задавал, как и КАЖДЫЙ, кто до этого писал на Tcl.
> — Почему я не могу просто добавить кнопки с полями на форму без изучения всех этих LayoutManager'ов?
Я не задавал, как и КАЖДЫЙ, кто до этого писал на Tcl.
НЛО прилетело и опубликовало эту надпись здесь
можно сравнить читабельность и размер кода для одинаковых форм.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Начинаем сравнивать по основным параметрам. Для краткости возьмём определение первого текстового поля.
Код Layoutless:
Код FormLayout:
Читабельность
FormLayout — что делает код непонятно без изучения документации. Что такое, скажем, «3dlu» предположить сложно.
Layoutless — даже постороннему с первого взгляда ясно что у компонента задаются размер и положение (x/y они и в Африке x/y, для ширины там вполне читабельное математическое выражение).
Возможность ошибок
FormLayout — что будет если в текстовой строке спецификации указать просто «blablabla»? Что будет если указать 2 колонки по 2 компонента но добавить 5 компонентов? Причём проблемы вылезут в рантайме а не при компиляции а значит их трудней обнаружить.
Layoutless — подобные ошибки внести нельзя. Колонок нет, строк нет, текстовых описаний компоновки тоже нет. Есть только простые как штопор координаты с размерами.
Простота модификации
FormLayout — предположим что у первого текстового поля понадобилось добавить кнопку для вызова диалога выбора файла. Нужно переделать описание столбцов и рядов на каком-то миниязыке типа «max(60dlu;p), 3dlu, p:grow» (или как они это называют comma separated encoded specifications).
Layoutless — нужно уменьшить ширину поля:
и добавить на освободившееся место кнопку
Итого:
У Layoutless по сравнению с FormLayout лучше читаемость, меньше возможностей допустить ошибку, проще (ну, или очевидней) модификация кода.
Логично?
Код Layoutless:
layoutless
.item(new ComponentBox()
.component(jTextField1)
.width(layoutless.width().minus(labelsWidth).minus(16))
.height(22)
.x(labelsWidth+8)
.y(8+25*0)
)
Код FormLayout:
FormLayout layout = new FormLayout(
"max(60dlu;p), 3dlu, p:grow", // columns
"p, 3dlu, p, 3dlu, p" // rows
);
CellConstraints cc = new CellConstraints();
builder.add(jTextField1, cc.xy(3, 1));
Читабельность
FormLayout — что делает код непонятно без изучения документации. Что такое, скажем, «3dlu» предположить сложно.
Layoutless — даже постороннему с первого взгляда ясно что у компонента задаются размер и положение (x/y они и в Африке x/y, для ширины там вполне читабельное математическое выражение).
Возможность ошибок
FormLayout — что будет если в текстовой строке спецификации указать просто «blablabla»? Что будет если указать 2 колонки по 2 компонента но добавить 5 компонентов? Причём проблемы вылезут в рантайме а не при компиляции а значит их трудней обнаружить.
Layoutless — подобные ошибки внести нельзя. Колонок нет, строк нет, текстовых описаний компоновки тоже нет. Есть только простые как штопор координаты с размерами.
Простота модификации
FormLayout — предположим что у первого текстового поля понадобилось добавить кнопку для вызова диалога выбора файла. Нужно переделать описание столбцов и рядов на каком-то миниязыке типа «max(60dlu;p), 3dlu, p:grow» (или как они это называют comma separated encoded specifications).
Layoutless — нужно уменьшить ширину поля:
.item(new ComponentBox()
.component(jTextField1)
.width(layoutless.width().minus(labelsWidth).minus(16)<b>.minus(50)</b>)
.height(22)
.x(labelsWidth+8)
.y(8+25*0)
)
и добавить на освободившееся место кнопку
Итого:
У Layoutless по сравнению с FormLayout лучше читаемость, меньше возможностей допустить ошибку, проще (ну, или очевидней) модификация кода.
Логично?
НЛО прилетело и опубликовало эту надпись здесь
жёсткое задание размеров прекрасно существует в огромном количестве успешных приложений в самых разных областях.
Не надо преувеличивать.
Не надо преувеличивать.
НЛО прилетело и опубликовало эту надпись здесь
«Рисовать интерфейсы» было возможно (на Java) ещё во времена JBuilder 6, но при этом он не только генерировал ужасный код, вместе с дополнительными файлами xml, но и использовал собственные классы. Я тогда возненавидел не только метод jbInit() и класс XYLayoutManager, но и вообще визуальный метод рисования форм.
А когда вдруг он вышел на базе Eclipse, я вообще отказался от этого варезника, и полюбил Eclipse c версии 3.1. Да, там нет средств визуального проектирования «из коробки», но есть что-то, что удерживает от использования таких замечательных IDE, как, например, NetBeans и IntelliJ Idea.
А когда вдруг он вышел на базе Eclipse, я вообще отказался от этого варезника, и полюбил Eclipse c версии 3.1. Да, там нет средств визуального проектирования «из коробки», но есть что-то, что удерживает от использования таких замечательных IDE, как, например, NetBeans и IntelliJ Idea.
Я тезисно, можно?
1. GroupLayout никогда не был предназначен для «ручного» программирования.
2. MigLayout чуть ли не старше GroupLayout-а. Кстати, автор MigLayout — военный лётчик. :)
3. Layout manager позволяет правильно располагать элементы при масштабировании контейнера, изменении размера шрифта, смены разрешения экрана, Look-n-Feel и т.п. Не хотите изучать layout manager-ы в Java? Смените род занятий и не занимайтесь больше UI.
1. GroupLayout никогда не был предназначен для «ручного» программирования.
2. MigLayout чуть ли не старше GroupLayout-а. Кстати, автор MigLayout — военный лётчик. :)
3. Layout manager позволяет правильно располагать элементы при масштабировании контейнера, изменении размера шрифта, смены разрешения экрана, Look-n-Feel и т.п. Не хотите изучать layout manager-ы в Java? Смените род занятий и не занимайтесь больше UI.
Не хотите изучать layout manager-ы в Java? Смените род занятий и не занимайтесь больше UI.
— мне кажется из текста и из кода видно что я очень хорошо знаю что такое layout manager-ы в Java. Те кто предпочитают MigLayout могут использовать его. Те кому не нравится концепция компоновщиков в принципе могут использовать мой вариант.
— мне кажется из текста и из кода видно что я очень хорошо знаю что такое layout manager-ы в Java. Те кто предпочитают MigLayout могут использовать его. Те кому не нравится концепция компоновщиков в принципе могут использовать мой вариант.
Ваш вариант — тот же layout manager, только вид сбоку и хуже. Впрочем, если допилить (например, использовать LayoutStyle.getComponentGap() (спрятать в какой-нибудь Layoutless.gap()) вместо захардкоденных значений отступов), то он может и оказаться годным.
ну, это у же софистика. Конечно если контейнер управляет расположением дочерних компонентов то он выполняет примерно те же функции что и копмоненты имплементирующие интерфейс LayoutManager.
На счёт хуже — выше есть сравнение с тем же FormLayout. Функционал немного отличается но читабельность и отказоустойчивость выше. Что и было конечной целью создания библиотеки.
На счёт хуже — выше есть сравнение с тем же FormLayout. Функционал немного отличается но читабельность и отказоустойчивость выше. Что и было конечной целью создания библиотеки.
сто процентов, вы тоже создали layout manager. Вообще при ручном формировании UI, без layout manager обойтись не возможно. Каждый считает что его layout manager идеальный. Но в реале CSS имеет всех разом. Но пока JavaFX еще в бета стадии придется еще мучатся. Потом вопросы по UI в Java исчезнут.
А потом вашу программу запустят на системе с DPI != 96 и всё поплывёт.
И здесь, что ли, вставить свои две копейки и сравнить с SWT? :)
Так там та же хрень ))
Может даже несколько попроще…
Ну, правда, тут небольшой чит — это не чистый SWT, а JFace, и кнопочки к диалогу идут бесплатно. :)
protected Control createDialogArea(Composite parent) {
final Composite area = (Composite) super.createDialogArea(parent);
((GridLayout) area.getLayout()).numColumns = 2;
GridDataFactory gdf = GridDataFactory.fillDefaults()
.hint(200, SWT.DEFAULT);
new Label(area, SWT.NONE).setText("Label 1");
text1 = new Text(area, SWT.SINGLE | SWT.BORDER);
text1.setText("Text 1");
gdf.applyTo(text1);
new Label(area, SWT.NONE).setText("Label 2");
text2 = new Text(area, SWT.SINGLE | SWT.BORDER);
text2.setText("Text 2");
gdf.applyTo(text2);
new Label(area, SWT.NONE).setText("Long label 3");
text3 = new Text(area, SWT.PASSWORD | SWT.BORDER);
text3.setText("Password");
gdf.applyTo(text3);
return area;
}
Ну, правда, тут небольшой чит — это не чистый SWT, а JFace, и кнопочки к диалогу идут бесплатно. :)
Код, сгенерированный WindowBuilder'ом для того же груп лэйаута вроде бы получше выглядит.
В свое время очень много на свинге писал. Формы ручками исключительно писал. Потом в большом проекте использовал рисовалку от идеи — уж очень мне она понравилась с JGoodies.
Счас столкнулся с ExtJs, для которого визуалка есть только платная, а json код напоминает по результатам программирование swing форм руками. Очень пригодились навыки swing и знание layout-ов. Да и под андроид насколько я понял писать приходится на тех-же лайотах. Так что лайоты надо знать!
Счас столкнулся с ExtJs, для которого визуалка есть только платная, а json код напоминает по результатам программирование swing форм руками. Очень пригодились навыки swing и знание layout-ов. Да и под андроид насколько я понял писать приходится на тех-же лайотах. Так что лайоты надо знать!
Ну и треш. Неужели за 15 лет никто не додумался верстать формы хотя бы с помощью XML? Это же какой-то быдлокод, с этими всеми .add() и .setWidth(). В десктопном программировании творится какой-то мрак.
Частично согласен. GUI, как и View в MVC, должен быть пассивен и декларативен. Тем более, что .setWidth() эквивалентен .width=
Впрочем, несложно написать LayoutManager, который будет свои правила брать из xml или properties. Сложности могут появиться тогда, когда нужна сложная логика расположения, которую декларативно не очень опишешь красиво.
Впрочем, несложно написать LayoutManager, который будет свои правила брать из xml или properties. Сложности могут появиться тогда, когда нужна сложная логика расположения, которую декларативно не очень опишешь красиво.
Да додумались, см. SwingX или XWT, но они как-то непопулярны.
Согласен все все сто. Не слишком слежу за миром Java, потому, будучи WPF разработчиком, я был крайне удивлен тому, что такие технологии каменного века все еще используются и о них всерьез пишутся статьи.
Хочется ПОУБИВАТЬ всех, кто не юзает менеджеры компоновки.
[sarcasm]а я делаю так — качаю Qt Creator...[/sarcasm]
к сожалению сначала я запостил статический скриншот и большинство подумало что в примере просто заданы константные координаты. Сейчас скриншот показывает как меняются размеры и положение контролов в зависимости от размера формы.
Если кто-то считает что знает компоновщик позволяющий для такой небольшой формы сделать более простой и читабельный код (см. текст исходника) то просьба запостить пример реализации такого же окошка сюда для сравнения. И только потом делиться своими оценками.
Если кто-то считает что знает компоновщик позволяющий для такой небольшой формы сделать более простой и читабельный код (см. текст исходника) то просьба запостить пример реализации такого же окошка сюда для сравнения. И только потом делиться своими оценками.
Код формы из первого скриншота выглядит так:Это ужасно. Ужасно неудобно, нечитаемо и неподдерживаемо, имхо. Даже по сравнению с длиннющими портянками GridBag-конструкторов. Не вижу ни одного преимущества перед классическими layout-ами, при том, что явные недостатки (описанные выше) налицо, особенно про «поплывёт», от чего layout-ы, собственно, призваны спасать. В вашем же случае получается по факту реально то же самое, только надо в голове разруливать зависимости расположений элементов относительно друг друга, да ещё и в абсолютных значениях каких-то.
Если кто-то считает что знает компоновщик позволяющий для такой небольшой формы сделать более простой и читабельный код (см. текст исходника)Лично я не считаю это простым и читабельным кодом. Потому, что код для описания раскладки не должен быть таким. ИМХО, опять же. А вообще, это просто субъективные вещи всё. Вам не нравится как выглядит работа с классическими layout-ами и вы написали велосипед. Больше нет причин искать подобные альтернативы) А мне механизм лаяутов в java очень нравится удобством и гибкостью.
вооот. Уже лучше. Есть волшебное слово «ИМХО». Осталось привести код который компонует такую простую форму как на скриншоте и сравнить, насколько работа с привязкой к границам контейнера проще и логичней.
Понимаете, очевидно, что при изобретении велосипедов действует презумпция ненужности. Не ВАМ должны доказывать, что существующие способы лучше, а ВЫ должны показать ЧЕМ вам способ удобнее и интереснее (особенно в общем случае). А на деле у вас получается такая же длиннющая портянка кода, со всеми своими непонятностями и недостатками. Она вам кажется понятнее и удобнее, это ясно. И даже, вероятно, в некоторых случаях она себя оправдает своим (как модно говорить, «функциональным») подходом. Но я не вижу ни одной реальной посылки его использовать, хотя я по-честному обдумал ваш способ и постарался разобраться в том, что вы написали.
в каментах ниже и выше приводились примеры кода похожей формы для MigLayout и для FormLayout. Я привёл вполне логичный разбор и показал что недостатков у Layoutless меньше. Будет другие примеры — можно сравнить с ними.
Относительно кто кому должен доказывать — для этого и существует обсуждения в комментариях к статьям. Сразу сделать описание понятное для всех непросто.
Относительно кто кому должен доказывать — для этого и существует обсуждения в комментариях к статьям. Сразу сделать описание понятное для всех непросто.
Вот накидал на GridBagLayout.
Заняло времени пару минут. При этом универсально, гибко, кроссплатформенно. Можно чуть подправить Insets для щелей между компонентами, а также размер button итд… Выглядит шибко длинно, но это самый длинный и универсальный способ применённый в самом сыром виде. Можно обернуть сверху в конструктор с меньшим кол-вом параметров, если есть какие-то закономертности в вашем GUI. Или отнаследовать и видоизменить поведение по дефолту. У нас, например, в GridBag вычисляются insets автоматом, не используются ipadx, ipady итд итп.
frame.add( new JLabel(new ImageIcon(new URL(ICON_URL))), new GridBagConstraints( 0, 0, 1, 4, 0.0, 0.0, GridBagConstraints.SOUTH, GridBagConstraints.NONE, new Insets(0,0,0,0), 0, 0 ) );
frame.add( new JLabel("jLabel1"), new GridBagConstraints( 1, 0, 1, 1, 0.0, 0.0, GridBagConstraints.CENTER, GridBagConstraints.NONE, new Insets(0,0,0,0), 0, 0 ) );
frame.add( new JTextField("jTextField1",10), new GridBagConstraints( 2, 0, 1, 1, 1.0, 0.0, GridBagConstraints.WEST, GridBagConstraints.HORIZONTAL, new Insets(0,0,0,0), 0, 0 ) );
frame.add( new JButton( "..." ), new GridBagConstraints( 3, 0, 1, 1, 0.0, 0.0, GridBagConstraints.CENTER, GridBagConstraints.NONE, new Insets(0,0,0,0), 0, 0 ) );
frame.add( new JLabel("jLabel2"), new GridBagConstraints( 1, 1, 1, 1, 0.0, 0.0, GridBagConstraints.CENTER, GridBagConstraints.NONE, new Insets(0,0,0,0), 0, 0 ) );
frame.add( new JTextField("jTextField2",10), new GridBagConstraints( 2, 1, 2, 1, 1.0, 0.0, GridBagConstraints.WEST, GridBagConstraints.HORIZONTAL, new Insets(0,0,0,0), 0, 0 ) );
frame.add( new JLabel("jLabel3"), new GridBagConstraints( 1, 2, 1, 1, 0.0, 0.0, GridBagConstraints.CENTER, GridBagConstraints.NONE, new Insets(0,0,0,0), 0, 0 ) );
frame.add( new JPasswordField("jTextField3",10), new GridBagConstraints( 2, 2, 2, 1, 1.0, 0.0, GridBagConstraints.WEST, GridBagConstraints.NONE, new Insets(0,0,0,0), 0, 0 ) );
frame.add( new JButton("jButton1"), new GridBagConstraints( 2, 3, 2, 1, 0.0, 1.0, GridBagConstraints.SOUTHWEST, GridBagConstraints.NONE, new Insets(0,0,0,0), 0, 0 ) );
Заняло времени пару минут. При этом универсально, гибко, кроссплатформенно. Можно чуть подправить Insets для щелей между компонентами, а также размер button итд… Выглядит шибко длинно, но это самый длинный и универсальный способ применённый в самом сыром виде. Можно обернуть сверху в конструктор с меньшим кол-вом параметров, если есть какие-то закономертности в вашем GUI. Или отнаследовать и видоизменить поведение по дефолту. У нас, например, в GridBag вычисляются insets автоматом, не используются ipadx, ipady итд итп.
Ок, можно сравнивать.
Layoutless тоже «универсально, гибко, кроссплатформенно», это пропускаем.
Далее не буду повторяться, просто посмотрим на строку
frame.add( new JTextField(«jTextField1»,10), new GridBagConstraints( 2, 0, 1, 1, 1.0, 0.0, GridBagConstraints.WEST, GridBagConstraints.HORIZONTAL, new Insets(0,0,0,0), 0, 0 ) );
сравним с этим
.item(new ComponentBox()
.component(jTextField1)
.width(layoutless.width().minus(labelsWidth).minus(16).minus(50))
.height(22)
.x(labelsWidth+8)
.y(8+25*0)
)
Зададим вопрос:
является ли первый вариант более читабельным и локаничным чем второй?
Ну и сам собой напрашивается ответ — да это пистец какой-то. Вообще ничего невозможно разобрать.
Это ж не соревнование кто больше времени тратит на изучение кода который делает тривиальные вобщем-то вещи. Всего лишь форма с несколькими полями и кнопками.
Layoutless тоже «универсально, гибко, кроссплатформенно», это пропускаем.
Далее не буду повторяться, просто посмотрим на строку
frame.add( new JTextField(«jTextField1»,10), new GridBagConstraints( 2, 0, 1, 1, 1.0, 0.0, GridBagConstraints.WEST, GridBagConstraints.HORIZONTAL, new Insets(0,0,0,0), 0, 0 ) );
сравним с этим
.item(new ComponentBox()
.component(jTextField1)
.width(layoutless.width().minus(labelsWidth).minus(16).minus(50))
.height(22)
.x(labelsWidth+8)
.y(8+25*0)
)
Зададим вопрос:
является ли первый вариант более читабельным и локаничным чем второй?
Ну и сам собой напрашивается ответ — да это пистец какой-то. Вообще ничего невозможно разобрать.
Это ж не соревнование кто больше времени тратит на изучение кода который делает тривиальные вобщем-то вещи. Всего лишь форма с несколькими полями и кнопками.
является ли первый вариант более читабельным и локаничным чем второй?Да ну уж, прямо. В чём разница особая? По количеству кода или его содержанию никакой разницы нету. Вы просто пытаетесь выставить своё сугубо субъективное недовольство layout выставить как несомненную проблему swing-layout. Несмотря на то, что тысячи java-разработчиков кайфуют от именно такого, как им кажется, удобного механизма. И выше вам на это же явно указали другие юзеры. Я с ними соглашаюсь. Лаяуты в swing реализованы очень удобно и существуют на любой вкус и цвет, плюс возможность писать свои (тут вообще бесконечная гибкость потенциально). Поймите, это не значит, что ваш способ совсем гадкий или что-то типа такого. Это просто ваш личный велосипед, который удобен только вам, вот и всё.
Ну и сам собой напрашивается ответ — да это пистец какой-то. Вообще ничего невозможно разобрать.
Ну хорошо, давайте разберёмся. Итак, в чём «пистец» то? В том, что нет цепочки самовызовов? В том, что у вас куча поименованных методов? Или в том, что у меня код не в столбик? Конструктор можно сократить, ибо часть параметров (мной, например) никогда не используются (ipadx, ipady), часть напрямую зависит от других (weightx, weighty), итд итп. Это ведь вообще САМЫЙ полный вариант раскладки в свинге, можно на нём написать ВСЁ, причём не вычисляя в цифрах что куда подвинуть, как у вас, а описательно задавая решётку и расположение в нёй компонентов с кучей вариантов растяжения, расположения в ячейке итп. Если из моего кода убрать побочное/ненужное/отвлекающее внимание и расположить в столбик:
.add(
jTextField1,
new GridBagConstraints(
2, 0, //ячейка
1, 1, //размер ячейки в таблице, типа rowspan, colspan как в html (вроде правильно написал)
1.0, 0.0, //я в 99% тут использую всегда комбинации 1.0 и 0.0 в зависимости от указания растяжки ячейки и растяжки компонента в ней
GridBagConstraints.WEST, //расположение в ячейке
GridBagConstraints.HORIZONTAL, //растяжка
new Insets(0,0,0,0), //отступы от соседей, тут тоже можно сократить: задать константно или вычислять в зависимости от расположения в общей таблице
0, 0 // никогда не использую
));
Не понимаю где тут сложность. Причём это всё гармонично работает с указанными минимальными, prefered итп размерами. Кросплатформенен. Да да, именно так, на что вам обращают внимание. Да, это не поплывёт и учитывает DPI, направление письма (лево-право, сверху вниз итд итп, а ваш, а?) и кучу других параметров платформы.
Да и вообще ваш способ преследует совсем другую идеологию, нежели swing-layout, так что тут и сравнивать не очень-то корректно.
.add(
jTextField1,
2, 0, //ячейка
1, 1, //размер ячейки в таблице, типа rowspan, colspan как в html (вроде правильно написал)
new Insets(0,0,0,0), //отступы от соседей, тут тоже можно сократить: задать константно или вычислять в зависимости от расположения в общей таблице
));
Не понимаю где тут сложность. Причём это всё гармонично работает с указанными минимальными, prefered итп размерами. Кросплатформенен. Да да, именно так, на что вам обращают внимание. Да, это не поплывёт и учитывает DPI, направление письма (лево-право, сверху вниз итд итп, а ваш, а?) и кучу других параметров платформы.
Да и вообще ваш способ преследует совсем другую идеологию, нежели swing-layout, так что тут и сравнивать не очень-то корректно.
Честно говоря, мне очень не понравился ваш подход. 68 сторчек чтобы нарисовать форму с пятью элементами это чересчур много. Значения отступов читать и менять сложно, всевозможные 8+25*1 совершенно неочевидны, функция minus() взрывает мне мозг.
Вот девять строчек, который рисуют такую же форму при помощи MigLayout:
Swing — довольно сложный и не очень красивый фреймворк. Пожалуйста, не делайте его сложнее и уродливее!
Вот девять строчек, который рисуют такую же форму при помощи MigLayout:
JPanel panel = new JPanel( new MigLayout("fillx", "60[150]5[]0", "0[]7[]7[]push[]0")
panel.add( label1 );
panel.add( field1, "growx, split" );
panel.add( browse, "wrap );
panel.add( label2 );
panel.add( field2, "wrap" );
panel.add( label3 );
panel.add( field3, "wrap" );
panel.add( button1, "skip");
Swing — довольно сложный и не очень красивый фреймворк. Пожалуйста, не делайте его сложнее и уродливее!
с помощью этого кода получится такое окошко:
Сходство, скажем так, условное. Но если доработать напильником то можно добиться такого же внешнего вида как на первом скриншоте. Т.е. можно сравнивать MigLayout и Layoutless:
функционал — почти совпадает. Исключение — в MigLayout невозможно накладывать один компонент на другой т.е. сделать фоновую картинку с ключами непосредственно в определении компоновкой нельзя.
читабельность — так же как и у JGoodies FormLayout из предидущих каментов, догадаться что делает, скажем, «0[]7[]7[]push[]0» нельзя без чтения документации.
возможность допустить ошибку — также как и в JGoodies FormLayout легко ошибиться в константах и ошибка проявится только в рантайме
Итого
у MigLayout по сравнению с Layoutless меньше возможностей, хуже читабельность кода, больше вероятность допустить ошибку.
Сходство, скажем так, условное. Но если доработать напильником то можно добиться такого же внешнего вида как на первом скриншоте. Т.е. можно сравнивать MigLayout и Layoutless:
функционал — почти совпадает. Исключение — в MigLayout невозможно накладывать один компонент на другой т.е. сделать фоновую картинку с ключами непосредственно в определении компоновкой нельзя.
читабельность — так же как и у JGoodies FormLayout из предидущих каментов, догадаться что делает, скажем, «0[]7[]7[]push[]0» нельзя без чтения документации.
возможность допустить ошибку — также как и в JGoodies FormLayout легко ошибиться в константах и ошибка проявится только в рантайме
Итого
у MigLayout по сравнению с Layoutless меньше возможностей, хуже читабельность кода, больше вероятность допустить ошибку.
Вы, конечно, правы: я нарисовал не совсем то, что было на изначальной форме. Скажу честно, код этот я написал «из головы», не проверяя. Однако, нельзя не согласиться с тем, что используя MigLayout получилось на порядок меньше когда.
Думаю, что к Layoutless, как и к MigLayout надо привыкнуть. Что менее понятно, сказать сложно. Меня пугают функции вроде x(), вас пугает запись «0[]7[]7[]push[]0». Об этом сложно спорить.
В MigLayout меня очень привлекает возможность представить, как примерно выглядит форма глядя лишь на одну строчку. В Layoutless надо смотреть на весь код.
Наверное, другим минусом Layoutless может быть распространение констант. Все значения отступов, похоже, придётся вынести в константы. Если форма сложная, то констант будет много и легко будет забыть, что к чему. Если константами не пользоваться, то смена отступа станет очень непростым изменением.
Поймите меня правильно: вы написали очень интересный проект. Я заглянул в исходный код и изумился простоте основных классов и умелому применению binding'а. Я хочу лишь указать на сложности, которые заставили бы меня выбрать другой лейаут фреймворк.
Думаю, что к Layoutless, как и к MigLayout надо привыкнуть. Что менее понятно, сказать сложно. Меня пугают функции вроде x(), вас пугает запись «0[]7[]7[]push[]0». Об этом сложно спорить.
В MigLayout меня очень привлекает возможность представить, как примерно выглядит форма глядя лишь на одну строчку. В Layoutless надо смотреть на весь код.
Наверное, другим минусом Layoutless может быть распространение констант. Все значения отступов, похоже, придётся вынести в константы. Если форма сложная, то констант будет много и легко будет забыть, что к чему. Если константами не пользоваться, то смена отступа станет очень непростым изменением.
Поймите меня правильно: вы написали очень интересный проект. Я заглянул в исходный код и изумился простоте основных классов и умелому применению binding'а. Я хочу лишь указать на сложности, которые заставили бы меня выбрать другой лейаут фреймворк.
если нарисовать именно такую форму как в скриншоте то кода с MigLayout'ом будет не меньше. И будет он уже состоять из нетривиальных вещей.
по простоте представления (читабельности) — опять же можно сравнить конкретный код. У MigLayout: panel.add( field1, «growx, split» );
— без контекста абсолютно не ясно где это будет лежать. Причём в зависимости от спецификации в менеджере (эти самые «0[]7[]7[]push[]0») может иметь разное положение и поведение.
у Layoutless:
.item(new ComponentBox()
.component(jTextField1)
.width(layoutless.width().minus(labelsWidth).minus(16).minus(50))
.height(22)
.x(labelsWidth+8)
.y(8+25*0)
)
— вполне ясно где это находится и какого размера. И если зависит от других параметров (от размеров формы layoutless.width() например) то это сразу видно в определении самого компонента.
так что читабельность всё таки выше
Это скорей проблема всех статей
— если сделать простой пример то всем будет казаться что это очень просто и любым другим инструментом можно повторить
— если сделать сложный пример то мало кто разберётся
по простоте представления (читабельности) — опять же можно сравнить конкретный код. У MigLayout: panel.add( field1, «growx, split» );
— без контекста абсолютно не ясно где это будет лежать. Причём в зависимости от спецификации в менеджере (эти самые «0[]7[]7[]push[]0») может иметь разное положение и поведение.
у Layoutless:
.item(new ComponentBox()
.component(jTextField1)
.width(layoutless.width().minus(labelsWidth).minus(16).minus(50))
.height(22)
.x(labelsWidth+8)
.y(8+25*0)
)
— вполне ясно где это находится и какого размера. И если зависит от других параметров (от размеров формы layoutless.width() например) то это сразу видно в определении самого компонента.
так что читабельность всё таки выше
Это скорей проблема всех статей
— если сделать простой пример то всем будет казаться что это очень просто и любым другим инструментом можно повторить
— если сделать сложный пример то мало кто разберётся
By the way, credits: автором, видимо, была использована следущая иконка: 
:)
:)
Отлично! Очень понравилась ваша идея использовать DSL для задания лейаута. Сам использую MigLayout (считаю его полностью удовлетворяющим любые потребности), но его проблема в читабельности. Интересно было бы приготовить подобный DSL для MigLayout.
Вот ещё вариант с MigLayout:
— «строк» почти нет (при желани наверное и от этих можно будет избавиться)
— абсоютное позиционирование в MigLayout есть
— «строк» почти нет (при желани наверное и от этих можно будет избавиться)
— абсоютное позиционирование в MigLayout есть
JPanel pnl = new JPanel(new MigLayout(""));
CC tfConstraints = new CC().growX().width("100%").wrap();
pnl.add(new Label("label1"));
pnl.add(new JTextField(), tfConstraints);
pnl.add(new Label("label2"));
pnl.add(new JTextField(), tfConstraints);
pnl.add(new Label("label3"));
pnl.add(new JTextField(), tfConstraints);
pnl.add(new JButton("button1"), new CC().skip());
pnl.add(new JLabel("absolute"), new CC().pos("0","0"));
этот код сделает форму даже примерно не похожую на скриншот.
Да, есть куча компоновщиков с большим количеством возможностей. Ноесли сделать такую же форму как в первом скриншоте (вобщем-то ничего сложного нет, всего-то несколько полей и кнопок) то кода уйдёт на это больше чем в примере из статьи. Я уж не говорю о читабельности и пр.
Да, есть куча компоновщиков с большим количеством возможностей. Ноесли сделать такую же форму как в первом скриншоте (вобщем-то ничего сложного нет, всего-то несколько полей и кнопок) то кода уйдёт на это больше чем в примере из статьи. Я уж не говорю о читабельности и пр.
что именно не похоже?
то что у вас фиксирована ширина поля с паролем и кнопка уезжает вниз?
или нужно указать ширину колонки с JLabel?
то что у вас фиксирована ширина поля с паролем и кнопка уезжает вниз?
или нужно указать ширину колонки с JLabel?
да ничего не похоже. Это вроде сразу видно. Если сделать похоже (например чтоб кнопка "..." была по высоте как и поля, чтоб по таким же правилам размеры полей менялись, чтоб были отступы между надписями и границами и т.д.) то кода потребуется больше чем в примере из статьи.
А то что текст на кнопке в другом L&F может не поместиться вас не смущает? Если уж так хочется одинаковые размеры — надо размер текстового поля увеличивать под кнопку.
В MigLayout тоже можно все размеры жестко прописать как у вас только под каким-нибудь линуксом с другими шрифтами в фиксированное текстовое поле влезет только пол буквы в высоту.
В MigLayout тоже можно все размеры жестко прописать как у вас только под каким-нибудь линуксом с другими шрифтами в фиксированное текстовое поле влезет только пол буквы в высоту.
это вариант похож?
JPanel pnl = new JPanel(new MigLayout());
CC labelConstraints = new CC().gap("100lp");
pnl.add(new Label("label1"), labelConstraints);
pnl.add(new JTextField(), new CC().growX().width("100%").split().sizeGroupY("tfHeight"));
pnl.add(new JButton("..."), new CC().wrap().height("0!").sizeGroupY("tfHeight"));
pnl.add(new Label("label2"), labelConstraints);
pnl.add(new JTextField(), new CC().growX().width("100%").wrap());
pnl.add(new Label("label3"), labelConstraints);
pnl.add(new JPasswordField(), new CC().width("200lp").wrap());
pnl.add(new JButton("button1"), new CC().skip().pushY().alignY("bottom"));
pnl.add(new JLabel(new ImageIcon(new URL(ICON_URL))), new CC().pos("0",null,null,"100%"));
Данный код выдаст следующую форму:
Как видим, сходство с первым скриншотом почти полное, осталось добавить код чтобы сделать высоту кнопки "..." равной высоте текстовых полей и изменить размер отступа между полями.
Читабельность этой кучи констант и методов по сравнению с предидущими примерами применения MigLayout не изменилась. То же про вероятность ошибок и сложность изменения.
Это и есть итог обсуждения:
простую форму никому не удалось воссоздать с первого раза и точно как на картинке (понятно что возиться лень а на раз-два не выйдет).
Это концептуальная проблема выноса логики компановки в LayoutManager
— если сделать просто как в FlowLayout то функционала будет недостаточно
— если сделать многофункционально как GroupLayout то чрезмерная сложность будет затруднять рисование элементарных вобщем-то окошек
Этих проблем лишён Layoutless
— правила использования просты как правила игры в перетягивание каната
— binding позволяет добиться гибкости бОльшей чем есть у многих менеджеров компоновки
Как видим, сходство с первым скриншотом почти полное, осталось добавить код чтобы сделать высоту кнопки "..." равной высоте текстовых полей и изменить размер отступа между полями.
Читабельность этой кучи констант и методов по сравнению с предидущими примерами применения MigLayout не изменилась. То же про вероятность ошибок и сложность изменения.
Это и есть итог обсуждения:
простую форму никому не удалось воссоздать с первого раза и точно как на картинке (понятно что возиться лень а на раз-два не выйдет).
Это концептуальная проблема выноса логики компановки в LayoutManager
— если сделать просто как в FlowLayout то функционала будет недостаточно
— если сделать многофункционально как GroupLayout то чрезмерная сложность будет затруднять рисование элементарных вобщем-то окошек
Этих проблем лишён Layoutless
— правила использования просты как правила игры в перетягивание каната
— binding позволяет добиться гибкости бОльшей чем есть у многих менеджеров компоновки
наиболее точно проблемы использования менеджеров компоновки отражены тут:
http://habrahabr.ru/blogs/java/127339/#comment_4204183
http://habrahabr.ru/blogs/java/127339/#comment_4204183
Допустим, это всё замечательно. Но, если привязываться к пикселям, как быть с различным DPI?
Пусть уж будут абсолютные координаты, но нужны какие-то условные единицы.
Пусть уж будут абсолютные координаты, но нужны какие-то условные единицы.
DPI это количество точек на дюйм (Dots per inch). Касается он физичесикх размеров монитора либо распечатанного материала. Все менеджеры компоновки работают с пикселами, не понимаю зачем про этот DPI вообще спрашивать.
А шрифты-то не в пикселях.
Попытаюсь объяснить.
Можно настроить разрешение экрана в виндовс на 1024х768. Точно такое же разрешение можно сделать и на нетбуке с экраном 11" по диагонали и на офисном мониторе 20" по диагонали.
В результате DPI на нетбуке будет почти в два раза ниже чем на офисном компе. Можно взять линейку и посчитать количество пикселов на дюйм.
DPI это термин из полиграфии, никакие менеджеры компоновки его не учитывают.
Можно настроить разрешение экрана в виндовс на 1024х768. Точно такое же разрешение можно сделать и на нетбуке с экраном 11" по диагонали и на офисном мониторе 20" по диагонали.
В результате DPI на нетбуке будет почти в два раза ниже чем на офисном компе. Можно взять линейку и посчитать количество пикселов на дюйм.
DPI это термин из полиграфии, никакие менеджеры компоновки его не учитывают.
Для «прототипирования», в особенности Веб-приложений, мне очень понравился ZK. Так даже в
www.zkoss.org/zksandbox/ следующий код
<window title="My First XUL Win" border="normal" height="222px" width="500px"> <vbox> <hbox> <vbox> <image src="http://icons.iconarchive.com/icons/custom-icon-design/pretty-office-5/128/keys-icon.png"/> </vbox> <vbox> <hbox> jLabel1<textbox id="txt1" value="zTextField1" /><button label="..." onClick='alert( "hello !");txt1.value="hello"' /> </hbox><hbox> jLabel2<textbox id="txt2" value="zTextField2" /> </hbox><hbox> jLabel3<textbox type="password" value="zTextField3" /> </hbox> <button label="zButton1" onClick='alert( "Habr !");txt2.value="Habrahabr"' /> </vbox> </hbox> </vbox></window>
трансформируется в достаточно симпатичный и уже даже чуточку функциональный
[img src=«zazki.googlecode.com/hg/src/main/resources/ZK1.png» alt=«image»/]
zazki.googlecode.com/hg/src/main/resources/ZK1.png
ЗЫ
никто не знает как включить линки + картинки+ HTML-тэги? Без них как то не информативно всё…
www.zkoss.org/zksandbox/ следующий код
<window title="My First XUL Win" border="normal" height="222px" width="500px"> <vbox> <hbox> <vbox> <image src="http://icons.iconarchive.com/icons/custom-icon-design/pretty-office-5/128/keys-icon.png"/> </vbox> <vbox> <hbox> jLabel1<textbox id="txt1" value="zTextField1" /><button label="..." onClick='alert( "hello !");txt1.value="hello"' /> </hbox><hbox> jLabel2<textbox id="txt2" value="zTextField2" /> </hbox><hbox> jLabel3<textbox type="password" value="zTextField3" /> </hbox> <button label="zButton1" onClick='alert( "Habr !");txt2.value="Habrahabr"' /> </vbox> </hbox> </vbox></window>
трансформируется в достаточно симпатичный и уже даже чуточку функциональный
[img src=«zazki.googlecode.com/hg/src/main/resources/ZK1.png» alt=«image»/]
zazki.googlecode.com/hg/src/main/resources/ZK1.png
ЗЫ
никто не знает как включить линки + картинки+ HTML-тэги? Без них как то не информативно всё…
З.Ы. а как форма ведёт себя при ресайзе?
А если попробовать уголки, а не квадратные скобки?
Это то, чего Вы добивались?
А если попробовать уголки, а не квадратные скобки?
Это то, чего Вы добивались?
на скриншоте видно как форма ведёт себя при ресайзе. В статье и в каментах сравнивается не функционал (он достаточный) а простота достижения цели, читабельность кода, лёгкость модификации макета и вероятность допустить ошибки.
>>>>RE: «Это то, чего Вы добивались?»:::
C уголками — вот так (между «начало» и «конец»)
начало
конец
Но за попытку спасибо! Вероятно от захабренности зависит, как работает :-\
>>>: З.Ы. а как форма ведёт себя при ресайзе?
Ну а для лайоута нужно его указывать, что бы он работал. Там не сложно, например: www.zkoss.org/zkdemo/layout/complex_border_layout
C уголками — вот так (между «начало» и «конец»)
начало
конец
Но за попытку спасибо! Вероятно от захабренности зависит, как работает :-\
>>>: З.Ы. а как форма ведёт себя при ресайзе?
Ну а для лайоута нужно его указывать, что бы он работал. Там не сложно, например: www.zkoss.org/zkdemo/layout/complex_border_layout
а что насчет использования JavaFX? я думаю там можно найти то что автор предлагает в статье…
Да это вобщем-то примерно то что выйдет в JavaFX этой осенью. Только здесь чистый Swing и с биндингом получше.
На похожих принципах можно компоновать содержимое форм в .NET
http://msdn.microsoft.com/en-us/library/system.windows.forms.control.anchor%28v=vs.71%29.aspx
и во Flex'е
http://livedocs.adobe.com/flex/3/html/help.html?content=size_position_5.html
На похожих принципах можно компоновать содержимое форм в .NET
http://msdn.microsoft.com/en-us/library/system.windows.forms.control.anchor%28v=vs.71%29.aspx
и во Flex'е
http://livedocs.adobe.com/flex/3/html/help.html?content=size_position_5.html
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Layout без layout'ов