Как стать автором
Обновить

Комментарии 71

Что же, спасибо :)
Надеюсь что много ещё кому пригодится изложенная информация
Не сомневайся))
Stroke.
Это единственная функцональность, которую я не знаю как можно «толково» перевести на русский язык...


Может «окантовка»?
Это логичный, но не совсем точный вариант.
Боюсь если бы я сказал — «установите окантовку ...» — меня бы вряд ли поняли бы…
Особенно те, кто в курсе что такое Stroke.

Хотя может мне только так кажется :)
Были ещё и другие идеи:
бордер / ход / граница
но как-то всё не то, всё же…
«штрих»?
Один из параметров конструктора BasicStroke является «dash» — это фактически и есть «штрих» (или «штрихи»). Так что вряд ли Stroke можно так назвать…
dash — черта, тире
Не угодишь Вам :)
Собтсвенно, и не спрашивал бы, если бы можно было обойтись одним словарём :)
Вообще ещё узнаю у одного знакомого, но уже завтра…
«Обводка»?
А вот это уже мысль :)
Наверное так и оставлю, спасибо за идею!
Dash — существительное:
тире
штрих
черта

В контексте Stroke — шрих, не иначе :)
Симпатичный LaF. Чем-то напоминает Alloy. Вставьте пожалуйста на сайт онлайн демо например с SwingSet2.
А для Graphics2D самая лучшая на сей момент библиотека — JavaFX :)
Очень сомневаюсь что оно так для всех.
Скажем крупные приложения, написанные на Swing очень вряд ли будут переводить на JavaFX.
Впрочем то же касается и новых приложений, ибо JavaFX сейчас в бете.

Насчёт демки — Вы имеете в виду добавить запускаемое через .jnlp демо на основе SwingSet2?
Если так — то идея достаточно хорошая, добавлю помимо основного демо.
Кстати насчёт Alloy — отчасти он вдозновил меня на идею написания своего LaF'а.
Хотелось что-то лёгкое, не напрягающее глаз, но при этом достаточно элегантное и приятное «на ощупь».
Есть конечно шероховатости ещё, но со временем они уйдут.
Да, Alloy был мой любимый laf, тока ему антиалайсинга шрифтов не хватало. Да, стоит демку с .jnlp или аплетом сунуть, чтобы сразу его можно было «пощупать». И спасибо за старания.
Думаю .jnlp добавлю. Но swing-set демки всё же не то — там мало что будет видно,
ведь помимо LaF'а есть ещё и доп. компоненты и многое другое.
В общем как закончу некоторые фиксы по библиотеке, займусь «презентабельным» видом :)
Пытаюсь подключить Web LAF к существующему проекту. JDK 1.6.0.22. Выдает exception
java.lang.NoClassDefFoundError: sun/swing/MenuItemLayoutHelper
at com.alee.laf.menu.WebMenuUI.paintMenuItem(WebMenuUI.java:109)

Какую версию JDK все же надо иметь, чтобы LAF заработал?
У Вас случаем не OpenJDK используется?
Да нет. Релиз под x86
Странно, вероятно данный класс появился в ещё более позднем релизе…
Я сейчас заменю его и выложу обновлённую версию, так как Вы уже не первый, кто сталкивается с его отсутствием.
Да я обновлю JDK — не проблема. Просто вы указывали что Web LAF доступен с JDK версии 1.6u20. Вот я и спросил.
Нет нет, он и должен быть доступен с той версии (даже, на самом деле, с ещё более ранней).
Так что в любом случае стоит прикрыть эту «дыру» :)
Обновил JDK. Заметил такой баг в меню. Если нет ни одной иконки то вертикальная черта пересекает текст
Да, это ещё одна причина использовать свой класс для определения размеров меню и элементов меню. Уже работаю над этим.
И еще, вы почему-то убрали кнопки из JScrollBar.
Честно говоря, за последний наверно год — не использовал эти кнопки ни в одном приложении, а места они отъедают прилично, если делать скролл шире для кнопок.
В общем, как мне кажется, весьма бесполезный функционал.

Может в дальнейшем просто оставлю возможность их отображать, но придётся для этого немного видоизменить сами скролл-бары.
Ну у меня используется для навигации между транзакциями. Так хотел заказчик.
Хм, сложно представить, честно говоря без представления о Вашем интерфейсе…
Словил такой exception и не могу открыть один из фреймов

