Comments 71
Полезный материал. В избранное.
Еще бы все java приложения по умолчанию в gtk использовали gtk'шные же настройки, аля --laf com.sun.java.swing.plaf.gtk.GTKLookAndFeel
Установить его — 2 строчки, так что это не самое страшное все-же :)
само собой, но куда приятнее когда открыл, и сразу получил привычное оформление :)
Ну на Windows, скажем, тоже не WindowsLookAndFeel по умолчанию стоит — если писать кроссплатформенное приложение с нативным стилем — в любом случае придется проставлять стиль для каждой ОС отдельно (по хорошему).
Помимо оформления если бы еще FileOpenDialog был у Java-приложений не свой, уродский, а родной системный :(
Я почему-то всегда любил Metal. Вот не знаю почему, но нравится он мне :) За Synthetica спасибо, выглядит наименее чужеродно и наиболее отстранённо от платформ.
Metal был очень хорош на тот момент, когда он только появился. Мы даже решили его оставить в паре крупных проектов. Плюс на всех платформах одинаково смотрится приложение, не нужно ничего подгонять и оптимизировать в интерфейсе.
Сейчас он смотрится немного устаревшим, как мне кажется. Но это сугубо мое мнение :)
Сейчас он смотрится немного устаревшим, как мне кажется. Но это сугубо мое мнение :)
Согласен, немного старовато смотрится, но от этого он не становится хуже. Чисто визуально мне приятно на него смотреть. Но это тоже моё личное мнение и ощущение.
Поддерживаю. Тоже к Metal прикипел всей душой. Еще Ocean очень люблю. Но вот новый Nimbus… его облик целиком и полностью взят с Mac'ов. Да и ладно, я б даже рад был, но к сожалению копия бездарная! Смотря на него я каждый раз задаюсь вопросом, кто в тогдашней еще Sun занимался дизайном? Программисты?..
А какие, собственно, в нем баги?
Как-то смотрел, но никаких фатальных косяков за ним не заметил — просто по стилю тогда не подошел.
Как-то смотрел, но никаких фатальных косяков за ним не заметил — просто по стилю тогда не подошел.
Это очень странно, учитывая то что даже в примере, который можно запустить с указанной Вами страницы, есть кнопки с иконками и они вполне себе работают. Плюс на багтрэкере у них по этому поводу тоже ничего. Возможно это просто очень давно было?
Большое спасибо за исчерпывающий обзор в данной области, ссылки и примеры.
Да не за что — всегда рад осветить полезную информацию :)
На самом деле, в пост хотелось бы вместить намного больше, но тогда это была бы уже не статья, а целая повесть, так что пришлось максимально ужимать материал. Впрочем, думаю я еще много всего интересного опишу в дальнейших топиках — главное, чтобы было достаточно времени на них.
На самом деле, в пост хотелось бы вместить намного больше, но тогда это была бы уже не статья, а целая повесть, так что пришлось максимально ужимать материал. Впрочем, думаю я еще много всего интересного опишу в дальнейших топиках — главное, чтобы было достаточно времени на них.
Очень подробная статья, автор старался. Но за последние 10 лет статей на тему Java UI c уклоном в «засучим рукава и напишем свой paintComponent» накопилось в избытке. Чего катастрофически не хватает и по сей день, так это толковых руководств к систематическому использованию Java UI фреймворков.
Новички (и не только!) часто находятся перед горой разноцветных виджетов, словно малые дети перед лего конструктором. Им поятно, что вот «это» можно воткнуть в «то» и высветится «гыгы», но дальше-то что?
Информацию по архитектуре UI призодится вылавливать по крупицам или добывать методом наступания на различные грабли. Что такое UI-Delegate и чем он отличается от MVC?
Чем отличается MVC от MVP? Где поместить логику приложения? Следят ли UI-Виджеты за изменениями в модели? А наоборот? Какие есть на сегодняшний день толковые Data Binding решения для свинга и есть ли они вообще?
Если автор действительно постарается
то, пожалуй, стоит начать с макромира Java UI, а уж потом углубляться в микроскопические детали.
Новички (и не только!) часто находятся перед горой разноцветных виджетов, словно малые дети перед лего конструктором. Им поятно, что вот «это» можно воткнуть в «то» и высветится «гыгы», но дальше-то что?
Информацию по архитектуре UI призодится вылавливать по крупицам или добывать методом наступания на различные грабли. Что такое UI-Delegate и чем он отличается от MVC?
Чем отличается MVC от MVP? Где поместить логику приложения? Следят ли UI-Виджеты за изменениями в модели? А наоборот? Какие есть на сегодняшний день толковые Data Binding решения для свинга и есть ли они вообще?
Если автор действительно постарается
изложить самые важные и значимые на мой взгляд моменты по работе со Swing и графикой
то, пожалуй, стоит начать с макромира Java UI, а уж потом углубляться в микроскопические детали.
Спешу не согласиться насчет:
> за последние 10 лет статей на тему Java UI c уклоном в «засучим рукава и напишем свой paintComponent» накопилось в избытке
Возможно их и множество, но по 2-3 строчки на каждом ресурсе сложно назвать исчерпывающей информацией — её также приходится искать по крупицам.
В эту статью я хотел уместить некую поверхностную часть. Далее же можно будет перейти и к макромиру Java UI, к описанию взаимодействия компонентов и их моделей и прочим внутренним вещам. Впрочем эта тематика достаточно объемная и спорная и достаточно сложно будет уместить что-то толковое в один пост.
> за последние 10 лет статей на тему Java UI c уклоном в «засучим рукава и напишем свой paintComponent» накопилось в избытке
Возможно их и множество, но по 2-3 строчки на каждом ресурсе сложно назвать исчерпывающей информацией — её также приходится искать по крупицам.
В эту статью я хотел уместить некую поверхностную часть. Далее же можно будет перейти и к макромиру Java UI, к описанию взаимодействия компонентов и их моделей и прочим внутренним вещам. Впрочем эта тематика достаточно объемная и спорная и достаточно сложно будет уместить что-то толковое в один пост.
Рекомендую «JGoodies Looks» — качественная настраиваемая шкурка: www.jgoodies.com/downloads/libraries.html
Пример параметров запуска приложения:
--cp:p /jgoodies-common-x.x.x.jar:/jgoodies-looks-x.x.x.jar
--laf com.jgoodies.looks.plastic.Plastic3DLookAndFeel
-J-DPlastic.defaultTheme=InvertedColorTheme
Пример параметров запуска приложения:
--cp:p /jgoodies-common-x.x.x.jar:/jgoodies-looks-x.x.x.jar
--laf com.jgoodies.looks.plastic.Plastic3DLookAndFeel
-J-DPlastic.defaultTheme=InvertedColorTheme
Jide имеет commons компоненты под одной из свободных лицензий.
Думаю, что многих удерживает от изучения или разработки на Java вопросы «как сделать оформление своего приложения ярким и запоминающимся?»
А я, вот, думаю, что многих удерживает от разработки десктопного софта на Java как раз обратное: «как сделать оформление своего приложения стандартным, не отлтчающимся, в случае Windows, от приложений на C#/WinForms, C++/MFC, WinAPI и т.п.?»
Сам я пишу на Scala (объектно-функционально производной Java, если кто не знает) и лично меня от написания на ней GUI-софта с использованием этой самой Swing удерживает ещё и отсутствие удобной визуальной IDE как VisualStudio для C# и NetBeans для Java (да, NetBeans поддерживает Scala через плагин, но не для дизайна форм). А от написания собственно на Java удерживает тот факт, что после Scala на Java смотришь уже как на QuickBasic после VB.Net или отечественную машину после хорошей иномарки — с ностальгией и удивлением что умудрялся этим пользоваться.
Честно говоря визуальной IDE при разработке интерфейса никогда не пользуюсь (только если в качестве накидать-посмотреть и то потом не использую получившийся код). В ней достаточно долго и муторно подгонять небольшие мелочи и оттачивать интерфейс.
Впрочем это конечно дело вкуса.
Насчет сравнения Scala-Java ничего не скажу, так как пока-что со Scala не имел возможности поработать, но думаю она еще появится.
Впрочем это конечно дело вкуса.
Насчет сравнения Scala-Java ничего не скажу, так как пока-что со Scala не имел возможности поработать, но думаю она еще появится.
А чем они особо отличаются? Лично я не заметил такого.
> как сделать оформление своего приложения стандартным, не отличающимся, в случае Windows, от приложений на C#/WinForms, C++/MFC, WinAPI и т.п.?
UIManager.setLookAndFeel ( UIManager.getSystemLookAndFeelClassName () ) — и будет Вам счастье на той же Windows. Или Вы говорите о каких-то отдельных элементах?
Может конечно где-то очень мелкими частями внешний вид и отличается, но при небольшом видоизменении его не отличишь.
К примеру, не понятно зачем, в стандартном WindowsComboBoxUI есть бордер, которого у нативных Win-комбобоксов не наблюдается. В сумме — есть несколько таких не особо бросающихся в глаза мелочей.
UIManager.setLookAndFeel ( UIManager.getSystemLookAndFeelClassName () ) — и будет Вам счастье на той же Windows. Или Вы говорите о каких-то отдельных элементах?
Может конечно где-то очень мелкими частями внешний вид и отличается, но при небольшом видоизменении его не отличишь.
К примеру, не понятно зачем, в стандартном WindowsComboBoxUI есть бордер, которого у нативных Win-комбобоксов не наблюдается. В сумме — есть несколько таких не особо бросающихся в глаза мелочей.
Отличная статья! Мне особенно понравился настрой автора: на Swing действительно можно написать почти всё, что угодно.
Хочется привести ссылки на пару библиотек, которые показались мне очень полезными:
1. Miglayout — это библиотека для позиционирования компонентов на панели. Работать с ней очень просто. При создании layout'а указывается, где что должно находиться (например,
2. Timing Framework сильно помогает при создании достаточно сложных анимаций. Увы, анимации делать не тк просто как, скажем в jQuery, но вполне возможно.
Хочется привести ссылки на пару библиотек, которые показались мне очень полезными:
1. Miglayout — это библиотека для позиционирования компонентов на панели. Работать с ней очень просто. При создании layout'а указывается, где что должно находиться (например,
"fillx", "5[]5[]5", "10[]10[]10"
создаст таблицу с двумя колонками и двумя рядами. Расстояние между колонками будет пять пикселей, между рядами — 10. При изменении размера таблица будет расти по в ширину, но не в высоту. 2. Timing Framework сильно помогает при создании достаточно сложных анимаций. Увы, анимации делать не тк просто как, скажем в jQuery, но вполне возможно.
Miglayout — интересная штука, ранее не встречал. Чем-то на формы в JGoodies похоже.
Насчет анимации — я предпочитаю, если уж и делаю что-то эдакое, не использовать библиотек на эту тему. Впрочем ничем серьезным не занимался в этой области, поэтому и обхожусь без них.
А анимацию на кнопках и других контролах я бы не назвал «настоящей» анимацией.
P.S. Еще насчет лэйаутов — я по большей части использую 3 лэйаута — BorderLayout, FlowLayout и TableLayout. Иногда еще GridLayout, но очень редко.
По большей части все же TableLayout — он позволяет сделать практически все что угодно, а главное быстро и легко. Правда кое-где я использовать свою версию, в которой было сделано обновление размеров и получение некоторых параметров.
Насчет анимации — я предпочитаю, если уж и делаю что-то эдакое, не использовать библиотек на эту тему. Впрочем ничем серьезным не занимался в этой области, поэтому и обхожусь без них.
А анимацию на кнопках и других контролах я бы не назвал «настоящей» анимацией.
P.S. Еще насчет лэйаутов — я по большей части использую 3 лэйаута — BorderLayout, FlowLayout и TableLayout. Иногда еще GridLayout, но очень редко.
По большей части все же TableLayout — он позволяет сделать практически все что угодно, а главное быстро и легко. Правда кое-где я использовать свою версию, в которой было сделано обновление размеров и получение некоторых параметров.
Обязательно посмотрите этот Miglayout. Он очень напоминает TableLayout. Разработчики добавили туда кучу полезных фич (например, debug). Я теперь только BorderLayout и Miglayout использую.
Ну, как минимум, для некоторых случаев он будет весьма удобен, но не думаю что для всех. Плюс к нему еще привыкнуть надо :)
Что-то Alloy как-то незаслужено обошли стороной. На мой взгляд это лучший LaF на сегодня. Несмотря на то, что последняя версия вышла в далеком 2004-м году, он работает шустрее и не грузит систему так как Synthetica или Substance.
Любители IntelliJ IDEA привет!
Любители IntelliJ IDEA привет!
Согласен — незаслуженно. Добавил в список.
Сам использую этот стиль в IDEA на самом деле :)
Сам использую этот стиль в IDEA на самом деле :)
Alloy во-первых, коммерческий, во-вторых уже лет пять как не развивается, в-третьих, не поддерживает сглаживание шрифтов. Тем не менее, наверное лучший LaF, который когда-либо был сделан для Java.
Ну коммерческий или нет — особого значения не имеет. Имеет значение функциональность, поддержка продукта и его развитие.
Даже учитывая, что он уже не развивается, он вполне себе живет и процветает во многих современных приложениях.
Даже учитывая, что он уже не развивается, он вполне себе живет и процветает во многих современных приложениях.
Да сглаживание шрифтов это ведь решаемо. Переопределить метод paintComponent > выставить там Rendering Hints… и будут в Alloy гладкие шрифты. Ну в общем вы, уверен, знаете… Вот то, что платный он — вот это самая досадная штука. Досадная потому, что покупать этот LaF сейчас не имеет смысла — проект стоит уже более пяти лет, а по сети гуляет ключ к нему, забесплатно — бери и юзай… Да и дороговато просят… Использовать же Alloy на широкую ногу в своих проектах, с тем же ломаным ключом, вроде как тоже нельзя — Alloy по-прежнему остается коммерческим. Вот и не знаешь что делать… Досадно ужасно, красивый и качественный LaF.
Мы его где-то лет пять назад и купили, после того, как увидели интерфейс JProfiler-а. И пользуем до сих пор. А со сглаживанием все сложнее. Переопределять paintComponent для всех компонентов свинга — дело накладное. Есть пара методов, например установить свой RepaintManager. Но с untrusted апплетами не работает.
> Переопределять paintComponent для всех компонентов свинга — дело накладное.
На самом деле, в большинстве случаев все-равно с каждым элементом идет куча стандартных настроек — в итоге и без необходимости переопределения paintComponent рано или поздно накапливается «дублирующий» Swing'овые компоненты набор. Да и компонентов там на амом деле не так много — не более 15-20 :)
На самом деле, в большинстве случаев все-равно с каждым элементом идет куча стандартных настроек — в итоге и без необходимости переопределения paintComponent рано или поздно накапливается «дублирующий» Swing'овые компоненты набор. Да и компонентов там на амом деле не так много — не более 15-20 :)
Немного поздно, но все же…
Обновил примеры статьи — выложил дополнительно все примеры и все исходные коды сгрупированно.
Обновил примеры статьи — выложил дополнительно все примеры и все исходные коды сгрупированно.
Что-то я не могу понять, а что мешает использовать SWT?
Так как он нативен, то отпадают все проблемы, с отображением контролов в стиле системы.
Так как он нативен, то отпадают все проблемы, с отображением контролов в стиле системы.
Извините за возможно глупый вопрос, а JavaFx можно прикрутить к этому делу, ну например, анимированная кнопка написанная на JavaFx?
Насчет JDIC я писал в предыдущей статье и решил повторно не упоминать :)
К тому же по тематике к данной статье не совсем подходило.
Насчет корректно алиасенного кастомного окна — через установку shape'а окна это не пройдет — форма будет без алиаса. Тут есть хитрость (о которой я вроде бы упоминал в статье?) — необходимо установить окну setUndecorated(екгу) и AWTUtilities.setWindowOpaque(window, false) и поверх него рисовать форму.
Вот небольшой пример реализации:
P.S. Извиняюсь за поздний ответ — пропустил уведомление мимо глаз :(
К тому же по тематике к данной статье не совсем подходило.
Насчет корректно алиасенного кастомного окна — через установку shape'а окна это не пройдет — форма будет без алиаса. Тут есть хитрость (о которой я вроде бы упоминал в статье?) — необходимо установить окну setUndecorated(екгу) и AWTUtilities.setWindowOpaque(window, false) и поверх него рисовать форму.
Вот небольшой пример реализации:
public class CustomShapeWindow extends JFrame
{
public CustomShapeWindow () throws HeadlessException
{
super ( "Кастом фрейм" );
getContentPane ().add ( new JComponent()
{
{
setOpaque ( false );
}
protected void paintComponent ( Graphics g )
{
super.paintComponent ( g );
Graphics2D g2d = ( Graphics2D ) g;
g2d.setRenderingHint ( RenderingHints.KEY_ANTIALIASING,
RenderingHints.VALUE_ANTIALIAS_ON );
g2d.setPaint ( Color.LIGHT_GRAY );
g2d.fillRoundRect ( 0, 0, getWidth (), getHeight (), 100, 100 );
}
} );
setUndecorated ( true );
AWTUtilities.setWindowOpaque ( this, false );
setSize ( 400, 400 );
setLocationRelativeTo ( null );
setVisible ( true );
}
public static void main ( String[] args )
{
new CustomShapeWindow ();
}
}
Это конечно самый базовый вариант. Можно использовать метод paint() окна, а не компонента в нем, и далее располагать поверх компоненты как Вам удобно. Можно отрисовывать на панели и поверх нее громоздить UI. Вариантов уйма.P.S. Извиняюсь за поздний ответ — пропустил уведомление мимо глаз :(
Отличная статья. Нашел кое-что новое для себя =)
Для приложения нужен нормальный (удобный, компактный) color chooser. Из-за одного компонента неохота тащить лишних 3Мб, особенно учитывая то, что само приложение весит меньше мегабайта. Есть ли способ выбить из библиотеки только WebColorChooserField и необходимые ему классы?
С последней версией это будет сделать сложнее т.к. сам color chooser теперь использует UI вместо отдельного компонента. Можно попробовать расковырять WebColorChooserUI и вынуть из него панель на которой все компоненты закреплены. В целом — она должна вполне нормально работать и отдельно от WebLaF, если вынести всё лишнее.
Мда, пожалуй, проще свой chooser написать.
Можете просто взять за основу некоторые сложные части, а в остальном да — проще написать свою альтернативу, если конечно размер приложения настолько критичен для вас. В целом сейчас плюс-минус пара метров в размере десктопного приложения ничего не решат (в разумных границах, естественно), если только вы не собираетесь показывать этот color chooser в апплете.
Sign up to leave a comment.
Улучшаем интерфейс Java-приложения