Pull to refresh

Comments 80

FLTK написан на С++, а не на Си. Соответственно, будет занимать значительно больше места (примерно +200kb за stdlibc++). Лицензия у него LGPL, а не Public Domain. Но лично меня оттолкнул внешний вид.
А вообще я бы хотел Qt, но в 100kb :-)

Благодаря си его еще можно например скриптовать tcc. Я его использую в мини аля-флеш плеере, у которого рантайм около 300кб (размер apk увеличивается на 100кб). Причем работает оно на десктопе, телефонах и веб через emscripten. Вот пример nanovg демки, обернутой в эту штуку (специальо для nuklear демки еще не делал).

Nanovg демка выглядит красиво. Есть ли такая же шкура, но натянутая на FLTK?
Прикольно. Получается, что за счёт emscripten к списку поддерживаемых Nuklear платформ можно добавить и браузеры?

Это псевдо-интерфейс вручную нарисованный nanovg (это почти то же что html5 canvas api, возможности те же). В принципе если код демки использовать — натянуть можно много куда, самому nanovg ничего кроме gl\gles не надо.
Насчет nuklear — да, собственно это уже делали, правда веб демка жаль уже 404, но я видел как она работала)
так точно. Nuklear поддерживает glfw и sdl, а это означает, что с emscripten проблем не будет. я сам увлекаюсь этой технологией, прям магия с --> llvm --> js

Ну, судя по комменту выше, проблемки всё-таки есть) И с SDL тоже, но они в процессе решения.
С другой стороны практической ценности всё-равно вижу мало. У меня утилиты почти всегда файловые, а с этим насколько я в курсе у JavaScript проблемы.

насчет sdl не знаю для меня он слишком громоздкий в разрезе emscripten. А вот пример работы с glfw3, все там отлично рабоатет, как пример моя демка http://casualgum.com/test/mun.html
зачем это? ну все та же мутиплатформенность, например ты сделал тулзовину или приложение, а в веб версии ее демо-версия… навскид идейка

Ну у меня уже есть 2 мелкие тулзовины: одна конвертирует файл из одного 3D-формата в другой, а другая по файлу создаёт Си-массив. И той и той нужно читать файлы с диска. И вроде бы emscripten никак не может дать читать файлы с диска пользователя. Это была бы серьёзная дыра в безопасности.
А всякие тулзы типа "нарисуй градиент у нас онлайн и сохрани его как PNG" вроде проще сразу под веб и писать. Они ж будут под это заточены...

https://kripken.github.io/emscripten-site/docs/getting_started/Tutorial.html, раздел «Using files» (fopen)

C сервера — да. С компьютера пользователя никак. Но идея ясна. Так действительно можно делать демки. Хотя бы только со своим ограниченным набором файлов.

Через glfw там были какие то минорные проблемы, но в целом все хорошо работало. Собственно из скрипта аля-флеш мультика моего он тоже работает подо всеми платформами винда\линукс\мак\андройд\ios\веб.

Так используется именно Nuklear? А какая библиотека была выбрана драйвером, SDL/glfw?

В демо что я кинул — только nanovg, но вообще да, в невыложенных «флешках» я использую и nuklear для интерфейса\кнопочек итд. Использую glfw, но это кухня плеера, для скрипта вшитого во «флешку», эти подробности скрыты.

Очень интересно! Были ли какие-то проблемы с переносом именно в веб? Как много времени было потрачено на решение?

Были, мне пришлось пропатчить emscripten, добавив loadDynamicLibrarySrc для загрузки скрипта из памяти. Т.к. скрипт грузится не из файла, а распаковывается из zip («флешка» это скрипт+ресурсы). Там еще по мелочи #ifdef EMSCRIPTEN, немного js в html чтобы загрузить флешку по линку в контейнер откуда emscripten файлы берет.
В целом ничего сложного, за выходные помоему уложился
Всегда пожалуйста)

