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.
NK_INCLUDE_DRAW_TEXT_CUSTOM_FUNCTION
Ну рисовалку картинок оно точно на драйвер перекладывает. Разве со шрифтами не так же? По-моему, это уже есть в Nuklear. GDI+ явно не использует стандартную рисовалку шрифтов от Nuklear.
NK_INCLUDE_UNICODE_SUPPORT
Не подскажете, почему не UTF8?
А Nuklear что, уже не существующая библиотека? ;-)
IUP когда-то пробовал. Претендует на полность — много компонентов, свойств, конфигураций. И жирный исполняемый файл на выходе, несколько мегабайт. С тем же успехом можно wxWidgets взять, только писать код будет приятнее.
libui значительно лучше, даже называют похудевшим wxWidgets. Только libui написана на С++, а не на Си. Так что как минимум несколько сотен килобайт прибавит. А то и больше, всё-таки компоненов там значительно больше, чем в Nuklear. Но за ссылку спасибо, как-нибудь помучаю эту библиотеку.
Размер уменьшится, если не тащить с собой ttf-шрифт или сильно его урезать. В Readme написано, что можно отказаться даже от stdlib. Наверное, это как раз для каких-нибудь микроконтроллеров и может быть полезно. Только да, интерфейс всё-таки ориентирован на десктопы/мобильники. Ну или как минимум относительно большой экран. Хотя опять же, может быть кто-нибудь попробует, расскажет и поделится своими впечатлениями.
C сервера — да. С компьютера пользователя никак. Но идея ясна. Так действительно можно делать демки. Хотя бы только со своим ограниченным набором файлов.
Ну платную проприетарную IDE, да ещё и доступную только под одну ОСь, вряд ли будут прикручивать к Open Source Public Domain проекту.
С другой стороны, это Open Source. Я больше полугода сидел и хотел от Nuklear именно GDI+. Потом плюнул и реализовал недостающее сам :-)
Ну у меня уже есть 2 мелкие тулзовины: одна конвертирует файл из одного 3D-формата в другой, а другая по файлу создаёт Си-массив. И той и той нужно читать файлы с диска. И вроде бы emscripten никак не может дать читать файлы с диска пользователя. Это была бы серьёзная дыра в безопасности.
А всякие тулзы типа "нарисуй градиент у нас онлайн и сохрани его как PNG" вроде проще сразу под веб и писать. Они ж будут под это заточены...
Ну, судя по комменту выше, проблемки всё-таки есть) И с SDL тоже, но они в процессе решения.
С другой стороны практической ценности всё-равно вижу мало. У меня утилиты почти всегда файловые, а с этим насколько я в курсе у JavaScript проблемы.
Старое не всегда значит хорошее. Мне нравится примеры кода FLTK. Код красивый и лаконичный. По сути претензия к FLTK у меня только одна — ужасный и устаревший внешний вид. Если FLTK имеет хорошую кроссплатформенную поддержку скинов, то я готов пересмотреть своё решение. Иначе увольте. Такие интерфейсы делать в 2017 году считаю моветоном.
Визуального редактора форм под это дело точно нет. Не того масштаба проект. Такие визуальные редакторы нужны в основном для создания сложных интерфейсов. А их: 1) лучше создавать в другом инструментарии (читай Qt); 2) Nuklear скорее всего просто не осилит (за счёт малого количества компонентов).
Почему стоит требование малого размера? Потому, что мне жаль из-за утилитки на 20 строчек заставлять пользователя каждый раз тянуть с собой ещё несколько мегабайт Qt. Если проект крупный и серьёзный, то никто не спорит, что инструментарий должен быть соответствующим. Только вот для совсем маленьких проектов я очень долго не мог найти ничего кроссплатформенного...
Nanovg демка выглядит красиво. Есть ли такая же шкура, но натянутая на FLTK?
Прикольно. Получается, что за счёт emscripten к списку поддерживаемых Nuklear платформ можно добавить и браузеры?
Тогда всё отлично, спасибо! Прошу прощения, изначально не правильно понял смысл. Жду эти изменения в master'e Nuklear
Nuklear.h, 1156:
NK_INCLUDE_DRAW_TEXT_CUSTOM_FUNCTION
Ну рисовалку картинок оно точно на драйвер перекладывает. Разве со шрифтами не так же? По-моему, это уже есть в Nuklear. GDI+ явно не использует стандартную рисовалку шрифтов от Nuklear.
NK_INCLUDE_UNICODE_SUPPORT
Не подскажете, почему не UTF8?
(написал выше)
А с решением Björn Höhrmann не сравнивали? Его код выглядит гениально коротким и быстрым.
Да сейчас и на сотни гигабайт софт можно найти. Только что в этом хорошего?...
Спасибо за идею, помощь и подсказки. Для примера собрал свою веб-демку Nuklear:
https://dexp.github.io/nuklear-webdemo/
Уже добавлена в публикацию.
А Nuklear что, уже не существующая библиотека? ;-)
IUP когда-то пробовал. Претендует на полность — много компонентов, свойств, конфигураций. И жирный исполняемый файл на выходе, несколько мегабайт. С тем же успехом можно wxWidgets взять, только писать код будет приятнее.
libui значительно лучше, даже называют похудевшим wxWidgets. Только libui написана на С++, а не на Си. Так что как минимум несколько сотен килобайт прибавит. А то и больше, всё-таки компоненов там значительно больше, чем в Nuklear. Но за ссылку спасибо, как-нибудь помучаю эту библиотеку.
Размер уменьшится, если не тащить с собой ttf-шрифт или сильно его урезать. В Readme написано, что можно отказаться даже от stdlib. Наверное, это как раз для каких-нибудь микроконтроллеров и может быть полезно. Только да, интерфейс всё-таки ориентирован на десктопы/мобильники. Ну или как минимум относительно большой экран. Хотя опять же, может быть кто-нибудь попробует, расскажет и поделится своими впечатлениями.
Возможно. Только вот поддержка скинов в Nuklear полноценна (пруф. на гитхабе, нижние скрины красивее).
Очень интересно! Были ли какие-то проблемы с переносом именно в веб? Как много времени было потрачено на решение?
C сервера — да. С компьютера пользователя никак. Но идея ясна. Так действительно можно делать демки. Хотя бы только со своим ограниченным набором файлов.
Ну платную проприетарную IDE, да ещё и доступную только под одну ОСь, вряд ли будут прикручивать к Open Source Public Domain проекту.
С другой стороны, это Open Source. Я больше полугода сидел и хотел от Nuklear именно GDI+. Потом плюнул и реализовал недостающее сам :-)
Так используется именно Nuklear? А какая библиотека была выбрана драйвером, SDL/glfw?
Ну у меня уже есть 2 мелкие тулзовины: одна конвертирует файл из одного 3D-формата в другой, а другая по файлу создаёт Си-массив. И той и той нужно читать файлы с диска. И вроде бы emscripten никак не может дать читать файлы с диска пользователя. Это была бы серьёзная дыра в безопасности.
А всякие тулзы типа "нарисуй градиент у нас онлайн и сохрани его как PNG" вроде проще сразу под веб и писать. Они ж будут под это заточены...
Ну, судя по комменту выше, проблемки всё-таки есть) И с SDL тоже, но они в процессе решения.
С другой стороны практической ценности всё-равно вижу мало. У меня утилиты почти всегда файловые, а с этим насколько я в курсе у JavaScript проблемы.
Старое не всегда значит хорошее. Мне нравится примеры кода FLTK. Код красивый и лаконичный. По сути претензия к FLTK у меня только одна — ужасный и устаревший внешний вид. Если FLTK имеет хорошую кроссплатформенную поддержку скинов, то я готов пересмотреть своё решение. Иначе увольте. Такие интерфейсы делать в 2017 году считаю моветоном.
Визуального редактора форм под это дело точно нет. Не того масштаба проект. Такие визуальные редакторы нужны в основном для создания сложных интерфейсов. А их: 1) лучше создавать в другом инструментарии (читай Qt); 2) Nuklear скорее всего просто не осилит (за счёт малого количества компонентов).
Почему стоит требование малого размера? Потому, что мне жаль из-за утилитки на 20 строчек заставлять пользователя каждый раз тянуть с собой ещё несколько мегабайт Qt. Если проект крупный и серьёзный, то никто не спорит, что инструментарий должен быть соответствующим. Только вот для совсем маленьких проектов я очень долго не мог найти ничего кроссплатформенного...
Nanovg демка выглядит красиво. Есть ли такая же шкура, но натянутая на FLTK?
Прикольно. Получается, что за счёт emscripten к списку поддерживаемых Nuklear платформ можно добавить и браузеры?