dlangui
dlangui copied to clipboard
Library for window creation? [RU]
В свое время были разговоры чтобы в Фобос добавить примитивы для создания окон. Пару проектов заглохло. Сейчас вот такой пилится http://code.dlang.org/packages/oswald
Вопрос. Как сейчас у dlangui ситуация обстоит? Через что все рисуется и будут ли плюсы при миграции на что-то подобное?
Точнее так. Подобная либы уже используется? Переход на такую вот штуку дал бы какие-то плюсы?
Я не эксперт по dlangui, но примерно так
- создается окно методами winapi,
- создается буфер отрисовки для окна в памяти (буфер является абстрактным так что в целом все зависит от реализации, можно сделать свой собственный например для вулкана, наверное)
- нативное окно передает события, когда нужно нарисоваться, здесь же можно пройти до реализации (BitBlt с winapi)
- каждое окно содержит главный виджет и рекурсивно отрисовываются в полученный буфер
1 - https://github.com/buggins/dlangui/blob/master/src/dlangui/platforms/windows/winapp.d#L287 2 - https://github.com/buggins/dlangui/blob/master/src/dlangui/platforms/windows/winapp.d#L469 3 - https://github.com/buggins/dlangui/blob/master/src/dlangui/platforms/windows/winapp.d#L774 4 - https://github.com/buggins/dlangui/blob/master/src/dlangui/platforms/common/platform.d#L921
Быстро пробежавшись по описанию и примерам библиотеки по ссылке могу сказать что выглядит сомнительно. Создание простейшего окна и обработка событий через winapi занимает от силы 50-100 строк(добавить к нему opengl/vulkan/directx контекст еще примерно столько же), при этом большую часть займет передача параметров окна в структуре при создании. Для х11 не сильно сложнее. Основная сложность может быть с макосью, если чего-то нет в старом API - Carbon(чистый C) то все будет зависеть от состояния бриджа в obj-c для использования Cocoa, либо потребуется делать "нативные" обертки, и конкретно в данном случае видимо используется SDL в котором именно так и сделано.
@Superbelko а смысл тогда подобных либ в чем?
В данном случае автор указал что для личных нужд.
Но теперь вот представим что подобное решили добавить в phobos - ок отлично, создали окно, и что теперь делать? Как добавить кнопку? Текст? Поле ввода? Какой-нибудь диалог? Начнем добавлять обертки для системных контролов в библиотеку языка? А что если какого-то контрола нет в одной из систем? А что если предположим джойстик на одной из систем тоже передает события в окно? А что если нужно прозрачное окно и/или без рамки? А если какая-то из систем не предоставляет такой возможности совсем? Что если нужна своя хитрая логика для поведения окна? Начнем изобретать wxWidgets или Qt? Кто это потом будет поддерживать? Что делать на android?
В том то и дело! имхо, вместо очередного "универсального" велосипеда лучше иметь просто привязки как это уже частично сделано с winapi и довести до ума бридж в objective-c, если он еще не готов, чтобы не городить библиотек-оберток.
Думаю стоит заканчивать оффтоп.
Смысл такой библиотеки в стандартизации. Для создания окна достаточно будет пользоваться фобосом и не задумываться (до определенной степени) как там работает под капотом. Такая библиотека будет использоваться более широко, чем велосипед в отдельном проекте и со временем станет более отлаженной, надежной и функциональной.
Что касается конкретно oswald
- то это просто для себя и изначально не претендент на включение в фобос.
Такая библиотека имеет смысл. Но кроме создания окна, она должна предоставлять методы рисования графических примитивов и/или создания контекста OpenGL, а так же обработку событий клавиатуры и мыши.
Вот пример: https://github.com/Devisualization/window