Именно поэтому сы сейчас немного изменяем и вскоре представим на всеобщий суд демо-лицензии.

P.S. Я, конечно, не Станислав но лучше осведомлен в данном вопросе ;)

Основным ограничением демо-версии является отсутствие возможности сохранения проектов.

В скором времени с обзором продукта мы выложим здесь уникальные двухмесячные тестовые тестовые лицензии, дающие доступ ко всей функциональности продукта.

Хех, а я то еще подумал, не имели ли Вы ввиду ту самую картинку… Ну не может же быть… ;)

Предлагаете прилюдно казнить нашего дизайнера?)
Мы уже пытали её на тему заигрывалась ли она в WorldOfGoo, но расколоть так и не удалось.

На самом деле, похожа только идея головы, как мне кажется…
Впрочем это всё слишком высокие материи, так что я не буду спорить на эту тему.

А способ взаимодействия с заказчиком и процесса разработки может быть абсолютно разным у разных фирм. Так как мы исходно ориентировались на свою и знакомые нам фирмы — возможно их специфика сыграла свою роль и видоизменила некоторый функционал и исходную идею.

Впрочем, раз мы рассчитываем продвигать продукт в «широкие массы» — непременно исправимся и подкорректируем все возникшие несоответствия.

Собственно, сам фреймворк видел одним глазом, но не совсем понимаю, как он относится непосредственно к теме?..

Можем и расскажем, но уже в детальном обзоре самого продукта, который мы вскоре разместим.

Я не спорю, что некоторого функционала на данный момент еще недостает (как впринципе и в любом развивающемся продукте). Как Вы и сказали — необходима возможность размещать встроенные комментарии и подсказки по всему прототипу, чтобы было ясно что для чего предназначено в прототипе.

Но насчет того, что такие прототипы не стоит показывать заказчику — я не согласен. Много уже всего писали по данной теме, к примеру, что подробные прототипы отвлекают внимание заказчика от общих целей проекта. Но в то же время скетчи могут вызвать в итоге множество неточностей в реализации, которые очень прилично съедают времени при переписывании.

Это лишь один частный пример — у обоих вариантов есть и плюсы и минусы, о которых неоднократно писалось в различных источниках, поэтому, мне кажется, здесь все совсем неоднозначно.

Игрулину мы, конечно, заметили, но уже после того, как порешили с лого… В любом случае, связи тут особо никакой нет. Может в будущем найдем что поуникальнее ;)

ImageJ действительно упустил, но она уже достаточно старовата и, действительно, тормозная. Как-то давно пробовал ее как вариант для написания редактора изображений — в итоге отказался и сделал все по-своему.

Насчет SwingWT, QTJambi, LaF, Flamingo и JavaFX — это все не совсем соответствует содержанию данного топика. Я сейчас как-раз делаю новый топик по UI в Java-приложении — там всё это и много больше будет включено и описано.

JavaFX как вариант для проигрывания видео, все же, я исключаю, так как речь идет о J2SE (конкретнее даже — о Swing-интерфейсе) и использовать там JavaFX будет весьма накладно или даже невозможно.

> Под конец, многие java-девелоперы хотят, чтобы их продукт выглядел как нативная апликация и был независим от JVM.
> Помимо платного Excelsion JET можно порекоммендовать связку GCJ+SWT(SwingWT).
> Он хоть и уступает в производительности, но компенсирует за счет быстрого старта и нативного SWT.
Это впринципе абсолютно другая тема и как мне кажется, нет смысла прибегать к разным исхищрениям, чтобы использовать Java для разработки Windows only приложения. Врочем это отдельная тема для холивара, думаю не стоит его тут разводить.

Эх, планы планы… Надеюсь, они таки дозреют до выпуска новой версии в скором времени.
Хотя, конечно, сам список их планов достаточно внушающий. Хорошо если команда разработки его потянет в адекватные сроки.

Насчет «собрать из исходников» я говорил конкретно про Ваш случай — если Вам она все еще необходима в 64-разрядном виде — это возможно.
А насчет тех кто только обучается — согласен, добавлю чуть позже ссылки на доступные версии библиотек :)

> реализации для 64-разрядной JVM, что и логично ввиду архаизма ее — нет
Думаю вполне возможно пересобрать ее под 64x из исходников

> что бы найти «отдельный набор библиотек» нормальной сборки, потратил не менее получаса
Думаете, есть смысл разместить дополнительно ссылки к разным версиям библиотек?

Не знал, действительно поддерживает :)
Спасибо что подсказали — подправил в статье.

Кстати, Native Swing потому так и назван, что позволяет использовать интересные фичи SWT в обычных Swing-приложениях. Что-то до меня поздно дошла суть вопроса правда :)

Прочитал подробнее и посмотрел сайт проекта:
«The WebKit for SWT project has been discontinued and downloads are no longer available»
Увы, проект закрыт и найти даже устаревшую библиотеку где-либо я не смог.
Возможно у Вас где-то сохранилась копия самой библиотеки?

Хотя смысла о ней говорить вероятно нет, учитывая что проект закрыт (причем, вроде, достаточно давно) и обновлений не ожидается…

Насчет WebKit — спасибо за информацию — раньше не встречал никакой информации о нем.
Вероятно потому, что пока-что с SWT вплотную много не работал.

> Он уже морально устарел и со Swing его использовать точно не стоит
Я бы даже поправил себя — его впринципе не стоит использовать ;)

Ну, AWT это вообще другая история :)
Он уже морально устарел и со Swing его использовать точно не стоит

А про «Event Dispatcher thread и всякие такие штуки» — действительно смешивать интерфейсы лучше не стоит. Но когда речь идет об отдельных окнах с разным интерфейсом или же отдельных диалогах — все достаточно культурно.
Насчет смешивания самих интерфейсных частей — я еще посмотрю потом, самому интересно что будет.