Comments 40
Пишите еще!
И скоро каждый из читателей напишет свой лукандфил для своих рабочих проектов. Так сказать с блекджеком :) Сарказм конечно. Врага нужно знать в лицо.
И скоро каждый из читателей напишет свой лукандфил для своих рабочих проектов. Так сказать с блекджеком :) Сарказм конечно. Врага нужно знать в лицо.
Ну напишет или нет — дело самого читателя :)
Но более-менее адекватно описать «что и как» я всё-таки постараюсь, ибо подобного описания я толком найти нигде не смог.
Кстати, я был бы только ЗА, если бы появилось больше желающих развивать Swing-направление (в частности — написанием большего количества LaF, пусть даже коммерческих), так как оно сейчас, мягко говоря, отошло на второй план у Oracle, что весьма печально.
Но более-менее адекватно описать «что и как» я всё-таки постараюсь, ибо подобного описания я толком найти нигде не смог.
Кстати, я был бы только ЗА, если бы появилось больше желающих развивать Swing-направление (в частности — написанием большего количества LaF, пусть даже коммерческих), так как оно сейчас, мягко говоря, отошло на второй план у Oracle, что весьма печально.
Раз уж Нимбус стал дефолтным с седьмой джавы и уже давно есть в шестой, то логичнее новые проекты по созданию LaF начинать все-таки с простого переопределения пэйнтеров в Нимбусе. Там большинство работы уже сделано за вас.
Тут есть пара моментов, из-за которых этого делать, как мне кажется, не стоит…
Во-первых — 7ое JDK очень долго будет входить в полноценное использование.
Во-вторых — Вы видели те самые пейнтеры? Я вот видел — волосы дыбом встают.
Такое ощущение, что этот код писали далеко не руками (может это и так, ибо были упоминания о том, что есть некий NimbusDesigner?). Учитывая это — переопределение пейнтеров нимбуса займёт ещё больше времени и будет гораздо менее читаемо и изменяемо, в отличии от описанного мной способа.
Если не верите, могу написать и показать реализацию какого-либо компонента из NimbusLaF «по старинке» — к примеру взять прогресс-бар.
Может, конечно, Nimbus на выходе будет немного более оптимален в своих отрисовках, но эту разницу можно также сгладить, поработав над кодом.
В итоге лично я не вижу выигрыша в случае наследования Nimbus-пейнтеров (по крайней мере на данный момент). Конечно хотелось бы иметь что-то более человечное, но мне кажется это пока-что мечты…
Во-первых — 7ое JDK очень долго будет входить в полноценное использование.
Во-вторых — Вы видели те самые пейнтеры? Я вот видел — волосы дыбом встают.
Такое ощущение, что этот код писали далеко не руками (может это и так, ибо были упоминания о том, что есть некий NimbusDesigner?). Учитывая это — переопределение пейнтеров нимбуса займёт ещё больше времени и будет гораздо менее читаемо и изменяемо, в отличии от описанного мной способа.
Если не верите, могу написать и показать реализацию какого-либо компонента из NimbusLaF «по старинке» — к примеру взять прогресс-бар.
Может, конечно, Nimbus на выходе будет немного более оптимален в своих отрисовках, но эту разницу можно также сгладить, поработав над кодом.
В итоге лично я не вижу выигрыша в случае наследования Nimbus-пейнтеров (по крайней мере на данный момент). Конечно хотелось бы иметь что-то более человечное, но мне кажется это пока-что мечты…
Код нимбуса не ковырял, возможно он и сгенерирован.
Дело в том что в UI классах кроме отрисовки еще куча логики содержится. Порой ее не хотелось бы трогать, или в BasicUI каких-либо фич из Нимбуса может не быть, а тут не нужно откатываться на BasicUI.
А так да, на проекте пытался довести GUI до более-менее косистентного вида на Metal, Nimbus, GTK и Windows. Это адъ. Если Ваш WebLaF на мавене будет, и его буду рад потестить :)
Дело в том что в UI классах кроме отрисовки еще куча логики содержится. Порой ее не хотелось бы трогать, или в BasicUI каких-либо фич из Нимбуса может не быть, а тут не нужно откатываться на BasicUI.
А так да, на проекте пытался довести GUI до более-менее косистентного вида на Metal, Nimbus, GTK и Windows. Это адъ. Если Ваш WebLaF на мавене будет, и его буду рад потестить :)
Собственно — NimbusDesigner вроде как будет визуальным редактором для LaF/UI (правда я не представляют как они уместят туда всё необходимое), если его доведут таки до ума и откроют.
Насчёт логики — я изучал часть исходных кодов Nimbus — могу заверить — там логики (именно логики работы, а не логики отрисовки компонента) не сильно больше чем в Basic UI классах. Именно поэтому я и предлагаю наследоватсья от них — большая часть необходимого уже есть там — остаётся только подверстать внешний вид.
WebLaF, думаю, смогу выложить и на Maven (или только туда) — четно говоря с этим ещё не определился (какие плюсы-минусы?). А пока что проект (самая последняя версия исходников) хостится на нашем внутреннем SVN. Ранее собирался на Google code выложить, но теперь есть сомнения…
Насчёт логики — я изучал часть исходных кодов Nimbus — могу заверить — там логики (именно логики работы, а не логики отрисовки компонента) не сильно больше чем в Basic UI классах. Именно поэтому я и предлагаю наследоватсья от них — большая часть необходимого уже есть там — остаётся только подверстать внешний вид.
WebLaF, думаю, смогу выложить и на Maven (или только туда) — четно говоря с этим ещё не определился (какие плюсы-минусы?). А пока что проект (самая последняя версия исходников) хостится на нашем внутреннем SVN. Ранее собирался на Google code выложить, но теперь есть сомнения…
Если вы будете делать L&F на Synth (на котором основан Nimbus), то с удивлением узнаете, что в нем нельзя сделать выделенный (например, когда вы проводите над ним мышкой) задизейбленный пункт меню. Кроме этого есть еще и просто несколько багов, ограничивающих возможности задания свойств L&F. Эти баги не влияют на Nimbus, а потому возможно никогда не будут исправлены. При этом самому переопределить классы и исправить их нельзя — их нужно копировать (по крайней мере в java 6).
Честно говоря так глубоко в Synth/Nimbus не заглядывал, так как мне кажется сейчас впринципе невозможно на их основе что-то толковое написать (точнее возможно, но для этого нужно иметь целую команду, которая будет возиться со всеми мелочами и проблемами, иначе уйдёт вечность).
Но заметка, однозначно, интересная.
Инетересно, кстати, есть ли написанные под Nibus/Synth расширения/LaF (даже если коммерческие)?
Множество тех LaF/UI что я видел использовали Basic/Component UI за базу.
Но заметка, однозначно, интересная.
Инетересно, кстати, есть ли написанные под Nibus/Synth расширения/LaF (даже если коммерческие)?
Множество тех LaF/UI что я видел использовали Basic/Component UI за базу.
UFO just landed and posted this here
Есть много проблем, связанных с нативным внешним видом приложений. Особенно если Ваше приложение немного (или намного) сложнее, чем просто «табличка-тулбарчик-двекнопки».
Фактически весь «геморрой» делится на два направления:
— Поддержание своего LaF, но с любыми желаемыми плюшками
— Использование готовых/нативных и, естественно, никаких плюшек (либо изобретение велосипедов)
Я уж не говорю о том, что для опрятного оформления приложения придётся (даже при использовании нативных LaF) городить системо-зависимые части, ибо стандартное расположение компонентов и их вид (включая настройки общие для всех систем) по гайдлайнам разных систем абсолютно разные.
Фактически весь «геморрой» делится на два направления:
— Поддержание своего LaF, но с любыми желаемыми плюшками
— Использование готовых/нативных и, естественно, никаких плюшек (либо изобретение велосипедов)
Я уж не говорю о том, что для опрятного оформления приложения придётся (даже при использовании нативных LaF) городить системо-зависимые части, ибо стандартное расположение компонентов и их вид (включая настройки общие для всех систем) по гайдлайнам разных систем абсолютно разные.
Собственно, после двух лет «возьни» с нативным LaF я пришёл к выводу, что первый вариант, хоть и затратен на первых парах, но зато гораздо более удобен и приспосабливаем.
Тем более Вы в любом момент простым движением руки можете поменять поведение того или иного компонента, что невозможно или весьма затратно для нативного LaF'а.
Аналогично с оформлением — нативный LaF привязывает Вас к тому набору компонентов, который имеется в Swing или же реализован по образу и подобию LaF'а в сторонних библиотеках (таких, сразу скажу, мало), ибо всё остальное будет выглядеть глазовыдерающе на фоне нативного стиля.
Тем более Вы в любом момент простым движением руки можете поменять поведение того или иного компонента, что невозможно или весьма затратно для нативного LaF'а.
Аналогично с оформлением — нативный LaF привязывает Вас к тому набору компонентов, который имеется в Swing или же реализован по образу и подобию LaF'а в сторонних библиотеках (таких, сразу скажу, мало), ибо всё остальное будет выглядеть глазовыдерающе на фоне нативного стиля.
А что скажете за Substance (Очень приятный LaF имхо)? Ковырялись в нем?
Жаль что Кирилл забил болт на Substance…
Жаль что Кирилл забил болт на Substance…
Ковырялся конечно, но не так глубоко, как хотелось бы (а что собственно интересует?) :)
А сейчас даже уже не найду исходников, да и выкачать толком неоткуда, чтобы изучить…
Substance один из лучших реализованных LaF'ов. Исходно я даже рассматривал возможность его использования заместо написания своего LaF, но не удовлетворили некоторые визуальные реализации компонентов и некоторые другие мелочи. Ну и, собственно, что самое главное — поддержка/живость проекта — было бы очень неприятно отказываться от него, если бы на очередном обновлении JDK что-то слетело.
Всего я знаю 3 достойных LaF:
Alloy — он, вроде как, ещё продаётся, но не обновлялся века
Synthetica — этот тоже коммерческий, но всё ещё живой
И, сосбтвенно, Substance, который, к сожалению, более не поддерживается
Есть ещё несколько неплохих LaF'ов, но по оформлению/возможностям они сильно уступают этим трём.
Можете вот тут глянуть разные LaF'ы, если ещё не видели ресурс: www.javootoo.com
А сейчас даже уже не найду исходников, да и выкачать толком неоткуда, чтобы изучить…
Substance один из лучших реализованных LaF'ов. Исходно я даже рассматривал возможность его использования заместо написания своего LaF, но не удовлетворили некоторые визуальные реализации компонентов и некоторые другие мелочи. Ну и, собственно, что самое главное — поддержка/живость проекта — было бы очень неприятно отказываться от него, если бы на очередном обновлении JDK что-то слетело.
Всего я знаю 3 достойных LaF:
Alloy — он, вроде как, ещё продаётся, но не обновлялся века
Synthetica — этот тоже коммерческий, но всё ещё живой
И, сосбтвенно, Substance, который, к сожалению, более не поддерживается
Есть ещё несколько неплохих LaF'ов, но по оформлению/возможностям они сильно уступают этим трём.
Можете вот тут глянуть разные LaF'ы, если ещё не видели ресурс: www.javootoo.com
Кирилл выложил все исходники на гитхабе.
Он там внутрях своего LaF-а замутил всякие анимации и прочие вкусности.
А вместо субстанца теперь есть его форк и делает его Danno Ferrin
Он там внутрях своего LaF-а замутил всякие анимации и прочие вкусности.
А вместо субстанца теперь есть его форк и делает его Danno Ferrin
Да, форк вот только что нашёл в дебрях сети.
А насчёт анимации — честно говоря пока не смотрел.
Имхо в большинстве случаев анимацию компонентов лучше либо реализовывать оптимальными средствами прямо внутри UI, либо вообще забыть об этом. Всё таки LaF может сильно повлиять на скорость работы приложения, если будет сильно перегружен.
Я, конечно, поигрался с анимацией в паре мест, не буду лукавить, но постарался реализовать её максимально безопасно. Впрочем, ещё посмотрю что там есть на эту тему :)
А за ссылку на гитхаб спасибо, как дойдут руки — покопаюсь.
А насчёт анимации — честно говоря пока не смотрел.
Имхо в большинстве случаев анимацию компонентов лучше либо реализовывать оптимальными средствами прямо внутри UI, либо вообще забыть об этом. Всё таки LaF может сильно повлиять на скорость работы приложения, если будет сильно перегружен.
Я, конечно, поигрался с анимацией в паре мест, не буду лукавить, но постарался реализовать её максимально безопасно. Впрочем, ещё посмотрю что там есть на эту тему :)
А за ссылку на гитхаб спасибо, как дойдут руки — покопаюсь.
И про JTatoo пару слов. Ковырялся в нем однажды и понял что он раза в три медленнее Metal работает, потому как градиенты рисует.
Не думаю всё же что градиенты — корень зла, хотя сам и не видел что там внутри творится.
При корректном использовании отрисовка градиентов не создаёт практически никакой нагрузки.
Кстати, даже если JTatoo или ещё какой LaF работает медленнее (точнее сказать, медленее отрисовывает те или иные элементы) — это не повод отказываться от него. Более сложное и опрятное оформление так или иначе потребует большего количества кода и сложности отрисовки, что неизбежно влечёт замедление отрисовки — с этим ничего не поделать. Но пока отрисовка отрабатывает в адекватные промежутки времени и не вызывается зазря — имхо проблем использовать LaF быть не должно.
При корректном использовании отрисовка градиентов не создаёт практически никакой нагрузки.
Кстати, даже если JTatoo или ещё какой LaF работает медленнее (точнее сказать, медленее отрисовывает те или иные элементы) — это не повод отказываться от него. Более сложное и опрятное оформление так или иначе потребует большего количества кода и сложности отрисовки, что неизбежно влечёт замедление отрисовки — с этим ничего не поделать. Но пока отрисовка отрабатывает в адекватные промежутки времени и не вызывается зазря — имхо проблем использовать LaF быть не должно.
Можете чтонибудь про методы измерения производительности (performance) LaF'ов рассказать? Может есть какие бенчмарки? Да и вообще как можно в свинге/awt чтонибудь померить :)
Это весьма абстрактная тема — точно так же как попросить методы измерения производительности некоторого приложения X. Каждый LaF реализован абсолютно по-своему (кто на что горазд, да), и, соответственно, сложно подвести всё их многообразие под одну черту.
Собственно известных мне средств, заточенных под тестирование производительности Swing интерфейса, нет. Может таковые и существуют, но я лично в этом сомневаюсь.
Если рассматривать частные случаи — можно измерять время отрисовки тех или иных компонентов (непосредственно скорость отработки метода paintComponent при том или ином LaF) вручную проставляя «замерщики» в компонентах или прямо в UI классах, если имеется исходный код. Я делаю именно так при оптимизации неудачных частей интерфейса и улучшаю/изменяю алгоритм и отрисовку до тех пор, пока компонент не будет съедать, менее 1-2 мс на полную отрисовку.
Даже не знаю, что ещё можно было бы посоветовать для этого дела…
Собственно известных мне средств, заточенных под тестирование производительности Swing интерфейса, нет. Может таковые и существуют, но я лично в этом сомневаюсь.
Если рассматривать частные случаи — можно измерять время отрисовки тех или иных компонентов (непосредственно скорость отработки метода paintComponent при том или ином LaF) вручную проставляя «замерщики» в компонентах или прямо в UI классах, если имеется исходный код. Я делаю именно так при оптимизации неудачных частей интерфейса и улучшаю/изменяю алгоритм и отрисовку до тех пор, пока компонент не будет съедать, менее 1-2 мс на полную отрисовку.
Даже не знаю, что ещё можно было бы посоветовать для этого дела…
Я могу ошибаться, но мне кажется что скорость отрисовки зависит от 3D ускорителя и активирована ли в jvm отрисовка интерфейса через 3D акселератор. Какие бы графические навороты не использовались бы при отрисовки интерфейса то при включенной функции ускорения интереса через 3D, она будет отрисованна мгновенно. В 7ке эта функция включена по умолчанию, в 6ке её кажется нужно активировать ключами. Правда она появилась не сразу а после какого-то апдейта.
Скорость отрисовки, естественно, зависит от различных параметров системы, но…
Мгновенно ничего не бывает, увы. Действительно, при использовании подобных средств скорости могут взлетать на 5-10 порядков, но всегда можно наворотить такого, что даже на самом новом железе будет тормозить. И дело там будет совсем не в том, что системе не хватает средств на отрисовку.
Любая графическая или алгоритмическая операция, выполняемая при отрисовке элементов занимает некоторое время, путь это будут даже наносекунды. При наличии огромного количества подобных операций время складывается и выходят вполне значимые величины, ведь в Swing вся отрисовка интерфейса происходит в одном потоке, в отличие, скажем, от нативных виндовых компонентов. Именно поэтому в Swing есть множество оптимизаций, появившихся, если мне не изменяет память, в версии 1.4, когда, тогда ещё, Sun взялся всерьёз за проблему скорости работы интерфейса (и результаты были внушительные).
«Какие бы графические навороты не использовались бы при отрисовки интерфейса то при включенной функции ускорения интереса через 3D, она будет отрисованна мгновенно»
Мгновенно ничего не бывает, увы. Действительно, при использовании подобных средств скорости могут взлетать на 5-10 порядков, но всегда можно наворотить такого, что даже на самом новом железе будет тормозить. И дело там будет совсем не в том, что системе не хватает средств на отрисовку.
Любая графическая или алгоритмическая операция, выполняемая при отрисовке элементов занимает некоторое время, путь это будут даже наносекунды. При наличии огромного количества подобных операций время складывается и выходят вполне значимые величины, ведь в Swing вся отрисовка интерфейса происходит в одном потоке, в отличие, скажем, от нативных виндовых компонентов. Именно поэтому в Swing есть множество оптимизаций, появившихся, если мне не изменяет память, в версии 1.4, когда, тогда ещё, Sun взялся всерьёз за проблему скорости работы интерфейса (и результаты были внушительные).
но я все же с интересом смотрю на javafx. В сивингах они сделали все что можно было сделать. Особенности кросплатформности накладывают ограничения, но не сильные, а преимущества огромные. Но все же они развиваются дальше и пытаются привнести стиль веб программирования на десктопы. Это тоже интересно.
В свинге они сделали далеко не всё, что можно было бы, просто кому-то явно приспичело реализовать новый проект и тянуть его заместо Swing — не более. Я не знаю чем конкретно они руководствовались при выборе, но мне он кажется весьма сомнительным.
Анимацию, различные эффекты и прочий сахар, который добавляет JavaFX — давно уже реализован так или иначе в сторонних библиотеках для Swing — где-то более оптимально, где-то менее. Впрочем это не мешает интегрировать схожие адекватные средства в Swing, нежели открывать отдельную интерфейсную ветку.
Анимацию, различные эффекты и прочий сахар, который добавляет JavaFX — давно уже реализован так или иначе в сторонних библиотеках для Swing — где-то более оптимально, где-то менее. Впрочем это не мешает интегрировать схожие адекватные средства в Swing, нежели открывать отдельную интерфейсную ветку.
Эх, эту бы статью, да года три назад…
Самому бы хотелось в своё время найти подобный «мануал» и не мучаться над неясными мелочами и ошибками, но что поделать…
Помню, как шерстил код и матерился на полное отсутствие документации именно по этому вопросу. Были некоторые сведения в книгах, но не помогало. Так и бросил java, не сделав желаемый интерфейс. Перешел в веб-программирование.
Хех, очень давно тоже пытался начать с нуля, но бросил по той же причине. В итоге через пару лет опять вернулся к необходимости заняться этим делом…
Собственно, за пару лет удалось долгим путём проб и ошибок пробиться к желаемому результату :)
Но действительно поражает, что до сих пор не вышло ни одного толкового описания на эту тему. Максимум статьи по работе с графикой и не более.
Собственно, за пару лет удалось долгим путём проб и ошибок пробиться к желаемому результату :)
Но действительно поражает, что до сих пор не вышло ни одного толкового описания на эту тему. Максимум статьи по работе с графикой и не более.
Я до сих пор встречаю программы, которые пишут на AWT. У swing большая проблема с производительностью. Тот же swt или awt хоть и сложнее, и имеют меньше возможностей, но работают на порядок быстрее. Да и парадигма о том, что системный laf единственно правоверный до сих пор доминирует в умах людей.
Честно говоря, впервые слышу про проблемы производительности в Swing — он как раз таки был оптимизирован и заточен для большей производительности. Другой вопрос, что неумеючи можно такого наворотить… Видимо оттуда сплетни и растут.
Насчёт парадигмы — даже многие Mac'овые приложения уже давно используют свою стилизацию, которая ничем не хуже или даже лучше подходит к приложению. Виндовые так и вовсе — кто во что горазд. Так что мне кажется, что скоро останутся лишь те, кто любит только повозмущаться насчёт «несистемности» приложения, но реальных доводов «против» там не будет.
Насчёт парадигмы — даже многие Mac'овые приложения уже давно используют свою стилизацию, которая ничем не хуже или даже лучше подходит к приложению. Виндовые так и вовсе — кто во что горазд. Так что мне кажется, что скоро останутся лишь те, кто любит только повозмущаться насчёт «несистемности» приложения, но реальных доводов «против» там не будет.
Спасибо за статью, полезно, жду продолжения. И вообще интересна тема создания своих новых элементов управления
Всегда пожалуйста :)
Насчёт создания новых элементов — думаю это будет во 2ой, а может даже 3ей части.
Я имею в виду именно создание стилизуемого посредством UI компонента, конечно же.
Насчёт создания новых элементов — думаю это будет во 2ой, а может даже 3ей части.
Я имею в виду именно создание стилизуемого посредством UI компонента, конечно же.
По javafx не будет подобных обзоров? Тем более, что они обещают тесную интеграцию со swing.
Думаю что будут, но не в ближайший месяц.
Я пока только начинаю копаться с JavaFX и мне направление, пока что, кажется весьма сомнительным. Там действительно есть несколько моментов, которых в Swing сложно или невозможно реализовать, но они не настолько критичны, чтобы соскочить с места и перепрыгнуть в «лагерь» JavaFX. Да и косяков там немеряно на данный момент — иногда вообще не ясно ты ли накосячил или нет.
Я пока только начинаю копаться с JavaFX и мне направление, пока что, кажется весьма сомнительным. Там действительно есть несколько моментов, которых в Swing сложно или невозможно реализовать, но они не настолько критичны, чтобы соскочить с места и перепрыгнуть в «лагерь» JavaFX. Да и косяков там немеряно на данный момент — иногда вообще не ясно ты ли накосячил или нет.
Да и, кстати, тесную интеграцию пока-что только обещают…
Как только она действительно появится (я не говорю о разных затычках и хаках) — будет реальный повод более подробно описать что и как работает/взаимодействует и какие плюсы можно получить от подобной интеграции.
Как только она действительно появится (я не говорю о разных затычках и хаках) — будет реальный повод более подробно описать что и как работает/взаимодействует и какие плюсы можно получить от подобной интеграции.
Уважаемый автор, почему хабр показывает мне source code вместе c html что с этим можно сделать? Скрин:
Помогите пожалуйста
Помогите пожалуйста
Sign up to leave a comment.
Создаём свой Look and Feel — Часть I