java.lang.IllegalArgumentException: Start point cannot equalendpoint
  at java.awt.LinearGradientPaint.<init>(LinearGradientPaint.java:271)
  at java.awt.LinearGradientPaint.<init>(LinearGradientPaint.java:221)
  at java.awt.LinearGradientPaint.<init>(LinearGradientPaint.java:116)
  at com.alee.laf.toolbar.WebToolBarUI.paint(WebToolBarUI.java:185)


* This source code was highlighted with Source Code Highlighter.
Это случилось потому, что у Вас где-то используется JToolbar с нулевыми (или мизерными) размерами. Косяк я подправлю, но Вам тоже стоит посмотреть где же у Вас такое чудо :)

Хотя, может просто тулбар изначально появляется с нулевыми размерами и только потом сайзится. В таком случае это также возможно.
Да, есть такое чудо. Просто другие скины на это не ругались.
Да, это конечно косяк, уже подправил.
Остаётся только меню оживить…
Всё, поправил и перезалил на сайт (ссылки из этого топика ведут туда же, так что они тоже, фактически, обновлены).

Проблемы с меню также должны уйти (с некорректным расположением без иконок).
Кстати, у вас на сайте какая-то проблема с mime-type или Content-Disposition в download секции. Т.к. по клику на jar файл в хроме он начинает открываться в браузере вместо диалога загрузки.
Знаю, сейчас вот как раз трясу админа, чтобы он толково настроил отдачу файлов, так как я сам в настройке сайт-хостингов не силён :)
Слава гуглу, таки поправил эту проблему :)
Теперь всё должно нормально качаться
Почему-то кастомный JList с чекбоксами по типу такого
www.devx.com/tips/Tip/5342 не хочет работать. Галочки не ставятся
Ну и в ComponentOrientation.RIGHT_TO_LEFT, к сожалению, многое отображается не правильно
Редактируемые комбобоксы, почему-то, не отличаются по внешнему виду от нередактируемых.
Суть в том, что для рендереров и редакторов необходимы чекбоксы и радиокнопки без анимации, т.е. при создании модели с чекбоксами в том примере что вы указали необходимо отключить анимацию чекбоксов.
Я бы не обращал на это внимание, если бы это также некорректно работало в Substance, JTatto, JGoodies и т.д. Но в этих библиотеках все работает без дополнительных твиков.
Я наверное вас замучил? Если что — извините.
Я не уверен, но разве в указанных стилях присутствует анимация в чекбоксе?
Проблема возникает именно из-за неё.

Вообще я ещё добавлю достаточно много стилизованных рендереров и редакторов для всех случаев жизни, чтобы не нужно было этого делать руками.

Как и самих компонентов по типу чекбокс-списка, дерева и пр.
Как в отдельных компонентах анимация есть. А вот уже в JList она отсутствует. Видно где-то проверяется на глобальном уровне
Вы, кстати, там свой рендерер используете или какой готовый?
Просто если готовый — вероятно в нём проверяется.
Рендерер свой, который расширяет DefaultListCellRenderer. Если быть точнее то SubstanceDefaultListCellRenderer. Но я пробовал и с DefaultListCellRenderer — и все равно с вашим LAF были проблемы.
Ну дык, а попробуйте SubstanceLaF и DefaultListCellRenderer — вероятно что будут и у них проблемы :)
Попробовал. Проблема не наблюдается.
Ну тогда действительно глобально проверяется.
В любом случае я уже запланировал подобные вещи, буду допиливать возможность удобного использования рендереров.
В любом случае спасибо вам за труды. Вы делаете полезное дело. LAF выглядит вполне симпатично. Жаль, что пока не могу его использовать из-за отсутствия RTL поддержки и других мелких косяков.
Вам спасибо за наведение на неточности и ошибки.

Всё же очень бы хотелось услышать, где конкретно не учтён RTL и что за «другие мелкие косяки» (помимо кастомных рендереров). :)
Косяки я почти все указал:
— это кастомные рендереры;
— отсутствие кнопок в скролбаре;
— также заметил глюк, что не всегда отрисовывается прогрессбар. Только не удается найти условия, при которых это происходит. Могу сказать, что используется прогресс бар у меня в потоке SwingWorker'а в отдельном диалоговом окне.

В RTL:
— неправильно отображается меню (Иконки остаются слева, стрелочка подменю направлена не в ту сторону).
— подменю может уезжать на пикселей 20 от меню родителя.
— заголовок и иконка JInternalFrame уезжает куда-то
— кнопки управления JInternalFrame отображаются неправильно и не в том месте (остаются справа, когда должны уходить влево)
это то, что заметил при беглом тестировании
Ясно, буду править :)