Старое не всегда значит хорошее. Мне нравится примеры кода FLTK. Код красивый и лаконичный. По сути претензия к FLTK у меня только одна — ужасный и устаревший внешний вид. Если FLTK имеет хорошую кроссплатформенную поддержку скинов, то я готов пересмотреть своё решение. Иначе увольте. Такие интерфейсы делать в 2017 году считаю моветоном.

Посмотрел скриншоты у FLTK. На мой взгляд, примеры в статье выглядят не менее ужасно с точки зрения внешнего вида.

Возможно. Только вот поддержка скинов в Nuklear полноценна (пруф. на гитхабе, нижние скрины красивее).

Получается можно её использовать во встраиваемых системах на чистом железе, на микроконтроллерах?
Угу, только рендер свой написать.
Миленько :3
Просто сейчас тоже разрабатываю библиотеку ГУЯ, но ориентируюсь только на МК.
Для рисования на совсем слабых контроллеров могу свою либу посоветовать: https://github.com/errorcalc/ESLowGraphicsLibrary
Пасибки, возможн когда-нибудь и воспользуюсь. Но сейчас я пишу хай лэвел либу, возможно, с менеджером окон. Аля emWin, только в разы более простую и открытую.

Да, именно так: можно использовать хоть на микроволновке, только нужно будет описать драйвер для рендеринга. И это будет намного проще, чем сделать библиотеку для GUI. Рендер — это буквально пара десятков функций типа: нарисуй прямоугольник, линию, круг, текст, картинку. А Nuklear сама уже на этой базе построит элементы GUI. Библиотека Nuklear занимает порядка 15 000 строк кода, GDI+ драйвер для неё — 1 000, SDL — 300.

Только обычно библиотеку для GUI на микроконтроллер не нужно делать такой. Там нет мыши (ну можно конечно втулить), и окон, и даже тач редко используется. Обычно пара кнопок и тогда требования к UI совершенно другие. И библиотека рендера часто тоже есть. Остается только воплощать идею заказчика. И 100кб там это сильно больше 16Мб Qt приложения на декстопе.

Хотя конечно все бесспорно интересно как для PC так и для микроконтроллеров.

Размер уменьшится, если не тащить с собой ttf-шрифт или сильно его урезать. В Readme написано, что можно отказаться даже от stdlib. Наверное, это как раз для каких-нибудь микроконтроллеров и может быть полезно. Только да, интерфейс всё-таки ориентирован на десктопы/мобильники. Ну или как минимум относительно большой экран. Хотя опять же, может быть кто-нибудь попробует, расскажет и поделится своими впечатлениями.

Скриншот
image
напомнил еще одну GUI библиотеку — GWEN (GWork).
Тоже поддерживаются различные рендереры: GDI, SFML, OpengGL, DirectX, Allegro. Правда она потяжелее и написана на C++
мне проект понравился, думаю может утащу к себе, я какраз люблю когда никаких зависимостей
код смотрел, вижу что редактора нет, но может где-то существует и редактор под все это?

Визуального редактора форм под это дело точно нет. Не того масштаба проект. Такие визуальные редакторы нужны в основном для создания сложных интерфейсов. А их: 1) лучше создавать в другом инструментарии (читай Qt); 2) Nuklear скорее всего просто не осилит (за счёт малого количества компонентов).

ну… судя по коду все можно сериализировать, под капотом все пушается в буфер и рисуется. так что потенциально читать лайоут с какого-то редактора сделать не сложно. был бы редактор, кстати, можно попробовать использовать .dfm файлы Borland ide как вариант, редактор там норм

Ну платную проприетарную IDE, да ещё и доступную только под одну ОСь, вряд ли будут прикручивать к Open Source Public Domain проекту.
С другой стороны, это Open Source. Я больше полугода сидел и хотел от Nuklear именно GDI+. Потом плюнул и реализовал недостающее сам :-)

