Файловый диалог на xcb + Cairo

на xcb шо-то не нашел... но есть на X11. весьма няшный диалог, между прочим :)

https://github.com/x42/sofd

Спасибо, это почти то что нужно. Интегрировать в мой проект можно легко, но немного выбивается потому что Xlib а не xcb, и слишком сурово - все на X11. Хотя для файлового диалога тот же cairo не сильно нужен.

Скорее всего буду использовать это, с минимальными изменениями. Еще раз спасибо!

плагин

GUI реализован прямо на XCB

збс, а потом ноют что вейланд не готов

А на чем, по-твоему, должно быть реализовано GUI в плагине?

на кроссплатформенной библиотеке, разумеется

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

не вижу, как это должно помешать, но в таком случае гуй должен входить в апи плагинов

Мешает тем, что два разных фреймворка, а особенно разные версии одного и того же, трудно уместить в одно адресное пространство - они нехило конфликтуют. Каждый фреймворк создает свою event loop без расчета на то, что их внутри одного процесса будет несколько после загрузки плагина, который притянет свой фреймворк со своей event loop. Опять конфликт.

Гуй должен входить в api плагинов, да. Я двумя руками за. Только это пока слишком сложно для разработчиков хостов, особенно свободных. Они еле основную функциональность DAW систем реализовывают.

Поэтому имеем плагины на api иксов. И я согласен, это ппц.

Вообще в поставке иксов всегда были наборы базовых виджетов. Я думаю тебе нужно чуть больше погуглить.

Кстати, а может тебе Open Motif подойдёт?

Да, но я хочу сразу готовый диалог и на голом api либо на cairo. Тянуть в плагин какие-либо тулкиты крайне не желательно.

Хорошо, а выдрать из xdialog?

Глянул - он же вроде на gtk1.

на кроссплатформенной библиотеке, разумеется

Да что уж там, сразу на JS писать. И тащить с собой ноду.

чистое вин апи ваше всё?

Вообще есть такая платформа, где все аудио плагины прямо на JS, не только интерфейс но и обработка звука. Но там без ноды, все это целиком в браузере работает.

WinAPI!

Было бы круто, только где ж я его возьму. Я ж не под ReactOS разрабатываю :)

Сделай просто поле ввода, куда нужно вводить путь, и приделай к нему возможность копипасты. Иногда бывает проще выбрать файл в нормальном ФМ и скопировать его путь, чем пользоваться наскоро сделанными диалогами.

Существовала версия на чистых иксах

Нет уж, это делать с гитарой в руках крайне неудобно. zenity обеспечивает нормальный ФМ, и если не будет получаться сделать сравнимый по удобству, я просто оставлю как есть - и то будет лучше чем что-то вставлять.

Ну не знаю. Чем оно в этом аспекте отличается от пошариться в диалоге, чтобы найти файл? Это во-первых. А во-вторых — лично я с гитарой в руках не только табы с аккордами записывать могу, но и программировать иногда умудряюсь :) Не вижу препятствий немного покликать мышкой с гитарой в руках.

Если подумать, то да, не помешает сделать поле с возможностью ввода и вставки, помимо диалога. Так и сделаю, пожалуй.

Как в твоей больной голове кроссплатформенность влечет за собой джаваскрипт?

Да.

Графические тулкиты с единым языком программирования, поддерживающие большее количество (вид устройства * количество экземпляров устройства) чем веб-браузер с жаваскриптом, в студию.

Начнем с того, что браузер с джаваскриптом «кроссплатформенный» ровно в рамках мажорных ОС и архитектур. Закончим тем, что тулкиты наподобие Gtk, Qt, Tk, fltk, nuklear (из пришедших в голову) вполне покрывают потребность в кроссплатформенности.

А еще умножать на количество экземпляров абсолютно некорректно. От того, что ты в десять раз больше кусков кремния напечатаешь, у тебя программа не изменится. Считать надо количество ОС * количество архитектур.

Начнем с того, что ты не предоставил списка.

От того, что ты в десять раз больше кусков кремния напечатаешь, у тебя программа не изменится.

Мы не обсужадем количество программ в вакууме. Мы обсуждаем самый широкораспространённый (специально для умственно отсталых - распростарнённый среди людей, кроме людей этот интерфейс никому больше нахер не нужен) графический интерфейс.

Закончим тем, что только умножением на количество экземпляров можно понять охват целевой аудитории в людях. За неимением варианта посчитать человекочасы за конкретным интерфейсом - лучшее, что есть.

тулкиты наподобие

Давай, до свидания.

Гитаропатия (комментарий)

Извините за оффтоп, но мне кажется это может быть важно для curufinwe.

На моем ноуте где-то в 10 раз медленнее риалтайма идет.

А нельзя ли сделать так, чтобы со схемы spice генерировался импульс? Тогда ведь будет намного проще считать и можно с помощью того же jconvolver обрабатывать звук в реальном времени. Или есть какие-то мешающие ограничения?

Идея очень крутая, кстати.

А нельзя ли сделать так, чтобы со схемы spice генерировался импульс?

Так вот, тут самое интересное!

Просто импульс конечно нельзя, потому что усилитель система нелинейная, перегруз импульсом нельзя получить. Но - любой гитарный усилитель можно разложить на три компонента - два фильтра и перегруз (нелинейный искажатель) между ними. И если снять их характеристики, то можно легко в риалтайме получать звук любой схемы, не идеально точно, но довольно близко.

Я это реализовал в редакторе для профилей плагина tubeAmp. Редактор сейчас активно готовлю к выпуску.

А вообще, на основе моих наработок, можно сделать программу, где собираешь схему, она внутри себя обсчитывает профиль и потом все работает в риалтайме. Весь код для обсчета у меня уже есть, вопрос только в графическом интерфейсе.

А пока - полученный профиль можно использовать с плагином tubeAmp из моего набора KPP. Только мне надо зарелизить редактор, чтобы снимать профили со spice мог кто-то кроме меня :)

усилитель система нелинейная, перегруз импульсом нельзя получить

Теперь понятно. Усилитель раскладывается типа «входной фильтр → перегруз → выходной фильтр»? Наверное сложно подбирать параметры фильтров, ведь надо чтобы они были быстрые, навряд ли тут подойдут свёртки с длинными импульсами или БПФ. Я, если честно, даже понятия не имею как точно подобрать фильтр под заданную характеристику.

вопрос только в графическом интерфейсе

С хорошей документацией, думаю, на первых порах можно и из консольки позапускать :)

ведь надо чтобы они были быстрые, навряд ли тут подойдут свёртки с длинными импульсами или БПФ.

Свертки с длинными импульсами (до нескольких секунд), вычисляемые через БПФ работают довольно быстро для современного железа, я использую их. Использую библиотеку zita-convolver, она запускает вычисление в несколько потоков и работает довольно эффективно.

https://github.com/brummer10/Xputty

Вот спасибо.

Оказывается, разработчик guitarix за меня все уже сделал :)

Люблю опенсорс!

https://github.com/x42/sofd

попробовал, не умеет юникод (

Ага, к тому же sofd меня смутил тем что он на голом Xlib. Так что лучше дернуть пример из Xputty.

а запускал примеры? страшноваты немного)

Фон и кнопки перерисовать не проблема. Проблема - что сам диалог не шибко удобный. Придется сильно переписывать, хотя бы чтоб папки отображались там же где файлы и в них можно было заходить, а не через отдельный виджет выбирать.

Хотя там кода немного.