Comments 56
Киньте картинку рабочего стола, уж больно понравилась ) спасибо
Еще Crazy Eddie's GUI прикольный)
Вы хоть ссылки оставляйте: http://cegui.org.uk/content/getting-started
За наводку спасибо, не знал про него.
в калде проще интерфейс сделать на шейдерах, из-за реализации 2 матричной проекции, там реализация оч красивая выходит, как бы сам интерфейс на вашем скриншоте говорит об этом(это просто обьекты 2д у которых есть свойства и размеры с расположением в ортогональной проекции соотв), у д3 тоже шейдеры скорее всего просто там еффекты уже накидываются на обьекты (dear Imgui где-то в той же степи, но dear Imgui просто даёт возможность не делать сразу свой интерфейс на шейдерах соотв)
наверно шейдеров нету в ультиме-онлайн, там всё на тайлах сделано, просто с картинка-текстурками работаем, хотя может в те времера были тоже шейдеры(в обновлённой ультиме не знаю вроде шейдеры, а может и нету не знаю ))
из примера текстового редактора на шейдерах это 4coder
Впечатлила libUI, так как единственная feels native
libfx Low-level, cross-platform GUI library for native desktop and mobile.
Какая-то очень странная штука, Gtk4 и одновременно Foundation Kit для MacOS и iOS плюс Win32. Ни документации ни примеров.
Сами-то пробовали это завести?
Не пробовал (лежит у меня в коллекции идей вместе с упомянутой libui). Причина: меня не устраивают библиотеки GUI с огородом кастомных функций API. Всего есть ~13 элементов форм, Они одинаковы на всех платформах и их свойства на 90% совпадают (размер, видимость, цвет...). Отсюда форма должна задаваться в JSON-е и, в зависимости от платформы, разворачиваться в множество нативных элементов. Любой элемент иметь доступ по ID и управляться API из 3-х функций: установть атрибуты, установить значение, взять значение. Размер такой библиотеки будет минимален (десятки килобайт кода). Похожее было реализовано в VC6 как ClassWizard и FormEditor с DDE.
Мой прототип для HTML
Любой элемент иметь доступ по ID и управляться API из 3-х функций: установть атрибуты, установить значение, взять значение
Если уж идти от задачи минимизации - стоит убрать настройку вообще, но решить вопрос с обработчиками событий и данными.
Современная форма это далеко не только ввод, это еще и например выбор из выпадающего списка и закладки (табы) и еще много чего.
Сейчас вожусь с мини-движком, превращающим С++ в (подобие) JS:
var x = "hello", y = 1, z = T_MAP;
z["a"] = x;
z["b"] = y;
z["c"] = false;
var str = z.json(), str2 = json("{ "a" : 1, "b" : [1,2,3, "hello"], "c" :{} } ");
z = 8;
z += 2;
...
...
Затем, когда дойдут руки до GUI, дам на GUI на github ссылку. ;)
egui, iced, tauri, fltk – тоже интересные библиотеки для ui
egui - https://www.egui.rs/#demo да что ж с вами не так ) опять нативную разработку рендерят в веб!
iced - https://github.com/iced-rs/iced
tauri - https://github.com/agmmnn/tauri-ui
ftlk - https://www.fltk.org/ - он же очень известный у линуксоидов, на уровне wxwidgets
Для tauri там какой-то левый репозиторий, не относящийся к проекту, и использующий старую версию tauri.
Лучше по этой ссылке смотреть https://v2.tauri.app/
egui – универсальная библиотека, умеет как нативно рендерить под платформы, так и в веб, используя WebGL (никаких HTML/CSS/JS)
А встречалось ли где-нибудь (не зацепился ли глаз за) сравнение с wxwidgets? Я давно хотел перевести один проект с wxwidgets на что-нибудь поизящнее, вдруг тут прямо упоминали о такой возможности?
Забыли про Flutter, ElectronJS, ReactNative, Python со своими Frameworks.
В добавку, если думано как самостоятельное/встраиваемое решение, то можно глянуть в сторону LVGL , вроде есть порты и для веба, и для нативных приложений.
LVGL известный проект же https://github.com/lvgl/lvgl
Известный и непонятно куда разросшийся) пробовал его использовать для мк и монохромного дисплея и управления 4 кнопками, в итоге на второй тысяче строк у меня возникло стойкое ощущение, что я пишу CRM, всё снес, переехал на u8g2 Но умные часы и всякое цветное-переливающееся-тачевое на лвгл хорошо выходит, да.
nanogui-sdl (multiplatforms https://github.com/dalerank/nanogui-sdl)
nanogui (multiplatforms https://github.com/dalerank/nanogui)
Для тех, кто знает только Qt и GTK в первую очередь нужно было написать, что половина (а может и все, не смотрел) из представленного в статье -- это immediate-mode gui. И вообще рассказать, что бывают 2 вида режима GUI:
retain -- Qt, GTK, WinAPI и прочее традиционное. Вы описываете в коде интерфейс, а рисуется он в цикле событий, вам явно не видимом. Рассылает вам события, в которых вы действия и обрабатываете
immediate -- вы пишите код, который буквально рисует. Все, что еще не нарисовано (т.е. по коду находится ниже) еще нет. Помню, подумал, на сайте egui ошибка, как увидел, что там написано
if button("click").clicked() { ... }Подумал, забыли в замыкание обернуть, как оно работать-то будет? На самом деле вы и пишите внутри цикла отрисовки, и сразу же проверяете наличие флагов от событий и "на лету" меняете то, что нужно отрисовать.
Соответственно, в immediate режиме вы все UI строите с нуля каждый кадр, можете представить, что будет с энергопотреблением, если не ухищряться это все кешировать.
Я честно говоря как-то не задумывался о таком разделении, поэтому не описывал. С учетом разности подходов, кто из них retain а кто immediate сразу и не скажешь.
Что касается скорости: в качестве тестового стенда был 20-летний ноутбук с линуксом, если уж там не тормозит, то полагаю на нормальном десктопе и подавно.
Энергопотребление не замерял, но скорее всего это мало актуально, поскольку большая часть представленных библиотек — для редакторов либо изначально рассчитана на работу с GPU.
Современные рендереры уже давненько приспособились к тому, чтобы не перерисовывать то что не менялось, примерно также как и в retain режиме. Поэтому, пока у вас не рисуются графики и вы не тыкаете каждый кадр во все кнопки сразу просадка фпс и повышенное энергопотребление будет появляться исключительно из-за вашего кода.
Несколько лет назад оставлял коммент с подборкой из закладок.
Если не ограничиваться С/С++, то Home - HaxeUI можно посмотреть.
Сам использую и развиваю свое, но оно слишком недокументированно, чтобы им хвастаться.
Haxe вообщем-то известная штука, использование для веба видел в РФ.
Но она слишком уж универсальная, авторы пытаются захватить весь мир видимо )
Как ни забавно, но ровно наоборот. Автор – соучредитель геймдев студии, его позиция: "если мне не хватает каких-то интрументов, я их делаю, чтобы лучше делать игры". У них там все свое: и язык, и движок, и куча инструментов.
Т.ч. haxe сделан буквально для себя, а на продвижение всем вообще плевать. Иначе, с такими-то возможностями, он был бы намного популярнее.
с такими-то возможностями
Недостаточно просто заявить о «возможностях», их еще надо постоянно проверять и поддерживать, что дорого и сложно.
Поэтому и получается что проектов заявляющих поддержку «всего везде и сразу» — вагон, а в реальности все также используют стандартные вещи от крупных вендоров.
Недостаточно просто заявить о «возможностях», их еще надо постоянно проверять и поддерживать, что дорого и сложно.
В первую очередь – сложно. Дорого – это следствие, скорее даже один из способов решать "сложное".
Я пользуюсь haxe с его анонса, почти 20 лет. Разумеется, проблемы возникают. Случаются регрессии. Тем не менее, я склонен утверждать, что "проверяется и поддерживается" на уровне.
Огромное количество тестов, ci/cd, issue tracker – все на виду.
Сейчас над компилятором на фуллтайме работают, вроде, два человека + контрибьюторы. И справляются вполне не плохо.
Есть вещи, которые становится поддерживать сложно/нерентабельно, от них отказываются медленно и вдумчиво. В релизе haxe 5 планируют убрать поддержку c#. Потенциально она может появиться как внешний модуль (проект стороннего разработчкика, но пока не production ready).
Просто со сложностью можно бороться не только через заливание деньгами.
И haxe используется. Причем, мне кажется, что говорят о нем меньше, чем используют. Так что "заявили, наобещали и растворились" – вообще не этот случай.
Сейчас над компилятором на фуллтайме работают, вроде, два человека + контрибьюторы. И справляются вполне не плохо.
У них заявлена поддержа в виде target platform: Android, iOS, Windows, Linux и веб — слегка многовато для двоих разрабов, не находите?
В релизе haxe 5 планируют убрать поддержку c#
Полагаю речь про Mono и Unity ?
У них заявлена поддержа в виде target platform: Android, iOS, Windows, Linux и веб — слегка многовато для двоих разрабов, не находите?
Вы, наверно, не совсем понимаете, как это работает. Это как раз по поводу разных подходов к "управлению сложностью". По поводу двух разработчиков мне очень нравится вот эта история Beating the Averages.
Во-первых, haxe – это в первую очередь транспилятор. Результатом его работы является код на другом языке. Для поддержки множества платформ достаточно поддержать в качестве результата компиляции один язык, который компилируется на все эти платформы.
Так, например, многие современные языки не реализуют самостоятельно поддержку платформ, а используют LLVM. Это очень сильно упрощает разработку компиляторов.
Так вот, поддержать кучу платформ – сейчас не сложно, такую возможность и предоставляют современные языки через LLVM.
Во-вторых, уникальность haxe в том, что он позволяет получать (относительно человекочитаемые) исходники на хорошем спектре языков высокого уровня.
Это позволяет реиспользовать код на haxe в куче окружений. Например, игровой сервер может быть написан на java, php, node, ... и подключить игровую логику просто как модуь.
Или, например, запихать описание модели/сериализацию в нужный формат в блендер, через транспиляцию скрипта в питон (я так делал)
Можно писать на haxe игровую логику под разные движки. Для Defold – через транспиляцию в lua, для Godot – через GDScript и т.д.
И в-третьих, он интересен и хорош именно как язык, по выразительнсти и функциональности.
Мощная система макросов, развитая система типов + современные фишки типа паттерн-матчинга и, уникальный по-моему подход к введению zero-overhead абстракций через понятие абстракта.
Полагаю речь про Mono и Unity ?
Совсем не обязательно. Haxe выдает исходники на c#, а вы уже можете использовать хоть на сервере/десктопе в .net, хоть в юнити (и через mono, и через il2cpp) – везде, где можно писать код на c#/
Во-первых, haxe – это в первую очередь транспилятор. Результатом его работы является код на другом языке.
Ок, «код на другом языке не работает» — кто виноват? Куда бежать, кому заносить?
Все я прекрасно понимаю, просто есть отличие между законченным решением и вот такой универсальным транспилером, поэтому и поставил под сомнение вопрос поддержки столь обширного количества платформ.
везде, где можно писать код на c#/
Ээм это... очень смелое заявление, с учетом объемной спецификации C# и существенных отличий Mono (которая используется в Unity) и .NET.
Ок, «код на другом языке не работает» — кто виноват? Куда бежать, кому заносить?
Очевидно, https://github.com/HaxeFoundation/haxe/issues/
Там открываются, обсуждаются, фиксятся и закрываются тикеты и по конкретным таргетам (языкам). Для этого даже в начале тикета в квадратных скобках указывается таргет, если проблема специфична для него.
есть отличие между законченным решением и вот такой универсальным транспилером
Сформулируйте, пожалуйста.
Ээм это... очень смелое заявление, с учетом объемной спецификации C#
Вы путаете направление взаимоотношений. Это не # код запускается в haxe, для чего потребовалось бы учитывать все особенности полной спецификации.
Для того, чтобы сгениророванный код надежно работал в c# окружении, достаточно пользоваться необходимым минимумом из нее.
Сформулируйте, пожалуйста.
Полагаю вы не будете спорить с тем что на одном исходном коде решение не заканчивается?
Я честно говоря далек от геймдева, но полагаю что даже там необходимо учитывать разницу между платформами.
Для того, чтобы сгениророванный код надежно работал в c# окружении, достаточно пользоваться необходимым минимумом из нее.
Не работает такое, проходили уже.
Слишком быстро стали устаревать даже ключевые фичи, в пределах 5-7 лет обязательно что-то ломают на уровне языка.
Еще я не очень понимаю весь жизненный цикл: ну сгенерировали вы этот код из Haxe, а дальше что?
Допустим, пришлось внести какие-то ручные правки в этот сгенеренный код, повторная генерация из Haxe ведь его убьет, правильно?
И зачем тогда оно надо, если в итоге вам придется поддерживать две кодовых базы — на Haxе и сгенеренную, с правками.
Все это неоднократно наблюдалось в энтерпрайзе и Java — одних попыток построить систему вокруг кодогенерации штук 10 вспомню.
Но рано или поздно от кодогенерации избавлялись, как раз из-за необходимости ручных правок и долгосрочной поддержки.
Вы начали с уверенного утверждения:
есть отличие между законченным решением и вот такой универсальным транспилером
Из чего я предположил, что у вас есть критерии "законченного решения", которым не удовлетворяет haxe и экосистема вокруг него. Вероятно я ошибся и вы хотели сказать что-то другое.
Не работает такое, проходили уже.
Тоже весьма сильное заявление. Своей обобщенностью. Что не работает? Подход применияется, c# таргет используется, так что опровержение для вашей формулировки в общем виде у меня уже есть.
Еще я не очень понимаю весь жизненный цикл: ну сгенерировали вы этот код из Haxe, а дальше что?
Это хорошо, что вместо утверждений вы начали задавать вопросы. Дальше зависит от ваших задач и целей. Haxe – это инструмент, причем достаточно многогранный, решать им можно совершенно разные задачи.
Если ваша задача – делать инди игру, например, то вы берете движок OpenFL или HaxeFlixel, настраивайте его по инструкции, после чего запускаете вашу игру на haxe одной командой на любой платформе.
openfl test android
и игра запустится на подключенном телефоне,
openfl test html5
– откроется в браузере и т.д.
Другой вариант. Вы делаете сложную стратегию. И клиент с красивой графикой, допустим, на юнити. А сервер, допустим, на ноде. Красивую графику вы, понятно, на c# пишете. А логику: сколько ресурсов списать, каких солдатов улучшить – на haxe. И на билд-сервере есть задачи, которые после пуша запускают тесты, конвертят ресурсы и много чего еще, но среди прочего запускают haxe два раза с разными флагами и получают два артефакта .net dll и js файл.
Один попадает в проект на юнити, другой – в сервер на ноде. И клиент в результате может относительно долго играть в оффлайне, записывая действия пользователя. Когда подключится – отправит серверу эти действия. А сервер тоже выполнит их и будет уверен, что пользователь не жулил с результатами.
Ну или вот есть у меня там игра на openfl. А в игре я мешки использую и формат у меня свой, мне удобный. Я пишу на haxe маленькую утилиту-апи.
Для использования как-то так:
var m = new Mesh();
m.addVert(0,0,0);
export(m, "asset.json");
Транспилирую в питон и кидаю в каталог аддона к блендеру.
Уже на питоне пишу импорт утилиты как библиотеки и использую готовый экспорт в нужный мне формат.
Но рано или поздно от кодогенерации избавлялись, как раз из-за необходимости ручных правок и долгосрочной поддержки.
Ручные правки не используются. Человекочитаемые исходники помогают, если реально напоролся на случай, когда код работает по-разному и нужно разобраться. После этого либо переписываешь исходники haxe по-другому, либо репортишь баг. Либо и то и то. Ситуация в целом экстраординарная.
А просто исходники на разных языках нужны, чтобы использовать в соответствующих окружениях. Я перечислил далеко не все движки, под которые можно писать код на haxe.
Напомню, 20 лет уже проекту. Посмотрите только по стиму суммарно движки
Lime/OpenFl, Heaps.
https://steamdb.info/tech/
В веб-проектах распространение еще шире. Ничего общего с in-house наколенной кодогенерацией технология не имеет.
Из чего я предположил, что у вас есть критерии "законченного решения", которым не удовлетворяет haxe и экосистема вокруг него
Никогда не использовал Haxe, но полагаю сравнивать стоит со всем известным Unity, так что пусть будет Unity — законченное решение, поскольку содержит в себе все необходимое для разработки игры с нуля — от редактора 3Д‑сцен до редактора кода и собственно компиляции в готовое приложение.
Что не работает?
Ну я же написал «в пределах 5–7 лет ломают сам язык», те код написанный пять лет назад легко может не собраться в новой среде.
Ручные правки не используются.
Могу привести один из немногих известных мне примеров, связанный с геймдевом: поддержка ввода несколькими пальцами и сложные движения на мобильных устройствах — все эти свайпы и сложные клики.
Даже в Unity их поддержка реализовывалась через вставку нативного кода на Swift/Objective-C, но там предусмотрели подобное и есть возможность подобных вставок.
А как вы предполагаете забарывать такое без ручных правок на Haxe?
Никогда не использовал Haxe, но полагаю сравнивать стоит со всем известным Unity, так что пусть будет Unity.
Haxe – язык программирования. Unity – игровой движок. C# – язык программирования. На нем пишут под юнити. Понятно, к чему я веду?
Если не понятно: язык/тулинг корректно сравнивать с языком, движок – с движком. Примеры движков я вам уже привел. Можете еще Heaps - Haxe Game Engine - Heaps.io Game Engine посмотреть.
Ну я же написал «в пределах 5–7 лет ломают сам язык», те код написанный пять лет назад легко может не собраться в новой среде.
Ну у вас не работает, а у других работает. Если я не ошибаюсь, то многие изменения C# как языка – именно на уровне языка. Новый сахар часто компилировался в старый il код. Существует ли сейчас проблема, что dll с il кодом, собранная каким-нибудь C# 5 не может быть использована в современном проекте?
А как вы предполагаете забарывать такое без ручных правок на Haxe?
В haxe это предусмотрели более гибко и удобно, чем в юнити. Интероп с окружением таргета – это тоже сильная сторона haxe.
https://haxe.org/manual/lf-externs.html
Нюансы, разумеется, зависят от таргета. В общих чертах – не уникальо, описываем в терминах haxe, как вызывать платформенный код, собираем и/или исполняем так, чтобы вызовы были доступны.
А концепция Abstract про которую я писал в контексте zero-overhead в комбинации с экстернами вообще позволяет творить чудеса.
Можно написать обертку вокруг нативного класса так, что из прикладного haxe кода она будет выглядеть, как haxe класс, в сгенерированном коде будет вызов конструктора нативного класса. При этом в абстракт можно еще дописать методы, которые по желанию заинлайнятся вокруг обращения к нативному или превратятся в статические.
через вставку нативного кода
Но не редактирование же вывода транспилятора! Такой способ тоже доступен на уровне языка.
Что-то вроде
#if java
untyped __java__("native java code here");
#elseif js
untyped __js__("native js code here");
#end
Ну и мультитач давно доступен на уровне движков, по крайней мере, тех, что я называл.
В общем, я вижу, что в вас говорило совершенно необоснованное предубеждение перед мощной технологией просто потому что "так классно рассказывают, не может же на самом деле так быть".
Ну у вас не работает, а у других работает.
Наверное не самый показательный пример, зато самый свежий.
Существует ли сейчас проблема, что dll с il кодом, собранная каким-нибудь C# 5 не может быть использована в современном проекте?
Именно ради таких dll и устанавливают по несколько рантаймов .NET разных версий.
На моей памяти: 3.5, 4.x и Core — все имеют проблемы с совместимостью.
Что-то вроде
Ага, значит подобные вставки все же поддерживаются.
в вас говорило совершенно необоснованное предубеждение перед мощной технологией
Я же сразу написал, что не использовал Haxe, но спасибо за столь подробные ответы — думаю кому‑то из читателей пригодится.
Наверное не самый показательный пример, зато самый свежий.
В общем, моя гипотеза в том, C# код написанный максимально стандартным образом будет поддерживаться.
Например, список совместимости
https://www.nuget.org/packages/Newtonsoft.Json
достаточно приличный и, как я понял, это всле для одной ревизии исходников. Так что вряд ли стоит ожидать, что с# таргет текущей версии компилятора перестанет поддерживаться c# экосистемой в обозримом будущем.
Ага, значит подобные вставки все же поддерживаются.
Технология делается 20 лет исключительно с целью применения. Ее вообще не пытаются кому-то втюхать. Разумеется, большинство практических задач решено.
Да, рад, что пришли к консенсусу и тоже надеюсь, что кому-нибудь пригодится.
На скриншоте, подписанном как «Call of Duty» на самом деле меню настроек из Battlefield 3!
Не мог пройти мимо…
Кажется хотя бы в начале статьи, нужно было упомянуть Avalonia UI. Прекрасное решение для крсс-платформенных приложений. https://github.com/AvaloniaUI/Avalonia
Необычный интерфейс