Самая неожиданная реклама визуальной новеллы, что я видел.
А чем не устраивает QT? Да, объёмы больше, но и возможности не ограничиваются только GUI.

Почему стоит требование малого размера? Потому, что мне жаль из-за утилитки на 20 строчек заставлять пользователя каждый раз тянуть с собой ещё несколько мегабайт Qt. Если проект крупный и серьёзный, то никто не спорит, что инструментарий должен быть соответствующим. Только вот для совсем маленьких проектов я очень долго не мог найти ничего кроссплатформенного...

думаю, если собрать два самых частых вопроса в информационном поле нашей солнечной системы, они будут такими:
— а почему не unity
— а почему не qt
— а почему не assembler и framebuffer?
Я было подумал пост десятилетней давности, присмотрелся, нет свежий. Не понимаю зачем так экономить когда речь по большому счету не идет об embedded системах.

Лучше вложить свои силы создание красивого, правильного и простого установщика Qt runtime на системы где с этим туго. А для проектов побольше можно даже попробовать научить приложение дергать сей установщик, дабы подтянул необходимые компоненты.
Вы не сможете сделать утилиту на 100кб, портабельную и которая заработает под всеми дистрибутивами, которую просто скопировал в фаре и работай. Я пробовал, тут даже libstdc++ приходится линковать статически. Под виндой таскать с такими утилками несколько громадных dll тоже не айс, или копировать их в загрузочные пути чтобы все эти утилки заработали. Доп рантайм это гиблое дело, не заставите вы его никого ставить, все проекты эмбедят Qt внутрь. Под виндой даже С++ рантаймы новых студий ставить отдельно не хотят — эмбедят его установщик вместе с софтом. Причем версий рантайма установленных в системе придется делать 100500 т.к. разные утилки будет слинкованы с разными версиями Qt.
А так да, Qt конечно рулит.
Так я и говорю, если правильно приложить к этому руки, то к продукту и люди потянутся и со временем превратят его в стандарт. И тогда, конечно, выпуск новой версии скажем раз в год строго с определенным тулчейном и определенной версией Qt — лучше чем клепать 100500 рантаймов. И вопрос портабельости в этом случае вполне решаем до определенной степени.

Насчет студийных рантаймов, это очень странно что MS не может решить эту проблему по-человечески много лет. Давно могли бы сделать (полу-)автоматическую установку.

А насчет размера бинарей. Я догадываюсь вряд ли количество подобных утилит дотянет в сумме до внушительных гигабайтов. А если и дотянет, то видимо время задуматься о выпуске пакета утилит с одним набором библиотек.
В ваших словах конечно есть истина, как и в моих. Как я уже говорил — я пытался заюзать Qt для данного сценария, проблема не только в размере, официальные сборки не статические, и в винде и в дистрибутивах. В винде приходится прикладывать dll, в лине или делать appimage\snap\flatpak или универсальный бинарь в который все надо линковать статически (из реп может не стоять по дефолту, а если бы стояло — версии разношерстные), на маке тоже придется постараться, в .app формате там приложение — это структура директорий. И универсальная сборка сильно усложняется. Для бльшого софта это норм, для мелкоутилок — ужас, ужас (./util.app/Contents/MacOS/util -f file :3 ).

Размер тоже может иметь значение. Если это мелкоутилка лично моя — меня не будет сильно парить ее размер, разве что не сотни мегабайт. А вот если я в apk на андройд эту либу заюзаю, как в примере с аля-флешкой выше — меня парить уже будет. Или если я эту «флешку» в сайт какой встрою — тоже размер парить будет. Так же если это вдруг не персональная утилита, а какая-то сверх массовая, типа гнушных утилит, то мелкость по функции и черезмерная толстота тоже начнет вызывать вопросы даже на десктопе, а количество утилит в масштабах дистрибутива очень много.
Насчет рантаймов студий — все было хорошо, пока его не вынесли в WinSxS, так что dll из текущей диры уже не подхватываются, и ищутся из недр WinSxS по манифесту. В 2015 студии пошли на попятную и dll можно снова просто прилагать к проге.
Для этого есть Qt.
Я лучше скачаю 10-20 МБ приложения, которое нативно выглядит и хорошо работает, чем 200 КБ примитивного GUI. Qt хорош, помимо прочего, большим количеством возможностей из коробки — и в плане GUI, и по взаимодействию с ОС.

