Да, звучит все это все несколько пренебрежительно к аудитории хабра, если требовать только обратной связи. Но достаточно ли обернуть идеи и задел техническими подробностями, интересными задачами и их решениями, чтобы статья стала хоть немного ценной для сообщества? Например, я не видел на хабре статьей раскрывающих проблему realtime audio. Может стоит просто написать об этом, но только в контексте конкретного проекта?
Кручусь в своей теме более 4-х лет и надеюсь, что за это время я что то понял и понял правильно. Но меня сподвигло написать статью и в следствии этот вопрос только неуверенность в конечном продукте. Каким он должен быть чтобы максимально быть полезным не для меня, а для других? Да, сейчас есть реализованное "ядро", которое решает только лишь базовые технические проблемы, но оно будет использовано при решении конкретных задач пользователей. И вот в выборе этих задач я сомневаюсь. А поскольку набор таких задач будет определять конечный "внешний вид" проекта, я на данном этапе не могу предложить что то более, чем просто идею, свое представление о use cases и несколько подробностей о технических проблемах, которые пришлось преодолеть при реализации прототипа.
Грубо говоря, есть идея, есть задел, есть желание, но нет пользователей.
В идеале, мне необходимо напрямую обращаться к специалистам той области, задачи которой я пытаюсь решить. Это действительно очень важно, но ведь статья на техническом ресурсе это совсем другое и не менее полезное, как мне кажется.
Евгений Шатунов, спасибо за ответ и интересные ссылки. Да, рассматривал конкретно nuklear и imgui. На первом даже пробовал сделать несколько "аудио" виджетов. Как оказалось, сделать свои виджеты на этих библиотеках довольно нетривиальная задача, а в некоторых нет даже возможности кастомизировать существующие. Да и немного настораживает мысль, что если в программе совершенно ничего не происходит, то по логике Immediate UI цикл обновления дерева виджетов не должен останавливаться. Возможно это может быть и полезно в некоторых случаях, но что если элементов на экране действительно очень много? Например, 32 канала микшера, для каждого из которых нужно отрисовывать множество ручек, кнопок, индикаторов. Каждый элемент при каждом кадре генерирует новый буфер команд для рендера, что кажется просто расточительством. Хотя с другой стороны, почему не кэшировать буферы тех частей дерева, которые точно не изменились на текущем этапе. К сожалению, такого я не нашел в рассматриваемых библиотеках.
Возможно после работы с realtime audio, я уже получил некоторую форму профдеформации и повсюду мерещатся проблемы с производительностью. Видимо по этому я и решил задать вопрос о GUI здесь на хабре.
А вообще, Immediate UI очень интересная идея. Конечная "верстка" приложения чем то даже напоминает ReactJS. Можно писать гуи на старом добром Си и при этом не запутываться в коде.
Спасибо за ответ и прошу прощения. Конечно мне надо было бы уточнить подробнее, что я имел в виду. Я дополнил вопрос.
Если честно, то мне пришлось столкнутся с подобными корпусами от Exegate/Procase как раз с высотой в 2 юнита, но качество исполнения этих корпусов оставляют желать лучшего.