Comments 64
оО Написали Qt для Java?..
Ребят, это бомба. Щупал zetes фреймворк месяцев 6 назад, не покидало ощущение волшебства, но смущала очень бедная библиотека. Я еще тогда подумал, вот бы андроидовские библиотеки туда — точно переписал бы на нем свое андроид апп. Сегодня мои мечты сбываются.
Спасибо огромное. Чувствую себя школьником, получившим пятёрку :)
Правда, на всякий случай — вдруг вы неправильно поняли. Оно — для desktop. Под android на нем приложение не сделать.
Что касается библиотек, то из Android там взяты только основные java-классы. Но если надо портировать Java-приложение c Android на PC, в какой-то степени ZetesWings вам, конечно, поможет.
Правда, на всякий случай — вдруг вы неправильно поняли. Оно — для desktop. Под android на нем приложение не сделать.
Что касается библиотек, то из Android там взяты только основные java-классы. Но если надо портировать Java-приложение c Android на PC, в какой-то степени ZetesWings вам, конечно, поможет.
я что-то не понял, так у вас свой GUI тулкит или SWT?
В качестве тулкита используется SWT. То есть окна, кнопки и менюшки рисует он. Но идеология SWT такова, что если вы пишете кроссплатформенное приложение и хотите, чтобы оно в каждом случае выглядело похожим на «родное», вам придется в куче мест писать проверки на то, под какой платформой вы находитесь, и выбирать, как выглядеть в данном случае. Обратите внимание, например, на окошко About.
Увы, девелоперы обычно не заморачиваются подобными вещами и кроссплатформенные приложения выглядят «чужими» под всеми платформами. Посмотрите, к примеру, на фотошоп под OS X.
Я написал основную идею в параграфе 2.
Цель — создать вокруг SWT такую обертку, чтобы она была одновременно гибкой и не грузила разработчика «культурными различиями». Но, увы, сделать эту обертку «непрозрачной» слишком сложно. Так что абстракция пока дырявая.
Увы, девелоперы обычно не заморачиваются подобными вещами и кроссплатформенные приложения выглядят «чужими» под всеми платформами. Посмотрите, к примеру, на фотошоп под OS X.
Я написал основную идею в параграфе 2.
Цель — создать вокруг SWT такую обертку, чтобы она была одновременно гибкой и не грузила разработчика «культурными различиями». Но, увы, сделать эту обертку «непрозрачной» слишком сложно. Так что абстракция пока дырявая.
Я работал 3 года в компании Zetes — название рождает странное чувство :)
Огромное спасибо! Я, как отчасти Java Desktop разработчик, мог только мечтать, что когда-нибудь появится такой проект.
Отдельное почтение за SWT. Все свои десктопные приложения теперь пишу только на нем.
P.S. Не увидел кнопки Donate.
Отдельное почтение за SWT. Все свои десктопные приложения теперь пишу только на нем.
P.S. Не увидел кнопки Donate.
Кнопка Donate находится в данный момент на GitHub и называется она «pull request».
Брать за эту штуку деньги я пока не хочу — во всяком случае до тех пор, пока не доведу ее до работоспособного состояния.
Брать за эту штуку деньги я пока не хочу — во всяком случае до тех пор, пока не доведу ее до работоспособного состояния.
Предлагаю пока Donate делать методом написания чего-нибудь на этом framework'е и отправкой bug report/feature request :)
P.S. Мы с bigfatbrowncat сейчас не сговаривались так отвечать :)
P.S. Мы с bigfatbrowncat сейчас не сговаривались так отвечать :)
Заведите, пожалуйста, google group в котором можно будет задавать вопросы. Вопросы возникают прям начиная с настройки IDE. И конечно хочется больше более «жирных» примеров. Работа с http, с графикой и так далее. Больше примеров с Android class library конечно хочется…
Всё будет понемногу.
Работу с IDE (то есть настройку eclipse) я собирался включить в эту статью, но она и так огромна, поэтому, думаю, напишу на wiki проекта zetes.
А вопросы и пожелания можете пока писать сюда или в личку. Мне или JustAMan.
По поводу работы с графикой — среди zetes-examples есть целых два проекта, использующих OpenGL (вы их видите на картинке в начале поста) — это GLDemo и OldLand.
Работу с IDE (то есть настройку eclipse) я собирался включить в эту статью, но она и так огромна, поэтому, думаю, напишу на wiki проекта zetes.
А вопросы и пожелания можете пока писать сюда или в личку. Мне или JustAMan.
По поводу работы с графикой — среди zetes-examples есть целых два проекта, использующих OpenGL (вы их видите на картинке в начале поста) — это GLDemo и OldLand.
Так GUI работает само по себе или поверх SWT?
но чем не устроил javafx? там и стилизация нормальная, и лишних библиотек не надо
Хотя бы лицензией. Здесь всё — «бери бесплатно, результат можешь продать» + отсутствие завязки на скачивание Oracle JRE, т.е. полученное приложение полностью автономно.
Ничем не устроил.
1. JavaFX тяжел и неповоротлив на слабых машинах.
2. JavaFX — проприетарная технология Oracle, а одна из задач этого проекта — лицензионная свобода.
3. JavaFX не выглядит «родным» ни в одной системе. Я про это писал чуть выше.
Возможно, я где-то ошибаюсь. Поправьте меня, если у меня неточные сведения.
1. JavaFX тяжел и неповоротлив на слабых машинах.
2. JavaFX — проприетарная технология Oracle, а одна из задач этого проекта — лицензионная свобода.
3. JavaFX не выглядит «родным» ни в одной системе. Я про это писал чуть выше.
Возможно, я где-то ошибаюсь. Поправьте меня, если у меня неточные сведения.
1. можно отключить режим opengl и запустить в 2д рендринге, только выглядеть будет не очень
2. javafx — это часть openjdk для начала, оракул добавил только пару расширений
3. нативный look-and-feel можно организовать через css стили
2. javafx — это часть openjdk для начала, оракул добавил только пару расширений
Differences between Open JDK and Oracle JDK with respect to JavaFX
Oracle JDK includes some software which is not usable from the OpenJDK. There are two main components which relate to JavaFX.
The ON2 VP6 video codec, which is owned by Google and Google have not open sourced.
The Oracle WebStart/Browser Embedded application deployment technology.
3. нативный look-and-feel можно организовать через css стили
Во-первых, без OpenGL оно будет еще медлительнее. OpenGL, пожалуй, главное преимущество JavaFX.
Во-вторых, вы, возможно, упустили тот факт, что под лицензионной свободой я, в том числе, подразумеваю свободу разработчика от ограничений GPL. И OpenJDK в этом смысле не годится. Именно создать ей альтернативу я и пытался.
В третьих, нативный look-and-feel можно создать только одним образом — отдать задачу рендера визуальных компонентов UI самой системе. Что, собственно, и делает SWT, в отличие ото всех других Java GUI библиотек. А попытка создавать его через css приведет к тому, что вы этот css будете писать под каждую версию системы свой. Или ваше приложение будет блестеть «стеклянными» кнопками под Windows 8, например.
Во-вторых, вы, возможно, упустили тот факт, что под лицензионной свободой я, в том числе, подразумеваю свободу разработчика от ограничений GPL. И OpenJDK в этом смысле не годится. Именно создать ей альтернативу я и пытался.
В третьих, нативный look-and-feel можно создать только одним образом — отдать задачу рендера визуальных компонентов UI самой системе. Что, собственно, и делает SWT, в отличие ото всех других Java GUI библиотек. А попытка создавать его через css приведет к тому, что вы этот css будете писать под каждую версию системы свой. Или ваше приложение будет блестеть «стеклянными» кнопками под Windows 8, например.
Если не изменяет память, JavaFX (как и Swing) не использует нативных виджетов ОС, а рисует окно сама силами VM. Так что портануть ее на такой проект займет годы. Да и, ИМХО, SWT справляется со своей задачей лучше JavaFX/Swing, по крайней мере на своих проектах я предпочтение отдаю именно SWT.
UFO just landed and posted this here
Рискну высказать непроверенное мнение, но, кажется, вы не сможете свой вариант, например, положить в Apple AppStore. А мой, думаю, сможете.
Хотя это требует уточнения.
Ну а еще — возможность слинковать один нормальный exe-шник без кучи валяющихся jar-файлов… Честолюбие, наверное.
Переписывать Java с нуля никто и не собирается. Кстати, о чем я забыл напомнить, проект, собранный на базе ZetesHands, прекрасно заработает на RaspberryPi, например.
Хотя это требует уточнения.
Ну а еще — возможность слинковать один нормальный exe-шник без кучи валяющихся jar-файлов… Честолюбие, наверное.
Переписывать Java с нуля никто и не собирается. Кстати, о чем я забыл напомнить, проект, собранный на базе ZetesHands, прекрасно заработает на RaspberryPi, например.
ой, не туда написал
Я так понимаю можно писать на groovy, scala или kotlin без особых проблем?
JRE вполне себе можно распространять, канонический пример — Intellij Idea. Для маководов — Packaging a Java App for Distribution on a Mac.
За ссылку спасибо — надо было мне не забыть про Code Signing…
А по поводу распространения — отвечу так: хочется альтернативы, свежей и чистой. Я люблю Java, но хочу думать, что любимый язык не пропадет как только от него по какой-то причине откажутся авторы. Я понимаю, что я — прожженый романтик и аргумент чисто идеалистический, но всё же…
А по поводу распространения — отвечу так: хочется альтернативы, свежей и чистой. Я люблю Java, но хочу думать, что любимый язык не пропадет как только от него по какой-то причине откажутся авторы. Я понимаю, что я — прожженый романтик и аргумент чисто идеалистический, но всё же…
UFO just landed and posted this here
опять промахнулся
Не подскажете, какой-нибудь удобный визуальный редактор GUI использовать можно? Хотелось бы в итоге получить что-то типа QtCreator
Если в качестве первого шага взяли SWT, то почему в качестве второго и третьего шагов не взять JFace и Eclipse RCP (особенно новую версию E4)? В самом деле, система вьюверов, меню и прочего в JFace не абсолютно завязана на SWT. Так же и E4 теоретически позволяет использовать другие рендереры. Чему подтверждение есть Rich AJAX Platform.
И JFace, и Eclipse RCP опираются на SWT. Поэтому никто их не мешает добавить отдельно, если они вам понадобятся. Включать же их по умолчанию я смысла не вижу — Zetes сделан в первую очередь для создания небольших приложений с отзывчивым интерфейсом, а это не подразумевает добавления слишком большого количества слоёв абстракции.
В любом случае, если я буду создавать еще одну абстракцию, в ее задачу будет входить в первую очередь обобщение UI в смысле выведения общих кроссплатформенных возможностей. И делать это придется в рамках самого Zetes.
В любом случае, если я буду создавать еще одну абстракцию, в ее задачу будет входить в первую очередь обобщение UI в смысле выведения общих кроссплатформенных возможностей. И делать это придется в рамках самого Zetes.
Звучит круто!
А какой размер hello-world получается при использовании Avian?
А какой размер hello-world получается при использовании Avian?
Порядка мегабайта. Посмотрите среди zetes-examples проект bellardpi. это — вычислялка числа Пи методом Беллара. Почти хеллоу-ворлд.
А если с минимальным простейшим GUI? Оно же на Avian Classpath под Windows завелось?
В этом смысле что GLTest, что TinyViewer — почти GUI-«Hello world», и вместе с SWT библиотеками занимает около 4.5 МБ. По сути где-то 3 мега — это SWT, его даже видно, если собрать пример и пошариться в obj/java/classpath.jar.
Консольный bellardpi весит 1.5 мега, т.е. по сути Авиан + его чистый classpath — это примерно 1.5 мега.
Консольный bellardpi весит 1.5 мега, т.е. по сути Авиан + его чистый classpath — это примерно 1.5 мега.
Лет триста назад я что такое был написал руками — custom JavaVM заточенную на UI — J-SMILE:
Этот вот exe на картинке содержит саму VM, classpath (свой полностью) и classes приложения. Все вместе 400k (под UPX — 120k).
Дело закончилось получением письма от Sun в то время. Почитал я его и сел писать свой Sciter.
Сейчас бы Oracle из меня душу вынул ибо реально сейчас sciter в том или ином виде работает на большем кол-ве PC чем кол-во PC на которых установлена Java.
В любом случае честно желаю успехов проекту.
Кстати рекомендую подумать про связку Zetes и Sciter. Sciter уже работает на всех desktop GUI платформах с одним и тем же API.
Иметь HTML/CSS/scriptable UI это в каком-то смысле правильно нынче. Сделать native UI в java по-хорошему не удастся. Да и не надо на самом деле.
Этот вот exe на картинке содержит саму VM, classpath (свой полностью) и classes приложения. Все вместе 400k (под UPX — 120k).
Дело закончилось получением письма от Sun в то время. Почитал я его и сел писать свой Sciter.
Сейчас бы Oracle из меня душу вынул ибо реально сейчас sciter в том или ином виде работает на большем кол-ве PC чем кол-во PC на которых установлена Java.
В любом случае честно желаю успехов проекту.
Кстати рекомендую подумать про связку Zetes и Sciter. Sciter уже работает на всех desktop GUI платформах с одним и тем же API.
Иметь HTML/CSS/scriptable UI это в каком-то смысле правильно нынче. Сделать native UI в java по-хорошему не удастся. Да и не надо на самом деле.
Снимаю перед вами шляпу и низко кланяюсь! Написать свою JVM — очень круто по моим представлениям. Oracle вас вряд ли стал бы трогать, потому что в главном сегменте, где они получают прибыль — Enterprise Solutions — вы даже носа не показали. А остальное для них — мелочи.
Если бы у вас была лицензия либеральная — связался бы. А так, увы, нам не по пути. Коммерческих решений в сегменте кроссплатформенного GUI — куча. Я бы хотел развить некоммерческое.
Я посмотрел на вашу страничку — я так понимаю, что мне можно было бы добиться подобного эффекта, добавив движок браузера какого-то, скажем, chromium-embedded, к моему проекту. Возможно, я даже попробую что-то такое сделать, хотя пока я хочу стабильной работы для простых приложений. Так что в ближайшее время, думаю, zetes не станет вам конкурентом ;)
Вот тут не согласен по обоим пунктам. Собственно, ради этого во многом мой проект и затевался. Просто у большинства в сознании отложилось намертво «Java = тормоза» и «Java = кривой GUI». Кстати, о тормозах — Avian местами обгоняет обычную JVM! Например, при работе с JNI в обычной API для того, чтобы передать блок данных из нативной памяти в управляемую, необходимо память копировать. Avian же позволяет залочить массив «снизу» и гарантирует, что массив в JVM соответствует просто массиву из Си. Таким образом удается работать через JNI с любыми блоками данных напрямую. В прочих случаях он на пару процентов медлительнее, хоть и тоже является JIT-компилятором. Но при разработке интегрированного решения скорость может быть такая, что вы на глаз от приложения на C не отличите.
Если бы у вас была лицензия либеральная — связался бы. А так, увы, нам не по пути. Коммерческих решений в сегменте кроссплатформенного GUI — куча. Я бы хотел развить некоммерческое.
Я посмотрел на вашу страничку — я так понимаю, что мне можно было бы добиться подобного эффекта, добавив движок браузера какого-то, скажем, chromium-embedded, к моему проекту. Возможно, я даже попробую что-то такое сделать, хотя пока я хочу стабильной работы для простых приложений. Так что в ближайшее время, думаю, zetes не станет вам конкурентом ;)
Сделать native UI в java по-хорошему не удастся. Да и не надо на самом деле.
Вот тут не согласен по обоим пунктам. Собственно, ради этого во многом мой проект и затевался. Просто у большинства в сознании отложилось намертво «Java = тормоза» и «Java = кривой GUI». Кстати, о тормозах — Avian местами обгоняет обычную JVM! Например, при работе с JNI в обычной API для того, чтобы передать блок данных из нативной памяти в управляемую, необходимо память копировать. Avian же позволяет залочить массив «снизу» и гарантирует, что массив в JVM соответствует просто массиву из Си. Таким образом удается работать через JNI с любыми блоками данных напрямую. В прочих случаях он на пару процентов медлительнее, хоть и тоже является JIT-компилятором. Но при разработке интегрированного решения скорость может быть такая, что вы на глаз от приложения на C не отличите.
Коммерческих решений в сегменте кроссплатформенного GUI — куча
Можно несколько примеров из «кучи» для Java?
Для Java, как мне тут уже неоднократно твердили, вполне достаточно Oracle JDK. В ней есть всё. А на мобильных платформах есть Android.
Если код, написанный в рамках этого проекта, окажется полезным в связке с любым другим проприетарным решением, я буду только рад оказаться полезен! Единственное, что я хочу определить — это собственную стратегию. А она сейчас в том, чтобы сделать нечто максимально независимое. Настолько, насколько это возможно…
Если код, написанный в рамках этого проекта, окажется полезным в связке с любым другим проприетарным решением, я буду только рад оказаться полезен! Единственное, что я хочу определить — это собственную стратегию. А она сейчас в том, чтобы сделать нечто максимально независимое. Настолько, насколько это возможно…
«Enterprise Solutions — вы даже носа не показали».
Чисто на всякий случай Sciter это UI engine как минимум этих вот продуктов: Norton Antivirus, NIS, AVG, COMODO, NOD32 и т.д.
Уж поверь мне никто из них не хотел, не хочет и не будет связываться с Oracle.
«добиться подобного эффекта, добавив движок браузера какого-то».
Это не работает в принципе. Desktop UI и Web UI имееют принципиально разные security модели. Скажем в принципе ты мог бы задействовать CEF но это всегда «песочница» (UI в отдельном процессе) и как минимум 40 MB ( versus 3-6 MB sciter'а ). И потом Sciter это принципиально embeddable engine. За этим много стоит.
«тут не согласен по обоим пунктам».
Ну и зря. Дело в том что разные платформы имеют разные архитекуры, иногда принципиально разные. Подвести их под общий знаменатель в принципе крайне сложно. Собственно никому это и не удалось еще. Просто поверь опыту — проходилось и начиналось много раз.
Т.е. кому нужен реально мультиплатформенный UI как раз и хотят его видеть одним и тем же образом на всех платформах.
И со своими, выстраданными, стилями, пример:
это Mac OSX а это то же самое но на Windows
Чисто на всякий случай Sciter это UI engine как минимум этих вот продуктов: Norton Antivirus, NIS, AVG, COMODO, NOD32 и т.д.
Уж поверь мне никто из них не хотел, не хочет и не будет связываться с Oracle.
«добиться подобного эффекта, добавив движок браузера какого-то».
Это не работает в принципе. Desktop UI и Web UI имееют принципиально разные security модели. Скажем в принципе ты мог бы задействовать CEF но это всегда «песочница» (UI в отдельном процессе) и как минимум 40 MB ( versus 3-6 MB sciter'а ). И потом Sciter это принципиально embeddable engine. За этим много стоит.
«тут не согласен по обоим пунктам».
Ну и зря. Дело в том что разные платформы имеют разные архитекуры, иногда принципиально разные. Подвести их под общий знаменатель в принципе крайне сложно. Собственно никому это и не удалось еще. Просто поверь опыту — проходилось и начиналось много раз.
Т.е. кому нужен реально мультиплатформенный UI как раз и хотят его видеть одним и тем же образом на всех платформах.
И со своими, выстраданными, стилями, пример:
это Mac OSX а это то же самое но на Windows
Потрясающе. Вы меня утоптали :) Единственное, что могу сказать в своё оправдание — это то, что под Enterprise в данном контексте я подразумевал сетевые (серверные) решения. То есть что-то из области TomCat или IBM WebSphere.
То, что ваш фреймворк используют такие гиганты — нереально круто. Завидую самой черной завистью :)
Я, возможно, близорук в силу своей неопытности, но я обратил внимание на то, что все три современных платформы, которые «держат» Desktop, создают примерно одно и то же окружение для пользовательского приложения. Да, на Windows есть реестр, а на OS X приложение с GUI, запущенное из Bundle не может быть запущено в двух экземплярах… Но эти различия можно компенсировать. В частности, последнее из перечисленных я с успехом победил при помощи труб (pipes) на винде.
Моя идея лишь в том, что разработчику, который пишет не слишком замороченное приложение, не важны эти нюансы. Ему хочется просто обработать открытие файла. А уж передается этот файл через командную строку, или, скажем, через системное событие — это не принципиально. Или (это еще не сделано, но на подходе) он хочет получить доступ к временной папке. Но не хочет точно выяснять, где эта папка должна лежать. Я следую официальному девизу Java: en.wikipedia.org/wiki/Write_once,_run_anywhere
Вы считаете это невыполнимым?
Разумеется, для общего случая эта задача нерешаема. Но я пытаюсь решить ее на уровне создания базового удобства. Конечно, если вы пишите кроссплатформенный антивирус, вам придется написать три антивируса (хотя и там Zetes, думаю, сможет взять на себя часть работы). Но если вы создаете игру или текстовый редактор, то, думаю, мой подход не так уж бесполезен. Как вы считаете?
Приведите мне, если несложно, пример проблемы, в которую я упрусь и не смогу решить.
То, что ваш фреймворк используют такие гиганты — нереально круто. Завидую самой черной завистью :)
разные платформы имеют разные архитекуры, иногда принципиально разные
Я, возможно, близорук в силу своей неопытности, но я обратил внимание на то, что все три современных платформы, которые «держат» Desktop, создают примерно одно и то же окружение для пользовательского приложения. Да, на Windows есть реестр, а на OS X приложение с GUI, запущенное из Bundle не может быть запущено в двух экземплярах… Но эти различия можно компенсировать. В частности, последнее из перечисленных я с успехом победил при помощи труб (pipes) на винде.
Моя идея лишь в том, что разработчику, который пишет не слишком замороченное приложение, не важны эти нюансы. Ему хочется просто обработать открытие файла. А уж передается этот файл через командную строку, или, скажем, через системное событие — это не принципиально. Или (это еще не сделано, но на подходе) он хочет получить доступ к временной папке. Но не хочет точно выяснять, где эта папка должна лежать. Я следую официальному девизу Java: en.wikipedia.org/wiki/Write_once,_run_anywhere
Вы считаете это невыполнимым?
Разумеется, для общего случая эта задача нерешаема. Но я пытаюсь решить ее на уровне создания базового удобства. Конечно, если вы пишите кроссплатформенный антивирус, вам придется написать три антивируса (хотя и там Zetes, думаю, сможет взять на себя часть работы). Но если вы создаете игру или текстовый редактор, то, думаю, мой подход не так уж бесполезен. Как вы считаете?
Приведите мне, если несложно, пример проблемы, в которую я упрусь и не смогу решить.
Временные файлы и все такое прочее это ничто. Три #ifdef в конце концов. Есть куча C++ библиотек которые такие вещи уже изолируют. Тот же std::, boost:: poco:: namespaces и библиотеки. Вот стилируемый UI и куча разработчиков которые знают CSS/HTML и что с ними делать — это то что нужно.
Некая корпорация (назовем её Foo Corp) так мне объяснила бенефиты от Sciter которые они с 2006 года используют:
1. Они выпускают новую версию своего продукта раз в год. При этом логика (backend) не сильно у них меняется за последние лет 20 или около того.
Но UI (то что customer's видят) они меняют регулярно — каждый год. Вчера были модны 3D кнопки, сегодня Metro UI.
В какие-то года они обходятся вообще косметическим редактированием CSS. Поэтому Sciter.
2. Их UX guy мне выдал следующую максиму: пользователь принимает решение покупать или нет в течение первых 40 секунд от начала download.
Т.е. скорость запуска и размер matters. Они вообще используют UI composition (загрузку интерфейса по требованию) когда пользователь
жмет кнопку «Детали...» или что-то там. Поэтому Sciter и HTML со скриптами в нем.
3. У них команды делающие UI и backend разделены. backend в своих worker threads выдает JSON или что-то на него похожее. frontend (UI) его потребляет.
Активно используется data-binding (sdk/samples/+plus — AngularJS alike databinding механизм).
Команды работают независимо практически ибо UI на данные не завязан сильно (естественное разделение UI и logic layers). Поэтому Sciter.
4. Direct2D graphics это GPU акселерация. В свете наличия уже на рынке retina grade (high-DPI) мониторов имеем увеличение фактически на порядок
количества пикселей которые CPU должен обработать (GDI, GDI+ и прочая). Только GPU короче. И в свете тех же мониторов получаются очень
нетривиальные конфигурации — здесь. Поэтому Sciter.
Там есть еще с десяток пунктов, но эти главные я думаю.
Это я к тому что каждый UI engine должен в принципе иметь свою client model — «для кого это все?»
Подумай на эту тему — для кого это все будет хорошо? И почему при наличии SWT или Swing в Java мы так и не видим особых массовых UI приложений на Java. Ну кроме одного — Эклипса…
Некая корпорация (назовем её Foo Corp) так мне объяснила бенефиты от Sciter которые они с 2006 года используют:
1. Они выпускают новую версию своего продукта раз в год. При этом логика (backend) не сильно у них меняется за последние лет 20 или около того.
Но UI (то что customer's видят) они меняют регулярно — каждый год. Вчера были модны 3D кнопки, сегодня Metro UI.
В какие-то года они обходятся вообще косметическим редактированием CSS. Поэтому Sciter.
2. Их UX guy мне выдал следующую максиму: пользователь принимает решение покупать или нет в течение первых 40 секунд от начала download.
Т.е. скорость запуска и размер matters. Они вообще используют UI composition (загрузку интерфейса по требованию) когда пользователь
жмет кнопку «Детали...» или что-то там. Поэтому Sciter и HTML со скриптами в нем.
3. У них команды делающие UI и backend разделены. backend в своих worker threads выдает JSON или что-то на него похожее. frontend (UI) его потребляет.
Активно используется data-binding (sdk/samples/+plus — AngularJS alike databinding механизм).
Команды работают независимо практически ибо UI на данные не завязан сильно (естественное разделение UI и logic layers). Поэтому Sciter.
4. Direct2D graphics это GPU акселерация. В свете наличия уже на рынке retina grade (high-DPI) мониторов имеем увеличение фактически на порядок
количества пикселей которые CPU должен обработать (GDI, GDI+ и прочая). Только GPU короче. И в свете тех же мониторов получаются очень
нетривиальные конфигурации — здесь. Поэтому Sciter.
Там есть еще с десяток пунктов, но эти главные я думаю.
Это я к тому что каждый UI engine должен в принципе иметь свою client model — «для кого это все?»
Подумай на эту тему — для кого это все будет хорошо? И почему при наличии SWT или Swing в Java мы так и не видим особых массовых UI приложений на Java. Ну кроме одного — Эклипса…
Я правильно понял, что Avian (а значит и Zetes) содержит «классическую» JVM c JIT, а не единовременный транслятор в нативный код?
>Исполняемый файл раздувается до 25 мегабайт
Так а что, включать лишь нужные кодовые таблицы нельзя? Да и классы лишь те, которые используются в приложении… А то так теряется потенциальное преимущество перед JRE/OpenJDK: они сами весят в районе 30 МБ, но при этом ставятся в систему обычно в одном экземпляре, а тут каждая программа за собой библиотеки тащит.
Так а что, включать лишь нужные кодовые таблицы нельзя? Да и классы лишь те, которые используются в приложении… А то так теряется потенциальное преимущество перед JRE/OpenJDK: они сами весят в районе 30 МБ, но при этом ставятся в систему обычно в одном экземпляре, а тут каждая программа за собой библиотеки тащит.
Согласен, будем над этим работать. Просто для того, чтобы выбирать необходимые кодовые страницы, необходимо разбивать на части статическую библиотеку ICU data, которая занимает почти 18 мегов и линковать ее по частям, в зависимости от пожеланий пользователя. Но это — достаточно сложная задача — надо разобраться плотно и подробно, времени пока не было.
Если вам это принципиально, я подскажу, что вы можете сделать для себя, чтобы решить эту проблему. Выкинуть несколько таблиц для CJK языков, например, — несложно. Труднее сделать универсальное решение.
Если вам это принципиально, я подскажу, что вы можете сделать для себя, чтобы решить эту проблему. Выкинуть несколько таблиц для CJK языков, например, — несложно. Труднее сделать универсальное решение.
Давным-давно, еще во время молодости и засилия Windows, я экспериментировал с этим. Был и сейчас есть довольно сносный GNU компилятор для Java (GCJ) и проект GNU classpath с эмуляцией джавовского API, которые на выходе дают бинарник. Вместо свинга использовался SWT. Был даже проект SwingWT с портированными свинговскими виджетами, работающими под SWT. Еще был проект Excelsior Jet, который компилировал джавовский код в бинарник. Тоже не требовал JRE, если не использовался Swing. Сейчас не знаю состояние этих проектов, но тогда мне хватало.
GCJ мертв, а Excelsior Jet вполне себе живет и здравствует.
Я как-то пытался шевелить GCJ. Оно ни фига не работало. К тому же, оно накладывало ряд ограничений на код… Avian несравненно круче.
Кстати, в SWT и сейчас можно использовать Swing-виджеты.
www.eclipse.org/articles/article.php?file=Article-Swing-SWT-Integration/index.html
www.eclipse.org/articles/article.php?file=Article-Swing-SWT-Integration/index.html
Sign up to leave a comment.
Zetes: Java с мультиплатформенным GUI, но без Oracle JVM