Речь не об embedded, конечно. Речь о том, что для десктопа 20 МБ — не размер, о котором нужно думать. Думать нужно о юзабилити и стоимости разработки хорошего приложения.
Qt может и выглядит нативно, но он не более нативен чем герой этой статьи. Точно также Qt рисует сам все контролы, все кроме самого окна.
Вижу на одном из скриншотов «Choose File».
В readme проекта не нашел ответа на свои вопросы.
Библиотека сама рисует диалоги choose file и тп? Или использует нативные? Или вообще нет такой фичи?
Нету такой фичи, у либы вообще нет зависимостей от системы и сама она такие диалоги не рисует. Но в демках и экзамплах уже есть зависимый от системы код.

А Nuklear что, уже не существующая библиотека? ;-)
IUP когда-то пробовал. Претендует на полность — много компонентов, свойств, конфигураций. И жирный исполняемый файл на выходе, несколько мегабайт. С тем же успехом можно wxWidgets взять, только писать код будет приятнее.
libui значительно лучше, даже называют похудевшим wxWidgets. Только libui написана на С++, а не на Си. Так что как минимум несколько сотен килобайт прибавит. А то и больше, всё-таки компоненов там значительно больше, чем в Nuklear. Но за ссылку спасибо, как-нибудь помучаю эту библиотеку.

libui на C++? Где вы его в репозитории увидели? Я только в одном семпле.

Наверно имеется ввиду папочка windows. Зачем так сделано не очень понятно, может из-за того что студии не очень дружат с С99.

Чёрт, похоже на деформацию, папочку unix посмотрел, а windows даже не открыл :) Кстати, а darwin код вообще на ObjectiveC написан.

20 mb Qt много? У нас есть простая GUI утилика написанная на node.js + angular.js + electron. Так вот её дистрибутив весит 466 MB, который, конечно для удобства, заботливо положен в GIT репозиторий. (GIT LFS? нет не слышал...)

Да сейчас и на сотни гигабайт софт можно найти. Только что в этом хорошего?...

Да ничего хорошего, конечно, нет. Каждый раз открываю я эту тулзу и плачу. Только вот писал её один наш co-op student и стоила она компании практически ничего. Другой новый co-op student может её спокойно продолжать пилить, поскольку все они сейчас знают JS.
Я хочу сказать то, что для постых задач нужна такая технология, которую можно отдать студенту, которая будет минимизирать стоимость разработки и для которой не нужен хардкорный программист который будут реализовывать загрузку изображений через OpenGL — для них и так работы хватает.
Другое дело, если задача — сложная, но тогда, все рано, придется использовать Qt или что то подобное.
Вот такие дела.
А несколько лишних мегабайт никого сейчас не волнует (хотя повторюсь, без слез на нашу тулзу смотреть нельзя, но она работает)

Проекты разные и требования разные. А также сюда можно добавить бюджет и время. Кому-то 2Гб не проблема в браузере грузить а кому и 640кб хватит на все задачи. Но все замечу, что тема топика «идеальный GUI для микро-проектов», что какбэ должно намекать…
Никто и не говорит что у такого подхота тоже нету жизни, сейчас каждый второй мессенджер — электрон. И кстати в вебе сейчас тоже есть webgl, а инициализировать его через glfw даже проще. И я бы не сказал, что веб сейчас это такая простая технология сильно проще других областей. Я вот с электроном и nodejs тоже возился и проблем хватало, например когда ставится 2000 njs пакетов, у части есть native и бац — один не компилится, приехали.
Тут все же немного разные области, одно дело одна своя утилита на 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?