Насчёт RTL в меню — страшно подумать зачем оно вовсе надо (но видимо надо). Это займет побольше времени.

JDesktopPane/JInternalFrame до конца толком ещё не стилизованы. Над ними ещё буду работать.

Насчёт прогресса — весьма странно. Нигде у себя не замечал подобных проблем (уже на реальных проектах).
RTL нужен для ряда языков, где письмо идет справа-на-лево.
Это то понятно, просто очень редко когда эта возможность реально необходима, мне кажется…

Тем более если приложение в рамках ru/en/de/fr языков.
Отнюдь вас не вынуждаю заниматься поддержкой RTL. Это действительно специфическая ситуация и это не стоит больших усилий с вашей стороны.
Ну отчасти поддержка уже присутствует, просто в некоторых отдельных компонентах были проблемы с этим и я отложил реализацию. В первой же стабильной версии-релизе RTL будет поддерживаться.
И нет, не замучали :)
Чем больше проблем получится устранить — тем лучше.
Отключить можно вот так:
WebCheckBox webCheckBox = new WebCheckBox ();
webCheckBox.setAnimated ( false );

Или же вот так:
JCheckBox checkBox = new JCheckBox ();
( ( WebCheckBoxUI ) checkBox.getUI () ).setAnimated ( false );
Чуть позже все подобные параметры можно будет также отключить и глобально для всего LaF'а.
Запустил пример в OpenJDK начал было радоваться что абсолютно все идентично с SunJDK, но все же один косяк вылез. В секции Textareas полетело все форматирование. Надеюсь этот косяк починят, как никак, но линия партии призывает всех переходить на OpenJDK. В остальном все отлично заработало, несмотря на то, что в OpenJDK есть известные проблемы с Java2D.
А можно более конкретно о том, что же полетело?
Точнее что подразумевается под форматированием?
Ubuntu 11.04. OpenJDK 1.6 выглядит как то так. Ресайз окна не влияет ни на что. Но в остальном все работает отлично. Больше никаких отличий в поведении от sunjdk не замечено. Я так думаю что лайот менеджер врет.
image
Всё проще — немного «кривое» поведение текстовых полей.
Я не задавал размеры полей (их на этой вкладке 3 разных), поэтому они и съехали.

«По хорошему» они должны были быть высотой в 4 строки каждый и preferred-ширины, но…
Видимо, стандартная реализациия getPreferredSize у BasicScrollPaneUI в OpenJDK отличается и скроллы просто наврали с размерами (с шириной по тексту и высотой по 4 строкам).

Я уже в процессе тестирования библиотеки под OpenJDK — постараюсь убрать все недочёты и сделать библиотеку ещё менее зависимой от таких вот «огрехов».

Чуть позже отпишу что нашлось по теме — изложенное выше лишь мои предположения (не безосновательные, конечно, но всё же).
Достать бы только OpenJDK под винду…
А то под виртуалкой это всё печально тестить
Да, это забавный квест. Я тоже пытался это сделать, но под виндой это можно сделать только из исходников. Причем компилировать нужно с помощью компилятора из cygwin в вижуал студии 2003… Мануал по компиляции напоминает сценарий фильма ужасов. Вообще, приемлемых способов установить OpenJDK под виндой нет, а значит и не будет пользователей, то и смысла тестировать нет. Лучше тестировать OpenJDK сразу на убунте. Проблем на виртуалке быть не должно, если конечно не использовать 3D. А если лень ставить вторую систему и не хочется возится с вируалкой, то можно установить нужный софт на LiveUSB.
Да, я уже прочитал мануал, порадовался списку необходимых вещей и операций…
И мееедленно устанавливаю новую убунту (как раз 11.04) — на ней и погоняю.

Просто VMWare как-то по чёрному сбоит на 7ке, пришлось переползти на VirtualBox.
Кстати, насчёт следующего обновления — оно будет включать доделки по UI JDesktopPane и JInternalFrame, фиксы для OpenJDK, LTR у компонентов и небольшие (но полезные) дополнения в UI кнопок. Возможно также и некоторые другие менее значимые мелочи.

Думаю что к этим выходным (может даже и раньше) обновление будет готово.

Останется только вопрос с JFileChooser/JColorChooser — с ними придётся поработать вплотную, чтобы переписать под мои готовые варианты.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий