GTK2-NG: форк библиотеки GTK2

Во-первых, не путай ipc и форматы данных. Во-вторых, формат в любом случае будет зависеть от того, какие данные ты передаёшь. Если ты например хочешь зачем-то передать в арфметический калькулятор jpeg-картинку, то никакие dbus-ы тебе в этом не помогут.

за это люблю опенсорс

Если цель эксплуатация уязвимости, то вполне поможет

В минте пока gtk2 есть. И она мне буквально на днях нужна была что бы hptalx собрать. Это такой графический командный фронтенд и файл-менеджер для калькуляторов HP. Связка там через kermit, но работает...

Так что нужно пока еще...

Первый глобальный. Скорее всего, именно он потом будет и в других дистрибутивах (в арчевом AUR, например).

взять gtk2-ng, добавить там поддержку вяленда

И HiDPI. После этого тормозные уродливые GTK 3 и GTK 4 можно закапывать.

Ну доспустим, соглашусь, gimp и inkscape умерли. Альтернативы им какие будут?

Толсто, по шрековски. Умерли иксы и gtk2. А gimp и inkscape пересели с пусть красивого и элегантного но тонущего парусного икса на уродливый, вонючий но пока еще непотопляемый пароход вейланда. С соответствующей сменой gtk2 на gtk3+.

Вот-вот, поэтому нужно по нормальному GTK3 форкать или писать какую-нибудь прослойку чтобы GTK3 приложения работали на GTK2-NG.

или писать какую-нибудь прослойку чтобы GTK3 приложения работали на GTK2-NG

gtk3-to-gtk2.

И HiDPI. После этого тормозные уродливые GTK 3 и GTK 4 можно закапывать.

"

А вот если объединить Солярис+Чпукс+Труша+ОпенВМС то это будет просто Unix. У лялиха тогда никаких шансов на выживание воопще не будет.

А вот если скрестить змею и ежа, то это будет просто три метра колючей проволоки. У пингвина тогда никаких шансов на выживание воопще не будет - умрет от смеху падстулом."

–anonymous (lorquotes)

Во-первых, не путай ipc и форматы данных.

Не распарсил, что ты этим хотел сказать.

Во-вторых, формат в любом случае будет зависеть от того, какие данные ты передаёшь.

Каким образом вызывающая программа (клиент) должна узнать, что умеет целевая программа (сервер)? Какие данные, куда она должна давать, в каком формате? Как серверу ответить клиенту, что он «(не)молодец»? Клиент/сервер в процессе сдох, как дальше жить?

Короче, так много вопросов, и так мало ответов. Но ты пишешь какую-то фигню про картинку в калькулятор.

Чисто технически и демон DBus работает поверх uds. Так что я опять не понимаю, чем ты недоволен.

Гном-2 ВНЕЗАПНО заработает в современном окружении

Увы нет…. Копаюсь в портировании МАте который суть форк второгнома. Там масса костылекодинга на иксовых вызовах - и то что мате портирован сто лет в обед на гтк3, а гтк3 те же сто лет поддеривает вейланд - не означает что все рабоает. И в крысе та же история.

Да и тяжеловесы вроде хрома, мозиллы, либры - уже точно не будут возвращаться назад. Они и вперед тоже не сильно спешат - так что гном с его галопом по европам вернее по версиям гтк -4, 5, уже 6 на горизонте - тоже ускакал далеко за границы корпоративного интереса

Конечно инициализация контекста там слегка по-ублюдски сделан

Слегка???? Да это апофеоз ублюдства. Там все сделано так чтобы твой порог входа в это был максимально высок.

Не распарсил, что ты этим хотел сказать.

IPC это возможность пересылать некие последовательности байт между процессами. Интерпретация этих байт уже другая тема, не надо её к ipc приплетать. Так вот, dbus для пересылки байт требует демона и не учитывает chroot-ы. sockets/pipes/shm этими недостатками не обладают и кроссплатформенно есть в любом юниксе (кроме может быть каких-то совсем древних).

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

Каким образом вызывающая программа (клиент) должна узнать, что умеет целевая программа (сервер)?

Очевидно же как. Вот тебе пример: если есть сокет /var/run/log, то он поддерживает приём данных в формате syslog. Если такого сокета нет - то данные слать некуда.

Какие данные, куда она должна давать, в каком формате?

Что она хочет слать - зависит от программы. Это не сфера ответственности коммуникации.

Как серверу ответить клиенту, что он «(не)молодец»?

Отправить в ответ пакет с ошибкой например. Или просто дропнуть соединение.

Клиент/сервер в процессе сдох, как дальше жить?

Если какая-то из сторон умерла, то коммуникация между ними неактуальна.

Так что я опять не понимаю, чем ты недоволен.

Тем что там лишний ненужный демон. Прям как pulse/pipewire над alsa.

VueScan
в свое время, когда переводил фото-архивы в цифру - использовал только его (ни какие прочие аналоги даже рядом не валялись... на целый космос отставали во всем). использовал в основном под макакой, т.к. под ней весь фото/графико-софт.

как с ним сейчас не знаю. :о)

он и для себя, вроде как, требует GTK2?! :o)

Ну вот, то что я тебе в первом сообщении написал: каждый строчит как хочет.

Очевидно же как. Вот тебе пример: если есть сокет /var/run/log

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

Что она хочет слать - зависит от программы.

facepalm. А программа, которая должна обработать как должна понять, что ей прислали?

Отправить в ответ пакет с ошибкой например. Или просто дропнуть соединение.

facepalm-ище. Нагиев.jpg

А отправить она его должна куда? Это должно быть TCP соединение? Открывать второй udp сокет? Синхронизацию рулим руками в каждой софтине?

И да, сигналы мы как будем реализовывать? Ну их нафиг?

Если какая-то из сторон умерла, то коммуникация между ними неактуальна.

А если повисла?

Тем что там лишний ненужный демон

И всем, кроме тебя видимо, очевидно что он делает. Уже даже сделали, «более лучший» демон (dbus-broker).

Вообще, лучше перелопатить xwayland так, чтобы любой запущенный под xwayland wm становился композитором для wayland.

Опенгл разрабатывался не для игрушек а для 3д софта, CAD и CAE. Они на вяленый так и не перешли

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

Из документации к syslogd или дистру. Если прога хочет слать логгеру логи, то очевидно надо сначала ознакомиться с документацией логгера. И вовсе даже не только для того, чтобы узнать как называется сокет.

facepalm. А программа, которая должна обработать как должна понять, что ей прислали?

Если логгер открыл сокет /var/run/log то слать ему должны логи в формате syslog. Всё остальное можно дропать т.к. очевидно это какие-то баги. В любом случае, что за прога бы ни была, у неё в документации надо указать что она принимает и как. Ты хочешь, чтобы у тебя две альтернативные друг другу проги принимали данные в одинаковом формате, а отправляльщики не должны были думать какая там из них. Ну, в случае в разными сислогами это само собой получилось и никаких dbus-ов для этого не потребовалось.

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

А отправить она его должна куда? Это должно быть TCP соединение? Открывать второй udp сокет? Синхронизацию рулим руками в каждой софтине?

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

И да, сигналы мы как будем реализовывать? Ну их нафиг?

О чём речь? kill -9? Как они связаны с передачей данных?

А если повисла?

Отвиснет - прочтёт что ей прислали. А что тут можно ещё сделать?

И всем, кроме тебя видимо, очевидно что он делает. Уже даже сделали, «более лучший» демон (dbus-broker).

Да я вообще замечаю что кучу всякого мусора в систему суют. Ни одного практически полезного применения dbus не замечал.

Из документации к syslogd или дистру.

Т.е. в рантайме никак? К каждому калькулятору будем сокеты в /var/run/ создавать (а также семафоры, но уж хрен с ними)?

Очевидно, в тот же канал связи откуда пришли данные

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

О чём речь?

О передаче сообщений один-много. Трахаемся с мультикаст группами?

Отвиснет - прочтёт что ей прислали.

В тоже время клиент курит бамбук?

Ни одного практически полезного применения dbus не замечал.

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

Вообще, как мини-пример: вот (gitflic.ru) плагины к моему пет-проекту. Там есть управляющие и для DBus и твой любимый REST на сокетах. Плагин DBus был сделан за день, в основном. И он отлично работает.

Плагин сокетов, чтобы сделать тот-же плюс-минус, самый протокол, потребовал некоторого секса и этими самыми сокетами (при том, что я взял TCP), а также реализации целой протокольной библиотеки с json (в которой я до сих пор не уверен, что где-то не накосяпорил), чтобы клиент и сервер ОДИНАКОВО трактовали протокол. И это для простенького API. И это я ещё не заморачивался версионированием.

И вот этот весь траходром, ты предлагаешь реализовывать в каждой софтине, с ФС в роли шины, с кастомным протоколом сериализации в каждой, без четкого маршалинга и корректной отработки ошибок? Сильно.

Отличная новость. Если «выстрелит», то было бы неплохо..

Ура! Не умрёт моя любимая древнятинка!

А гтк1 никто воскресить не хочет? А следом можно второгном под бсд патчить

10 лет трудились, переписывали на gtk3...

И теперь gtk3 объявлен устаревшим — нужно срочно портировать на gtk5 и пере-писать на расте.

LD_LIBRARY_PATH=$(pwd) <program>

gnome-disks: symbol lookup error: /lib/x86_64-linux-gnu/libhandy-1.so.0: undefined symbol: gtk_popover_popdown

xed: symbol lookup error: /lib/x86_64-linux-gnu/libxapp.so.1: undefined symbol: gtk_overlay_add_overlay

Не работает, увы.

где они бжлад умерли? Пишу сюда с иксов и браузера на gtk2. У вас глюки какие-то наверно...
А вот от inkscape и gimp пришлось отказаться, эти проекты долгое время были в стагнации, после чего сшизились окончательно...

Возможно. Мне эта часть крайне не понравилась как минимум из-за того, что невозможно знать заранее, какие расширения понадобится всем динамическим загружаемым модулям, а пересоздавать инстанс или логическое устройство потом обычно не вариант. Но основную задачу вулкан решает - работать с возможностями gpu напрямую. Записал коммандные буфферы, потом отправляешь по мере необходимости (обычно submit превращается в один-два ioctl, минимальный оверхед)
Да, навнрно можно было сделать лучше. Но это непросто - описать и стандартизовать возможности многих разных gpu в единое тонкое API.

Кстати да, и для их задач он прекрасно подходит. Но на них его полезное применение пожалуй и закончится

вот именно пора дропать gtk3 и переписывать на gtk2-ng

А это интересно, только его допиливать и допиливать для многих приложений...

VueScan прекрасно работает, выходят новые версии

Хоть какая-то польза от существования Devuan?

synaptic например. И причем в Alt p11 этот synaptic начали вытеснять из дистрибутива, типа на неподдерждиваемом GTK2, несмотря на то что полноценной замены synaptic в альте нет.

GUI к LV2 плагинам некоторым. Которые cinelerra-gg использует именно как gtk2 хост.

ну вот и славно!
п.с. а на каком бекэнде сейчас пишут? я даже не могу вспомнить на чем они тогда писали (шибко своеобразно выглядел интерфейс... что не мешало ему отлично работать)

Пишу сюда с иксов и браузера на gtk2.

Этот броузер на gtk2 что-то кроме ЛОРа открыть может?

Сюда то можно и из консольного линкса писать.

да имхо не сильно надо.

xsane хорош не тем что дает картинку, а тем что позволяет полностью управлять сканером как родная вендовая прога.

всяких недоделок которые позволяют просто получить картинку - тонна, а в этом xsane можно выставлять режимы цветности, крутить яркость-контрастность-цветокоррекцию (причем не программно - обрабатывая полученную картинку, а именно управляя сенсором сканера что важно), можно ограничить любую область сканирования - опять же железно - то есть если ты сканируешь фотку из поляроида то сенсор сканера проедет не все поле а ровно до конца фотки. Он позволяет управлять авоподатчиком (и любыми другими хитрыми приблудами подачи оригиналов), позволяет делать многостарничные pdf из скана, позволяет подключать распознавалку типа tesseract и превращать сканы в текст… Это только то чем я пользовался, возможно есть и еще