NK_INCLUDE_DRAW_TEXT_CUSTOM_FUNCTION
в 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_font struct 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: the nk_user_font pointer 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.
Так точно, я читал это. Но что, если нужно использовать vertex buffer, но абсолютно нет нужны инициализировать и загружать шрифт? Он уже загружен средствами другой подсистемы, и все, что нужно знать nuklear — это id шрифта, размер шрифта и имплементация функции float your_text_width_calculation(nk_handle handle, float height, const nk_tchar *text, int len)
Все остальное, такое как 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, так как в такой завязке мы получаем доступ к вертексам извне

Тогда всё отлично, спасибо! Прошу прощения, изначально не правильно понял смысл. Жду эти изменения в master'e Nuklear

есть пока противная бага с тачскрином, nuklear почему-то адаптирован только под «непрерывный инпут», а также где-то я напартачил с редактированием текстовых полей. работаемс, в общем, пока
Пытаюсь разобраться, но не хватает информации о самых основах. Вот допустим у меня есть игровой движок и файлик nuklear.h. И что я должен сделать, чтобы внедрить этот nuklear в свой движок, чтобы он дергал вызывал графические функции. Из статьи я только понял, что надо написать свой рендер. Что? Как? Я должен определить какие-то функции и подсунуть их библиотеке? Какие? Мне надо для этого изучить 780кбайтный файл nuklear.h, а потом построчно сравнивать все примеры из папки демо, чтобы выяснить чем-же они отличаются? Библиотека же должна упрощать жизнь, а не заставлять изучать весь ее исходный код. Или вот пример с нодами. Я двигаю ноды и они всегда рендерятся в одном и том же порядке (то есть при перетаскивании ноды она уезжает под другую ноду). А когда при перетаскивании ноды мышка касается заголовка окна, окно начинает двигаться вместе с нодой. Я должен сортировку и нормальное перетаскивание контролов сам реализовать? Что вообще библиотека делает? И при этом исходник node_editor.c 14 килобайт (то есть там что-то реализовывали, реализовывали, да не выреализывали). У кого хватит духу сказать, что для того, чтобы вывести несколько контролов на экран, нужно написать на cи полотно мутного текста и при этом оно будет работать кое-как — это хорошая библиотека?
Привет. я вот какраз сделал функционал, который потенциально облегчит проблему интеграции нуклеар в некий движок, но он еще ревьювится, как я понимаю, результат будет не скоро. Идея такая: колбеком высыпаются полигоны, а ты уже делай с ними что хочешь и добавляешь в свой opengl/directx ренделист.

Изучать nuklear.h нужно, как для меня, там все интуитивно понятно. Есть примеры, с них можно начать. То, что код получается «мутным» — это идейная часть нуклеара, все строится динамически. Может когда-то кто-то напишет редактор для нуклеара, который генерит с-код, но пока только так, вручную.

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

ps я уже выкладывал пример, как можно подружить игровой движок и нуклеар, повторюсь: http://casualgum.com/public/nuklear_gui.html
Справедливости ради, добавлю что в примерах готовые рендеры уже есть, и dx и ogl, так что претензии вообще не понятны. С чего это добавить готовую аналогичную либу чтобы «не писать мутный код» в которой рендер уже есть религия позволяет, а добавить крохотный кусок рендера из примера не позволяет. Тем более код рендеров там выделен, а в node_editor уже код самого эдитора, и получается вполне компактно, калькулятор вон 2кб, ничуть не хуже чем если делать аналог на wxWidgets, Qt C++ или imgui.
Движок предоставляет унифицированный апи, работающий и с OpenGL, и с DirectX9 / Dx11. Поверх этого дела навешивать gui, который работает только с OpenGL например, как то не комильфо.

> wxWidgets, Qt

