Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 36
да, отсутсвие нормальной UI для go — большой минус, к сожалению
web-решения заняли прочную позицию, потому что это единственный способ сделать красивый кроссплатформенный GUI на данный момент, не связываясь с Qt. Кроссплатформенные современные GUI-библиотеки нужны как воздух для всех языков. Стандартные виджеты не выглядят как говно разве только у OS X и Windows 8, всё остальное хочется перерисовать заново.
Лично меня от перспективы делать GUI-приложения для всех платформ на HTML+CSS+JS охватывает уныние.
Мне кажется, что современная GUI-библиотека должна удовлетворять следующим пунктам:
1) Кроссплатформенность.
2) Должна быть возможность написать приложение полностью на скриптовом языке. Для этого хорошо бы встроить, например, интерпретатор Lua.
3) Это должен быть развитый язык общего назначения с широким набором библиотек. Т.е. я должен иметь возможность на этом скриптовом языке работать с файлами, и многое другое. JavaScript, при всей его мощи, до сих пор остаётся в плену браузерного окружения, что неимоверно раздражает в случае с Qt — я не хочу изучать ещё и C++, я хочу все возможности C++ в скриптовом языке.
4) Богатый набор стандартных виджетов, возможность легко создавать собственные — произвольного внешнего вида и поведения.
5) API должен быть лаконичным и простым, хорошо также иметь возможность описывать GUI декларативно (типа QML, Kivy language).
6) Графический редактор интерфейса (как Qt Designer)
7) Идентичный на всех платформах внешний вид.
8) Библиотека должна использовать OpenGL там, где это оправдано. (по данным Google больше 90% всех устройств поддерживают OpenGL ES 2.0)
9) Библиотека должна быть удобна в сборке и установке, иметь хорошую, регулярно обновляемую документацию. Она не должна быть избыточна (в той же Qt переписали почти все стандартные библиотеки C++).
10) Небольшой размер. Простое приложение с GUI не должно весить под 100 МБ
11) Небольшое число зависимостей, как можно более распространённых и без жёсткой привязки к конкретной версии.
И что мы видим? Этим требованиям не удовлетворяет никто. Ближе всех подходят Qt и Kivy, имхо. Есть ещё Polycode, но он сырой и GUI там пока исключительно побочная фича.
Лично меня от перспективы делать GUI-приложения для всех платформ на HTML+CSS+JS охватывает уныние.
Мне кажется, что современная GUI-библиотека должна удовлетворять следующим пунктам:
1) Кроссплатформенность.
2) Должна быть возможность написать приложение полностью на скриптовом языке. Для этого хорошо бы встроить, например, интерпретатор Lua.
3) Это должен быть развитый язык общего назначения с широким набором библиотек. Т.е. я должен иметь возможность на этом скриптовом языке работать с файлами, и многое другое. JavaScript, при всей его мощи, до сих пор остаётся в плену браузерного окружения, что неимоверно раздражает в случае с Qt — я не хочу изучать ещё и C++, я хочу все возможности C++ в скриптовом языке.
4) Богатый набор стандартных виджетов, возможность легко создавать собственные — произвольного внешнего вида и поведения.
5) API должен быть лаконичным и простым, хорошо также иметь возможность описывать GUI декларативно (типа QML, Kivy language).
6) Графический редактор интерфейса (как Qt Designer)
7) Идентичный на всех платформах внешний вид.
8) Библиотека должна использовать OpenGL там, где это оправдано. (по данным Google больше 90% всех устройств поддерживают OpenGL ES 2.0)
9) Библиотека должна быть удобна в сборке и установке, иметь хорошую, регулярно обновляемую документацию. Она не должна быть избыточна (в той же Qt переписали почти все стандартные библиотеки C++).
10) Небольшой размер. Простое приложение с GUI не должно весить под 100 МБ
11) Небольшое число зависимостей, как можно более распространённых и без жёсткой привязки к конкретной версии.
И что мы видим? Этим требованиям не удовлетворяет никто. Ближе всех подходят Qt и Kivy, имхо. Есть ещё Polycode, но он сырой и GUI там пока исключительно побочная фича.
потому что это единственный способ сделать красивый кроссплатформенный GUI на данный момент
Не только поэтому.
- появился мир смартфонов/планшетов и просто новый подход к вопросу — «я хочу пользоваться интерфейсом с любого из своих устройств»
- как следствие, интерфейс должен работать и на мобильном телефоне и на экране телевизора
- веб-приложениям не нужно заниматься обновлениями приложений конечному пользователю — а это для многих ситуаций громадный выигрыш, часто решающий
- количество «виджетов» созданных для современных фронтендов будет покруче, чем у того же Qt. тут недавно была статья на хабре, как Highcharts.js прикручивали к Qt — подобной крутости charts-библиотек под десктопные UI нет и уже вряд ли будут
Хорошо. Я готов смириться с JavaScript.
Вопросы: я могу с помощью JavaScript прочитать строку из файла?
Я могу использовать Blink как интерпретатор (потому что мне не нужен браузер, мне нужно моё приложение на JS)? Чтобы пользователь запустил .exe файл и увидел окошко, внешний вид которого я полностью контролирую?
Вопросы: я могу с помощью JavaScript прочитать строку из файла?
Я могу использовать Blink как интерпретатор (потому что мне не нужен браузер, мне нужно моё приложение на JS)? Чтобы пользователь запустил .exe файл и увидел окошко, внешний вид которого я полностью контролирую?
строку из файла можно прочитать реквестом, если файл json.
Для создания приложений есть отличнейшая штуковина node-webkit (ныне NW.js). Там скрешена нода и браузер. Файл вы без проблем прочитаете. И еще много всего сделаете. Позволяет как раз таки создавать exe-шники.
Вопросы: я могу с помощью JavaScript прочитать строку из файла?Вы слышали про node.js?
Насчёт highcharts.js — pygal.org тоже очень неплох.
А с подходом «уже ведь написали и оно так круто — поэтому не будем ничего трогать» — этак мы бы до сих пор на Коболе писали.
А с подходом «уже ведь написали и оно так круто — поэтому не будем ничего трогать» — этак мы бы до сих пор на Коболе писали.
7) Идентичный на всех платформах внешний вид.
Это зачем? Как написать, на все мобильных одинаковый внешний вид, тут и выдумывать не надо WEB UI. На платформах должен быть аутентичный вид
Это зачем? Как написать, на все мобильных одинаковый внешний вид, тут и выдумывать не надо WEB UI. На платформах должен быть аутентичный вид
Хм, а FLTK не подойдет? (Не уверен разве что за качество/полноту language bindings и декларативные средства описания гуя.)
1) Кроссплатформенность.Unix/Linux (X11), Windows, OS X.
2) Должна быть возможность написать приложение полностью на скриптовом языке.Вот здесь у них перечислены Tcl/Tk, Perl, Guile, Python, Ruby и др. Lua, правда, не упоминается.
3) Это должен быть развитый язык общего назначения с широким набором библиотек. Т.е. я должен иметь возможность на этом скриптовом языке работать с файлами, и многое другое.
4) Богатый набор стандартных виджетов, возможность легко создавать собственные — произвольного внешнего вида и поведения.На мной вкус довольно богатый «из коробки», собственные создаются или наследуются легко и просто.
5) API должен быть лаконичным и простым, хорошо также иметь возможность описывать GUI декларативно (типа QML, Kivy language).К API у меня нареканий нет; но декларативные средства (если не считать fluid) отсутствуют.
6) Графический редактор интерфейса (как Qt Designer).FLUID, входит в поставку. Не такой продвинутый, как Qt Designer, конечно, но пользоваться можно.
8) Библиотека должна использовать OpenGL там, где это оправдано. (по данным Google больше 90% всех устройств поддерживают OpenGL ES 2.0)Natively supports 3D graphics via OpenGL and its built-in GLUT emulation. Другое дело, что это все-таки скорее для кастомных виджетов.
7) Идентичный на всех платформах внешний вид.Это все можно сказать про FLTK.
9) Библиотека должна быть удобна в сборке и установке, иметь хорошую, регулярно обновляемую документацию. Она не должна быть избыточна (в той же Qt переписали почти все стандартные библиотеки C++).
10) Небольшой размер. Простое приложение с GUI не должно весить под 100 МБ.
11) Небольшое число зависимостей, как можно более распространённых и без жёсткой привязки к конкретной версии.
дубль
Не могу не вспомнить про Java+SWT. Компоненты нативные, кросплатформенно, один из самых мощных (и бесплатных) визуальных дизайнеров WindowBuilder для Eclipse. Минусы — не очень распостранненно (относительно), нужно тянуть примерно 20МБ на платформу (в прочем, JRE тоже весит немало).
Или, если производительность некритична, писать UI под Chrome на HTML+CSS+JS и запускать это все дело через Chrome Application Mode — будет выглядеть не как страница браузера, а как нативное окно. (Чтобы такое сделать, нужно в хроме зайти в Menu — More tools — Create application shortcuts...).
Или, если производительность некритична, писать UI под Chrome на HTML+CSS+JS и запускать это все дело через Chrome Application Mode — будет выглядеть не как страница браузера, а как нативное окно. (Чтобы такое сделать, нужно в хроме зайти в Menu — More tools — Create application shortcuts...).
Очень классно! Раньше, я считал, что лучше всего подход у wxWidgets — они используют нативные компоненты на каждой платформе, но теперь я за OpenGL подход, потомучто только так можно добиться настоящей кроссплатформенности.
Ещё возникает вопрос, можно ли сделать реализацию QML на чистом Go?
Ещё возникает вопрос, можно ли сделать реализацию QML на чистом Go?
В качестве фантазий могу сказать так:
прежде всего, разработка ПО ушла в схему: backend + frontend, и это очень сильно упростило разработку бэкенда, освободив его от рендеринга, оставив только логику, например фреймворк Grape для руби вообще API-only. А фронтенд стал развиваться как бешеный, не даром ходит шутка что если к любому английскому существительному добавить окончание JS — скорее всего такая библиотека (фреймворк, тулза, сборщик, линтер, и т.п.) уже есть. Всё это кстати породило бешеный спрос на фронтендеров.
Далее тренды: компонентность, рективное программирование, отказ от массовых фреймворков в пользу библиотек и нативного кода (про это могу отдельно расссказать).
Тренд в кроссплатформенности: всё идёт к тому, чтобы можно было на любой ОС запускать любые приложения под любые ОС. Я на Линуксе запускаю нативные андроид приложения (пусть пока через хром, но всё же), wine для windows. Скоро обещают совершить революцию и запускать нативные ObjC и Swift приложения под линукс. Под виндой я могу запускать нативные линуксовые утилиты, и даже иксы. Развитие технологий — вопрос времени.
Тренд в UI — сейчас всё больше и больше уходят на html,css,js. Почему? Ведь даже телевизоры, микроволновки и духовые печи на кухне, холодильники — все имеют интерфейс, построенный на этом. А виной всему то, что мир ушёл в онлайн. Сейчас нет необходимости в приложении, которое будет работать нативно на ОС, т.к. для большинства задач уже подходят веб-приложения. Редакторы графики, текстовые, звуковые и видео редакторы — всё в онлайне. Хотите 3d игрушки? Нате, зависайте: webquake.quaddicted.com/Client/WebQuake.htm
Хотите красоту и интерактивность ui — идите в HCJ. Здесь нет .net на 100500 мегабайт с кучей (реально кучей) ненужных зависимостей. Да, даже на линуксе «Hello world» на си занимает восемь килобайт, хотя текста там…
Ок, резервирование памяти, стдио, это простительно. Но когда простите Hello World занимает 20+ мегабайт с .net компонентами — это уже слишком.
А так, да, здорово что у Go есть UI, пусть и скромненький, зато свой. Это безусловно хороший шаг развития языка, который мне очень симпатичен. Тем не менее, я бы предпочёл его использовать как хороший сильный многопоточный (даже на уровне синтаксиса) бэкенд.
прежде всего, разработка ПО ушла в схему: backend + frontend, и это очень сильно упростило разработку бэкенда, освободив его от рендеринга, оставив только логику, например фреймворк Grape для руби вообще API-only. А фронтенд стал развиваться как бешеный, не даром ходит шутка что если к любому английскому существительному добавить окончание JS — скорее всего такая библиотека (фреймворк, тулза, сборщик, линтер, и т.п.) уже есть. Всё это кстати породило бешеный спрос на фронтендеров.
Далее тренды: компонентность, рективное программирование, отказ от массовых фреймворков в пользу библиотек и нативного кода (про это могу отдельно расссказать).
Тренд в кроссплатформенности: всё идёт к тому, чтобы можно было на любой ОС запускать любые приложения под любые ОС. Я на Линуксе запускаю нативные андроид приложения (пусть пока через хром, но всё же), wine для windows. Скоро обещают совершить революцию и запускать нативные ObjC и Swift приложения под линукс. Под виндой я могу запускать нативные линуксовые утилиты, и даже иксы. Развитие технологий — вопрос времени.
Тренд в UI — сейчас всё больше и больше уходят на html,css,js. Почему? Ведь даже телевизоры, микроволновки и духовые печи на кухне, холодильники — все имеют интерфейс, построенный на этом. А виной всему то, что мир ушёл в онлайн. Сейчас нет необходимости в приложении, которое будет работать нативно на ОС, т.к. для большинства задач уже подходят веб-приложения. Редакторы графики, текстовые, звуковые и видео редакторы — всё в онлайне. Хотите 3d игрушки? Нате, зависайте: webquake.quaddicted.com/Client/WebQuake.htm
Хотите красоту и интерактивность ui — идите в HCJ. Здесь нет .net на 100500 мегабайт с кучей (реально кучей) ненужных зависимостей. Да, даже на линуксе «Hello world» на си занимает восемь килобайт, хотя текста там…
#include <stdio.h>
int main (void)
{
printf ("Hello World\n");
}
Ок, резервирование памяти, стдио, это простительно. Но когда простите Hello World занимает 20+ мегабайт с .net компонентами — это уже слишком.
А так, да, здорово что у Go есть UI, пусть и скромненький, зато свой. Это безусловно хороший шаг развития языка, который мне очень симпатичен. Тем не менее, я бы предпочёл его использовать как хороший сильный многопоточный (даже на уровне синтаксиса) бэкенд.
Что мне здесь не нравится — по умолчанию подразумевается знание как минимум 2-х языков — JS и того, на котором бэкенд. Т.е. либо у нас 2 человека, либо 1 человек, который пишет на 2-х языках (надо ещё посчитать HTML+CSS, которые развиваются очень быстро).
JS работает нормально только в WebKit браузерах. Супероптимизированный Blink, которым занимается одна компания, и всё. Все остальные движки уже не тянут амбиции современных фронтендеров. Все эти asm.js, JIT-компиляторы и пр… Кажется, что из технологии выжимают последние соки. Уже вовсю начинают использовать WebGL.
JS до сих пор узконаправленный — он работает только в браузере. А можно напрямую к JS прикрутить код на C/C++? Разве только в рамках Qt. Тот же Python уделывает JS по широте возможностей, а Lua по простоте встраивания его и в него. Я погуглил как в JS прочитать строку из файла и у меня волосы встали дыбом. А эта, совершенно рутинная операция, должна быть в скриптовом языке для GUI. Потому что я хочу на свойство виджета привязать лямбда-функцию, которая должна уметь делать всё, что я захочу, а не только то, что умеет браузер. Связываться с локальным кодом с помощью web-протоколов — извращение. Не говоря уже то том, что интерфейс этот однонаправленный — бэкенд не может вызвать фронтенд (разве только в Qt или Node.js)
JS работает нормально только в WebKit браузерах. Супероптимизированный Blink, которым занимается одна компания, и всё. Все остальные движки уже не тянут амбиции современных фронтендеров. Все эти asm.js, JIT-компиляторы и пр… Кажется, что из технологии выжимают последние соки. Уже вовсю начинают использовать WebGL.
JS до сих пор узконаправленный — он работает только в браузере. А можно напрямую к JS прикрутить код на C/C++? Разве только в рамках Qt. Тот же Python уделывает JS по широте возможностей, а Lua по простоте встраивания его и в него. Я погуглил как в JS прочитать строку из файла и у меня волосы встали дыбом. А эта, совершенно рутинная операция, должна быть в скриптовом языке для GUI. Потому что я хочу на свойство виджета привязать лямбда-функцию, которая должна уметь делать всё, что я захочу, а не только то, что умеет браузер. Связываться с локальным кодом с помощью web-протоколов — извращение. Не говоря уже то том, что интерфейс этот однонаправленный — бэкенд не может вызвать фронтенд (разве только в Qt или Node.js)
Совершенно согласен с вами, тем не менее хочу обратить внимание на io.js, к вопросу о работе js исключительно в браузерах.
Что же касается знания нескольких языков — я не понимаю проблемы совершенно. Язык — это инструмент. Когда мне было нужно писать изящный парсер на питоне — я написал изящный парсер на питоне. Java? Окей гугл, она не так сложна как может показаться. Go — без проблем, после прочтения первой же книги — пара полезных утилит для повседневной жизни в убунте. Вынашиваю идею ОРМ для Go, но это пока только в голове. Тем не менее — не вижу проблем. Если нужно в голове держать несколько языков — держите. Главное — всё равно логика.
А так, да, согласен, есть еще белые пятна, с теми же коллбеками из бэкенда. Реализуемо, но сложно. Опять же, всё зависит от задачи. Да наверное вообще всё от задачи зависит. Есть вещи, которые вообще только на асме лучше всего делать )
Что же касается знания нескольких языков — я не понимаю проблемы совершенно. Язык — это инструмент. Когда мне было нужно писать изящный парсер на питоне — я написал изящный парсер на питоне. Java? Окей гугл, она не так сложна как может показаться. Go — без проблем, после прочтения первой же книги — пара полезных утилит для повседневной жизни в убунте. Вынашиваю идею ОРМ для Go, но это пока только в голове. Тем не менее — не вижу проблем. Если нужно в голове держать несколько языков — держите. Главное — всё равно логика.
А так, да, согласен, есть еще белые пятна, с теми же коллбеками из бэкенда. Реализуемо, но сложно. Опять же, всё зависит от задачи. Да наверное вообще всё от задачи зависит. Есть вещи, которые вообще только на асме лучше всего делать )
Вы пытаетесь frontend JS представлять на месте традиционных системных языков. Но мы же тут о другом — «веб-решение» подразумевает другую модель взаимодействия с пользователем, и там где раньше вам нужно было «читать файл», сейчас вы «принимаете HTTP-запрос». Банальный пример — загрузка изображения. В случае нативной десктопной аппликации вам без умения читать файла с файловой системы не обойтись, в случае с веб-приложением — бекенду это не нужно, зато нужно уметь принимать изображение от клиента.
А так на JS можно делать все, node.js вам в пример.
А так на JS можно делать все, node.js вам в пример.
JS до сих пор узконаправленный — он работает только в браузере. А можно напрямую к JS прикрутить код на C/C++? Разве только в рамках Qt. Тот же Python уделывает JS по широте возможностей, а Lua по простоте встраивания его и в него.JS уже давно не только «браузерный»; есть легковесные, легко встраиваемые реализации (например, duktape), хотя Lua, конечно, встраивать проще (чтобы к duktape «прикрутить код на C/C++», нужно писать много boilerplate кода, который по-хорошему должен авто-генерироваться, по типу SWIG).
Но у Lua, при всех ее достоинствах, очень плохая compatibility track record — никогда нельзя быть уверенным, что ничего не сломается при изменении даже минорной версии — у JS с этим намного лучше.
Боюсь, это ожидание скорого пришествия антихриста Internet of Things и всеобщего онлайна закончится также как всеобщее ожидание смерти PC и прихода устройств с тачскрином.
Но порог вхождения в современный веб гораздо выше, чем в Qt, например. А как, например, в веб интерфейсе отображать быстро меняющиеся динамические данные? Пример: я сейчас думаю сделать на Go генератор анимаций для моего самодельного светодиодного дисплея. Как мне в веб-интерфейсе сделать предварительный просмотр?
Знаете, я вот посмотрел в зависимости, там freetype-go. Который самописный, с нуля, не биндинг к системному рендереру. То есть, приложения на gxui вообще никогда не будут выглядеть нативно и хоть чуть-чуть пристойно.
А можно подробней? Я плохо понимаю, почему самописный рендерер не может быть в итоге пристойным.
Сейчас, понятно, со шрифтами ноль полный там в плане пристойности, но если проект будут развивать, то тема шрифтов, полагаю, будет одной из главных в плане критики/пул-реквестов.
Сейчас, понятно, со шрифтами ноль полный там в плане пристойности, но если проект будут развивать, то тема шрифтов, полагаю, будет одной из главных в плане критики/пул-реквестов.
Ну, про пристойность это была по большей части шутка.
А шрифты просто никогда не будут выглядеть одинаково с отрендеренными нативно, что очевидно плохо. В буквальном смысле очевидно.
То есть, я, конечно, понимаю, автора freetype-go — писать свой truetype renderer интереснее, чем биндинги к системному. А вот тех, кто это использует не в игровом движке — нет.
А шрифты просто никогда не будут выглядеть одинаково с отрендеренными нативно, что очевидно плохо. В буквальном смысле очевидно.
То есть, я, конечно, понимаю, автора freetype-go — писать свой truetype renderer интереснее, чем биндинги к системному. А вот тех, кто это использует не в игровом движке — нет.
А в чем он нативный?
Нативный UI — это же, вроде, когда виджеты отрисовывает сама операционная система?
Или нативный — в том смысле что написан полностью на GO?
Нативный UI — это же, вроде, когда виджеты отрисовывает сама операционная система?
Или нативный — в том смысле что написан полностью на GO?
В golang-nuts несколько дней назад автор отписывался, что он всего лишь на выходных накидал проект и не ожидал такой популярности.
Там еще ничего не готово.
Мои пять копеек насчет трендов: в итоге крупные компании с толстым маркетинговым бюджетом продавят то решение, которое будет им выгодно, причем по причинам нам неизвестным. Причины, по которым лично я не хочу проснуться в мире «JavaScript Everywhere» основываются на моем личном опыте и интервью с создателями языка, прочитанными в книге Coders at Work; это не мешает мне использовать данный язык для своих целей там, где он отлично подходит — в web-интерфейсах. С теми же JS-фреймворками для разработки игр у меня исключительно отрицательный опыт на протяжении нескольких лет.
Там еще ничего не готово.
Мои пять копеек насчет трендов: в итоге крупные компании с толстым маркетинговым бюджетом продавят то решение, которое будет им выгодно, причем по причинам нам неизвестным. Причины, по которым лично я не хочу проснуться в мире «JavaScript Everywhere» основываются на моем личном опыте и интервью с создателями языка, прочитанными в книге Coders at Work; это не мешает мне использовать данный язык для своих целей там, где он отлично подходит — в web-интерфейсах. С теми же JS-фреймворками для разработки игр у меня исключительно отрицательный опыт на протяжении нескольких лет.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Нативная UI-библиотека для Go