У вулкана есть одно преимущество - это не рисоваьное апи, а апи доступа к железу гпу. То есть по идее это может работать ( и работает - например в llm есть возможность считаьь нейронки через вулкан) вычислительным стеком. Но за это заплачено адовым усложнением самого АПИ. Мало того что это стало сложно написать, еще сложнее написать это хорошо.

Пример - есть wlroots. В нем сейчас активно пилят рендерер на вулкане. При этом рендерер на gles2 жрет в полтора раза меньше ресурсов cpu/gpu делая тоже самое. и вот не прошло и … - появился MR который таки исправляет эту ситуацию. То есть все очень похоже на вейланд и иксы. Ижея была - вот иксы (и рпенгл) - все делабт сами и ты не можешь этим управлять, в мы вот дадим тебе возможность (и вменим в обязанность) все это реалищовывать с нуля самому - ну ты же конечно сделаешь лучше и эффективнее! а по факту - все вот это привело к тому что все получается как правило хуже и неэффективно совсем, и приходится очень основательно в этом копаться чтобы сделать хотя-бы не хуже.

А что он по-твоему не должен открыть? Как способность что-то открыть связана с gtk?

Пример - есть wlroots

wlroots - спонсор моего хейта в сторону wayland, уже не читая дальше можно считать его контрпримером, я не поверю в то, что они хоть что-то осилят нормально

активно пилят рендерер на вулкане

какой в этом смысл, если opengl'овые приложения могут отдать текстуру в том виде, в котором она с вулканом не заработает? Сомнительная задача сама по себе

все вот это привело к тому что все получается как правило хуже и неэффективно совсем

Окей, примеры где это неэффективно будут? Не в виде неосиляторства, а реальные?
Вот у меня есть: на ivybridge с opengl рендером serious sam fusion примерно в 2 раза быстрее, чем с vulkan. Но здесь есть нюанс: этот GPU никогда не поддерживал вулкан, а сам драйвер в mesa говорит что unsupported и используйте на свой страх и риск. Тем не менее, хотя бы работает.
Но это всё не касается реально разрабатываемых и поддерживаемых драйверов

Рисовальное API это cairo, xrender, GDI
А вот вулкан это API для отправки команд в GPU, это верно.
Только вот поверх вулкана делаются свои небольшие рисовальные API под собственные нужды, вроде того же бэкенда для imgui.
Только вот и opengl этим самым рисовальным API не является. Это API для отображения дисплейлистов из CAD и подобного, из которого, огромными усилиями и натягивая сову на глобус вырисовывали подобие вулкана. Получился какой-то полумер, чуть что начинающий ждать gpu и блокируя cpu, имеющий мало общего с реальными задачами. А удобных функций вроде «нарисуй квадрат», «заблить сюда вот картинку» нет и не было. Есть glBlitFramebuffer, но он появился весьма не сразу и требует кучу лишних действий, это тоже не рисовальное API

При этом рендерер на gles2 жрет в полтора раза меньше ресурсов cpu/gpu делая тоже самое.

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

Т.е. в рантайме никак? К каждому калькулятору будем сокеты в /var/run/ создавать (а также семафоры, но уж хрен с ними)?

Чем сокет в /var/run хуже имени в дереве dbus? И имя всё равно в документации выяснять. Или в dbus как-то можно выяснить, что в udisksd надо отправлять через org.freedesktop.UDisks2?

О передаче сообщений один-много. Трахаемся с мультикаст группами?

Зачем? У нас же файл-сокет.

при том, что я взял TCP

Ещё бы сразу HTTPS взял. Было бы ещё больше секса. Зачем что-то кроме файла для взаимодействия внутри одного компьютера?

а также реализации целой протокольной библиотеки с json

В случае dbus она просто уже неотъемлемая часть libdbus. И всё равно в любом нетривиальном случае всё равно нужен свой слой: даже типа для даты нет.

Вообще, как мини-пример: вот (gitflic.ru) плагины к моему пет-проекту.

Вот даже на этом примере. Смотрю документацию по плагину dbus для PluginInfo: <arg name="Info" direction="out" type="(uqqusssss)"/>.

Без дополнительной информации не вытащить.

также реализации целой протокольной библиотеки с json

Ты свой велосипед делал? А почему не https://github.com/json-c/json-c ?

И вообще, зачем json на отправку пары чисел в запросе и, фактически, списка строк в ответе?