Может я ошибаюсь, но их невозможно встроить их в игру, можно только игру встроить в интерфейс wxWidgets, Qt. Если Вы знаете способ — поделитесь.
Я про объем кода говорил (к которому была претензия), не вижу с ним больших проблем с nuklear по сравнению с этими аналогами. Что касаемо встраивания — да, их встраивать сложнее, хотя я делал. У wxWidgets получал контекст окна, у Qt использовал OpenGl виджет. Тут возникает проблема микса отрисовки, если контролы нужны поверх, но решаемы. На Qt можно сделать правильнее через scene graph, но это все на quick переписывать, что не хорошо когда есть готовый gl код.

1) Помните, что это OpenSource. Вы получаете решение абсолютно бесплатно, можете использовать его как хотите. Но при этом вам никто ничего не должен.
2) Предложите лучшие альтернативы. С удовольствием использую в своей игре что-нибудь другое, если оно будет лучше.
3) По моему опыту, с документацией обычно всё ещё хуже :-( Здесь есть хоть какая-то. И относительно много простых примеров, на многие случаи жизни.
4) Если нашли какой-то фатальный баг, то есть много путей решения: а) пофиксить самому; б) заплатить кому-нибудь, чтоб исправил его; в) сидеть и ждать, пока кто-нибудь возможно захочет исправить ваш баг бесплатно.
5) Не следует ожидать от микро-библиотеки супер-функционала и его мега-стабильности. Те же ноды — скорее пример, ЧТО можно закодить на этой мелочи. Собирать на этой библиотеке аналог Matlab вам никто не предлагает. Судя по скринам в документации библиотека делалась, чтоб на ней можно было быстро создать главное меню, настройки, и сфокусироваться на написании игры, а не интерфейса.
6) Что вы подразумеваете под словами "полотно мутного текста"? Простая формочка из публикации занимает 20 строк кода, работает одинаково и стабильно. Если вы встраиваете GUI в свою игру, то остальные строки (создание окна, инициализация OpenGL и пр.) у вас уже есть.
7) Если делаете с нуля — то просто берёте demo с удобной технологией и работаете с ней.
От себя добавлю, что сейчас делаю коммерческую игру на чистом Nuklear: Wordlase. Да, есть далеко не всё. Не всё так красиво, как могло быть. Да, есть некоторое количество багов. Но всё преодолимо. Получить на этой библиотеке игру — реально.
Исполняемые файлы и под Linux и под Windows у меня меньше 300кб, хотя содержат в себе декодеры PNG, TTF, OGG, JSON, TAR, GUI.

https://github.com/urho3d/Urho3D/pull/1709
В движке уже есть более лучшее решение (свое). Но это естественно не отдельное решение и добавить в свой движок вы его не сможете.
> содержат в себе декодеры PNG, TTF, OGG, JSON, TAR, GUI.
А теперь представьте, что для того, чтобы вам впилить PNG, TTF, OGG, JSON, TAR и т.д. в свой движок, вам нужно будет изучить исходники всех этих библиотек, и еще баги в них поправить
А зачем исходники изучать? Когда малый объем нужен я например при помощи stb картинки гружу, исходники его не изучал. При этом даже zip с помощью него распаковываю, т.к. для png он там есть, хоть и не рассчитан на это.
Так я к тому и клоню, что если исходники каждой используемой библиотеки изучать — это грохнуться можно

Эм. Чтобы встроить библиотеку в свой код вам нужно использовать функции. Они где-то описаны. Да, иногда есть документация. Но многое приходится читать прямо в комментариях прямо в коде…
И я не призываю вас изучать полностью исходники Nuklear. От этого действительно можно свихнуться. Но вот демки скорее всего обойти не получится. А вот они вовсе не так страшны, как вы их рисуете ;-)


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

Утащил в закладки. Ругаюсь последними словами, что не увидел эту статью раньше. С хабром всегда так. Читать всё нет никакой возможности. А потом натыкаешься на что-то подобное этому, и начинаешь себя гнусно материть :))))

Sign up to leave a comment.

Articles