Comments 80
FLTK написан на С++, а не на Си. Соответственно, будет занимать значительно больше места (примерно +200kb за stdlibc++). Лицензия у него LGPL, а не Public Domain. Но лично меня оттолкнул внешний вид.
А вообще я бы хотел Qt, но в 100kb :-)
Nanovg демка выглядит красиво. Есть ли такая же шкура, но натянутая на FLTK?
Прикольно. Получается, что за счёт emscripten к списку поддерживаемых Nuklear платформ можно добавить и браузеры?
Насчет nuklear — да, собственно это уже делали, правда веб демка жаль уже 404, но я видел как она работала)
Ну, судя по комменту выше, проблемки всё-таки есть) И с SDL тоже, но они в процессе решения.
С другой стороны практической ценности всё-равно вижу мало. У меня утилиты почти всегда файловые, а с этим насколько я в курсе у JavaScript проблемы.
зачем это? ну все та же мутиплатформенность, например ты сделал тулзовину или приложение, а в веб версии ее демо-версия… навскид идейка
Ну у меня уже есть 2 мелкие тулзовины: одна конвертирует файл из одного 3D-формата в другой, а другая по файлу создаёт Си-массив. И той и той нужно читать файлы с диска. И вроде бы emscripten никак не может дать читать файлы с диска пользователя. Это была бы серьёзная дыра в безопасности.
А всякие тулзы типа "нарисуй градиент у нас онлайн и сохрани его как PNG" вроде проще сразу под веб и писать. Они ж будут под это заточены...
Так используется именно Nuklear? А какая библиотека была выбрана драйвером, SDL/glfw?
Очень интересно! Были ли какие-то проблемы с переносом именно в веб? Как много времени было потрачено на решение?
В целом ничего сложного, за выходные помоему уложился
Спасибо за идею, помощь и подсказки. Для примера собрал свою веб-демку Nuklear:
https://dexp.github.io/nuklear-webdemo/
Уже добавлена в публикацию.
Старое не всегда значит хорошее. Мне нравится примеры кода FLTK. Код красивый и лаконичный. По сути претензия к FLTK у меня только одна — ужасный и устаревший внешний вид. Если FLTK имеет хорошую кроссплатформенную поддержку скинов, то я готов пересмотреть своё решение. Иначе увольте. Такие интерфейсы делать в 2017 году считаю моветоном.
Возможно. Только вот поддержка скинов в Nuklear полноценна (пруф. на гитхабе, нижние скрины красивее).
Просто сейчас тоже разрабатываю библиотеку ГУЯ, но ориентируюсь только на МК.
Да, именно так: можно использовать хоть на микроволновке, только нужно будет описать драйвер для рендеринга. И это будет намного проще, чем сделать библиотеку для GUI. Рендер — это буквально пара десятков функций типа: нарисуй прямоугольник, линию, круг, текст, картинку. А Nuklear сама уже на этой базе построит элементы GUI. Библиотека Nuklear занимает порядка 15 000 строк кода, GDI+ драйвер для неё — 1 000, SDL — 300.
Хотя конечно все бесспорно интересно как для PC так и для микроконтроллеров.
Размер уменьшится, если не тащить с собой ttf-шрифт или сильно его урезать. В Readme написано, что можно отказаться даже от stdlib. Наверное, это как раз для каких-нибудь микроконтроллеров и может быть полезно. Только да, интерфейс всё-таки ориентирован на десктопы/мобильники. Ну или как минимум относительно большой экран. Хотя опять же, может быть кто-нибудь попробует, расскажет и поделится своими впечатлениями.
В точку! Скин Gwen и используется:
https://github.com/vurtun/nuklear/blob/master/example/skins/gwen.png
код смотрел, вижу что редактора нет, но может где-то существует и редактор под все это?
Визуального редактора форм под это дело точно нет. Не того масштаба проект. Такие визуальные редакторы нужны в основном для создания сложных интерфейсов. А их: 1) лучше создавать в другом инструментарии (читай Qt); 2) Nuklear скорее всего просто не осилит (за счёт малого количества компонентов).
Почему стоит требование малого размера? Потому, что мне жаль из-за утилитки на 20 строчек заставлять пользователя каждый раз тянуть с собой ещё несколько мегабайт Qt. Если проект крупный и серьёзный, то никто не спорит, что инструментарий должен быть соответствующим. Только вот для совсем маленьких проектов я очень долго не мог найти ничего кроссплатформенного...
— а почему не unity
— а почему не qt
Лучше вложить свои силы создание красивого, правильного и простого установщика Qt runtime на системы где с этим туго. А для проектов побольше можно даже попробовать научить приложение дергать сей установщик, дабы подтянул необходимые компоненты.
А так да, Qt конечно рулит.
Насчет студийных рантаймов, это очень странно что MS не может решить эту проблему по-человечески много лет. Давно могли бы сделать (полу-)автоматическую установку.
А насчет размера бинарей. Я догадываюсь вряд ли количество подобных утилит дотянет в сумме до внушительных гигабайтов. А если и дотянет, то видимо время задуматься о выпуске пакета утилит с одним набором библиотек.
Размер тоже может иметь значение. Если это мелкоутилка лично моя — меня не будет сильно парить ее размер, разве что не сотни мегабайт. А вот если я в apk на андройд эту либу заюзаю, как в примере с аля-флешкой выше — меня парить уже будет. Или если я эту «флешку» в сайт какой встрою — тоже размер парить будет. Так же если это вдруг не персональная утилита, а какая-то сверх массовая, типа гнушных утилит, то мелкость по функции и черезмерная толстота тоже начнет вызывать вопросы даже на десктопе, а количество утилит в масштабах дистрибутива очень много.
Я лучше скачаю 10-20 МБ приложения, которое нативно выглядит и хорошо работает, чем 200 КБ примитивного GUI. Qt хорош, помимо прочего, большим количеством возможностей из коробки — и в плане GUI, и по взаимодействию с ОС.
Речь не об embedded, конечно. Речь о том, что для десктопа 20 МБ — не размер, о котором нужно думать. Думать нужно о юзабилити и стоимости разработки хорошего приложения.
В readme проекта не нашел ответа на свои вопросы.
Библиотека сама рисует диалоги choose file и тп? Или использует нативные? Или вообще нет такой фичи?
http://webserver2.tecgraf.puc-rio.br/iup/,
https://github.com/andlabs/libui?
Они тоже написаны на С. Тоже весьма компактны. Используют даже нативный вид ОС в которой работают.
А Nuklear что, уже не существующая библиотека? ;-)
IUP когда-то пробовал. Претендует на полность — много компонентов, свойств, конфигураций. И жирный исполняемый файл на выходе, несколько мегабайт. С тем же успехом можно wxWidgets взять, только писать код будет приятнее.
libui значительно лучше, даже называют похудевшим wxWidgets. Только libui написана на С++, а не на Си. Так что как минимум несколько сотен килобайт прибавит. А то и больше, всё-таки компоненов там значительно больше, чем в Nuklear. Но за ссылку спасибо, как-нибудь помучаю эту библиотеку.
libui на C++? Где вы его в репозитории увидели? Я только в одном семпле.
20 mb Qt много? У нас есть простая GUI утилика написанная на node.js + angular.js + electron. Так вот её дистрибутив весит 466 MB, который, конечно для удобства, заботливо положен в GIT репозиторий. (GIT LFS? нет не слышал...)
Да сейчас и на сотни гигабайт софт можно найти. Только что в этом хорошего?...
Да ничего хорошего, конечно, нет. Каждый раз открываю я эту тулзу и плачу. Только вот писал её один наш co-op student и стоила она компании практически ничего. Другой новый co-op student может её спокойно продолжать пилить, поскольку все они сейчас знают JS.
Я хочу сказать то, что для постых задач нужна такая технология, которую можно отдать студенту, которая будет минимизирать стоимость разработки и для которой не нужен хардкорный программист который будут реализовывать загрузку изображений через OpenGL — для них и так работы хватает.
Другое дело, если задача — сложная, но тогда, все рано, придется использовать Qt или что то подобное.
Вот такие дела.
А несколько лишних мегабайт никого сейчас не волнует (хотя повторюсь, без слез на нашу тулзу смотреть нельзя, но она работает)
Тут все же немного разные области, одно дело одна своя утилита на 400 метров, раз приемлимо и проблем нет — почему бы и нет. Другое дело если каждая такая мелкая системная утилитка типа grep, meld, git gui, kdiff3 итд начнут весить по 400м, жрать по 2 гига и тормозить. Все же во все времена есть какой-то разумный баланс и раз кто-то уже инвестировал свое время в более оптимизированное решение, которым можно воспользоваться — это же хорошо.
Сделал модификации, подключаемые ключами:
NK_INCLUDE_DRAW_VERTEX_CUSTOM_FUNCTION
не использовать штатный механизм буферизации данных меша
в этом режиме, каждый раз, когда вычисляется данные по вершине полигона, вызывается функция
typedef void*(*nk_draw_vertex_f)(void *dst, const struct nk_convert_config *config, struct nk_vec2 pos, struct nk_vec2 uv, struct nk_colorf color);
что делать с этими данными уже решает пользователь
(режим более заточен для отрисовки меша функцией glDrawArrays(GL_TRIANGLES))
NK_INCLUDE_DRAW_TEXT_CUSTOM_FUNCTION
не использовать штатный механизм отрисовки текста и генерации фонта.
режим сделан для движков, у которых есть собственный механизм отрисовки текстов
NK_INCLUDE_UNICODE_SUPPORT
поддержка юникода вместо utf8
то, чего я вно не хватало библиотеке
NK_INCLUDE_DISABLE_KEYBOARD_EDIT
отключает клавиатурный ввод и отображение курсора/селекшина
также были добавлены мелкие полезные мелочи
Это все уже работает, вот пример интеграции библиотеки в мой игровой движочек:
http://casualgum.com/public/nuklear_gui.html
Сейчас занимаюсь исправлением багов и стабилизацией для пулл реквеста.
Изменений очень много, могут и не канонизировать, так что, кому интересно, пока все наработки тут:
https://bitbucket.org/pascualle/nuklear
NK_INCLUDE_DRAW_TEXT_CUSTOM_FUNCTION
Ну рисовалку картинок оно точно на драйвер перекладывает. Разве со шрифтами не так же? По-моему, это уже есть в Nuklear. GDI+ явно не использует стандартную рисовалку шрифтов от Nuklear.
NK_INCLUDE_UNICODE_SUPPORT
Не подскажете, почему не UTF8?
в GDI+ переделан полностью весь механизм работы с NK_COMMAND*
а при этом ключе просто выключается все, что связанное с текстами при стандартной работе с nk_convert()
нужно только определить функцию для рендера текста:
typedef void(*nk_query_font_glyph_f)(nk_handle handle, float font_height,
struct nk_user_font_glyph *glyph,
nk_rune codepoint, nk_rune next_codepoint)
и функцию определения ширины для логики лайоута
typedef float(*nk_text_width_f)(nk_handle, float h, const nk_tchar*, int len);
NK_INCLUDE_UNICODE_SUPPORT
ибо не utf единым, юникод является типом текстовых данных по умолчанию для многих библиотек, тем более тип wchar_t и работа с ним — нативная часть c/c++, а utf — это все-таки чужеродное, хоть и удобное
Nuklear.h, 1156:
1.) Using your own implementation without vertex buffer output
So first up the easiest way to do font handling is by just providing a
nk_user_fontstruct which only requires the height in pixel of the used
font and a callback to calculate the width of a string. This way of handling
fonts is best fitted for using the normal draw shape command API where you
do all the text drawing yourself and the library does not require any kind
of deeper knowledge about which font handling mechanism you use.
IMPORTANT: thenk_user_fontpointer provided to nuklear has to persist
over the complete life time! I know this sucks but it is currently the only
way to switch between fonts.
2.) Using your own implementation with vertex buffer output
While the first approach works fine if you don't want to use the optional
vertex buffer output it is not enough if you do. To get font handling working
for these cases you have to provide two additional parameters inside the
nk_user_font. First a texture atlas handle used to draw text as subimages
of a bigger font atlas texture and a callback to query a character's glyph
information (offset, size, ...). So it is still possible to provide your own
font and use the vertex buffer output.
Все остальное, такое как texture atlas, query callback и тд, не нужно.
Тем не менее, NK_INCLUDE_DRAW_TEXT_CUSTOM_FUNCTION требует от пользователя заполнить структуру nk_user_font:
font->userdata.id = font id стороннего шрифта
font->height = размер стороннего шрифта
/* имплементация your_text_width_calculation */
font->width = nk_custom_font_get_text_width;
/* инитиализация nuklear с nk_user_font */
nk_init_default(инстанс_nuklear.ctx, font);
/* функция рисования текста в vertex buffer стороннего движка */
инстанс_nuklear.ctx.draw_list.draw_text = nk_custom_draw_list_add_text;
Другими словами, новый ключ NK_INCLUDE_DRAW_TEXT_CUSTOM_FUNCTION расширяет возможности nuklear, без избыточности, более того, при этом ключе удаляется весь «ненужный» код работы с шрифтами в nuklear. Правда, использование этого ключа максимально эффективно в работе с ключом NK_INCLUDE_DRAW_VERTEX_CUSTOM_FUNCTION, так как в такой завязке мы получаем доступ к вертексам извне
(написал выше)
Изучать nuklear.h нужно, как для меня, там все интуитивно понятно. Есть примеры, с них можно начать. То, что код получается «мутным» — это идейная часть нуклеара, все строится динамически. Может когда-то кто-то напишет редактор для нуклеара, который генерит с-код, но пока только так, вручную.
А всякие недочеты можно чинить самому и реквестить автору. Базовый функционал, который обычно используется в играх (ползунки, кнопки, окна, меняющие размер, привязка контролов к окну и тд) работает, имхо, отлично.
ps я уже выкладывал пример, как можно подружить игровой движок и нуклеар, повторюсь: http://casualgum.com/public/nuklear_gui.html
> wxWidgets, Qt
Может я ошибаюсь, но их невозможно встроить их в игру, можно только игру встроить в интерфейс wxWidgets, Qt. Если Вы знаете способ — поделитесь.
1) Помните, что это OpenSource. Вы получаете решение абсолютно бесплатно, можете использовать его как хотите. Но при этом вам никто ничего не должен.
2) Предложите лучшие альтернативы. С удовольствием использую в своей игре что-нибудь другое, если оно будет лучше.
3) По моему опыту, с документацией обычно всё ещё хуже :-( Здесь есть хоть какая-то. И относительно много простых примеров, на многие случаи жизни.
4) Если нашли какой-то фатальный баг, то есть много путей решения: а) пофиксить самому; б) заплатить кому-нибудь, чтоб исправил его; в) сидеть и ждать, пока кто-нибудь возможно захочет исправить ваш баг бесплатно.
5) Не следует ожидать от микро-библиотеки супер-функционала и его мега-стабильности. Те же ноды — скорее пример, ЧТО можно закодить на этой мелочи. Собирать на этой библиотеке аналог Matlab вам никто не предлагает. Судя по скринам в документации библиотека делалась, чтоб на ней можно было быстро создать главное меню, настройки, и сфокусироваться на написании игры, а не интерфейса.
6) Что вы подразумеваете под словами "полотно мутного текста"? Простая формочка из публикации занимает 20 строк кода, работает одинаково и стабильно. Если вы встраиваете GUI в свою игру, то остальные строки (создание окна, инициализация OpenGL и пр.) у вас уже есть.
7) Если делаете с нуля — то просто берёте demo с удобной технологией и работаете с ней.
От себя добавлю, что сейчас делаю коммерческую игру на чистом Nuklear: Wordlase. Да, есть далеко не всё. Не всё так красиво, как могло быть. Да, есть некоторое количество багов. Но всё преодолимо. Получить на этой библиотеке игру — реально.
Исполняемые файлы и под Linux и под Windows у меня меньше 300кб, хотя содержат в себе декодеры PNG, TTF, OGG, JSON, TAR, GUI.
В движке уже есть более лучшее решение (свое). Но это естественно не отдельное решение и добавить в свой движок вы его не сможете.
> содержат в себе декодеры PNG, TTF, OGG, JSON, TAR, GUI.
А теперь представьте, что для того, чтобы вам впилить PNG, TTF, OGG, JSON, TAR и т.д. в свой движок, вам нужно будет изучить исходники всех этих библиотек, и еще баги в них поправить
Эм. Чтобы встроить библиотеку в свой код вам нужно использовать функции. Они где-то описаны. Да, иногда есть документация. Но многое приходится читать прямо в комментариях прямо в коде…
И я не призываю вас изучать полностью исходники Nuklear. От этого действительно можно свихнуться. Но вот демки скорее всего обойти не получится. А вот они вовсе не так страшны, как вы их рисуете ;-)
Но это естественно не отдельное решение и добавить в свой движок вы его не сможете.
Вот-вот. Лучшего встраиваемого, чем Nuklear, я так и не нашёл...
Утащил в закладки. Ругаюсь последними словами, что не увидел эту статью раньше. С хабром всегда так. Читать всё нет никакой возможности. А потом натыкаешься на что-то подобное этому, и начинаешь себя гнусно материть :))))
Nuklear — идеальный GUI для микро-проектов?