с кастомным протоколом сериализации в каждой

Зачем кастомный? Он в любом случае кастомный. Поверх JSON/DBus или поверх строк или поверх protobuf. В любом случае это лучше, чем «(uqqusssss)» в качестве типа значения.

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

Игры меня честно говоря волнуют мало, просто тупо выжать фпс прожигая кристаллами гпу и цпу дыры в металле особого ума не надо, надо просто больше ватт тепловыделения. И тут вулкан как раз имеет преимущество - gl сам там внутри себя решает как распараллеливать процессы, а вот вулкан возволяет нагрузить по максимуму абсолютно все ресурсы и задействовать то что в gl простаивало и ожидало своей очереди.

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

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

Я предыдущему оратору очень «тонко» намекал, что ему придётся это всё стандартизировать и унифицировать. И что здесь важен не только (и не столько) транспорт, но ещё универсальна сериализация и маршаллинг. В результате получить тотже эрзац-dbus (ну, Varlink/Binder/etc. да куча их, какой больше нравится). По вашей идее, вместо демона шиной используется ФС. Ну ок, какие из этого плюсы (ну кроме повышения уровня абстрагирования и, соответственно, куда больших тормозов, уж и DBus-то тут не подарок, хотя с брокером получше)?

Зачем? У нас же файл-сокет.

Сервер в этот сокет отправил пакет, n-цать клиентов должны его получить. Только они, не вся шина. Действия? Насилуем себя multicast-ом.

Зачем что-то кроме файла для взаимодействия внутри одного компьютера?

Да хоть пайпы, хоть shm. Сериализацию и синхронизацию это как-то отменило? А TCP потому что постоянное соединение. Клиентов всё равно предполагается не сильно много (в подавлящем большинстве один) и траффик там копеечный. Поэтому ТСР, в данном случае, «охлаждает траханье»(с) со стеком и не более.

В случае dbus она просто уже неотъемлемая часть libdbus

Ну так, а я что, возражаю чтоли? Факт, что это буду делать не я.

Без дополнительной информации не вытащить.

Но машиночитаемая информация о типах и порядке их передачи в наличии. Структура из двух uint32_t, между которыми два uint16_t и пять строк.

А почему не https://github.com/json-c/json-c ?

Там cJSON пашет. Велик для того, чтобы структуры протокола одинаково (де-)сериализовались как на клиенте, так и на сервере в нужные структуры.

И вообще, зачем json на отправку пары чисел в запросе и, фактически, списка строк в ответе?

Допустим API немного поменялся. Резко и решительно переписываем всё, что использует наш кастомный бинарный протокол? Да ну, нафиг.

Поверх JSON/DBus или поверх строк или поверх protobuf

Да хоть поверх мейл-слотов. Стандартизировать-то и унифицировать это всё равно надо. Вон в Varlink, вроде как, json и гоняется.

Ещё раз, для протокола, мне как-то всё равно, какой там высокоуровневый IPC (DBus/Varlink/Binder/etc.). Факт в том, что он должен быть. В linux на данный момет единственный - это DBus (Varlink ещё не взлетел и далеко не факт, что взлетит). А комментатор, с которым мы дискутируем, предлагает зачем-то от его отказаться и городить в каждом приложении его куски самостоятельно (даже если все на свете договоряться поддерживать хоть какой-то протокол). Зачем, мне решительно не понятно.

Не к нему, а через него, DBus - это транспорт.

Вы путаете с kdbus. DBus использует любой транспорт, и чаще всего это юникс сокет.

И в отличие от dbus они не требуют никаких демонов

dbus over kdbus тоже не требует демонов.

какой в этом смысл,

элементарно, Ватсон. Индустрия выбрала вулкан и вейланд, а мксы с гл готовится закопать. В отличии от щедро обмазанного баблом г(ов)нома проект типа wlroots не сможет смигрировать за месяц а значит озаботились об этом заранее что ИМХО стратегически правильно. И думаю к версии 0.21 вулкановый рендерер уже не будет уступать gles.

Конечно есть: unix-сокеты, пайпы, shm. И в отличие от dbus

Так дбас поверх сокетов и работает. Сравнил тёплое с мягким.