Тор не поддерживает системы без wayland

Под виндой у приложений что на Qt, что на GTK, что просто на WinAPI элементы оформления будут единообразно выглядеть (если они не используют специально что-то нестандартное).

А по твоей логике можно и Cairo универсальным тулкитом считать.

Поэтому и не делают. Но техническая возможность есть. Если тебе надо, то можешь посодействовать.

Бред. «Идите встраивать в тулкиты. Техническая возможность есть. Можете посодействовать.»

В какие тулкиты-то? Во все сразу?

Приходит бабка к адвокату и говорит:
— Имею ли я право?
— Имеешь, бабушка.
— Нет, я хочу спросить, имею ли я право…
— Да, имеешь!
— А могу я или нет?
— Нет, бабка, не можешь.

4.2.

В какие тулкиты-то? Во все сразу?

Какие используешь, в те и встраивай. Остальное будет картинку гонять. Подозреваю, что и под виндой условный браузер и приложения на Eleсtron тоже будут слать в основном готовую картинку.

Можешь попробовать заставить всех использовать один тулкит, но у тебя не получится.

4.2.

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

А в винде, по-твоему, как реализовано? Просто гораздо больше приложений используют официальный тулкит.

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

а если он все использует??! у него может быть и gtk2 и gtk3 и gtk4 и qt. допустим, надо подключиться к чужому рабочему софту. что запускает какой-то другой юзер я должен предвидеть заранее что ли?

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

А по твоей логике можно и Cairo универсальным тулкитом считать.

А где я предлагал считать cairo тулкитом?

Если ты API рисования не отличаешь от тулкита, это твои проблемы.

Очередное подтверждение, что среди защитников вяленого есть только те, кто не могут в архитектуру.

Под виндой у приложений что на Qt, что на GTK, что просто на WinAPI элементы оформления будут единообразно выглядеть (если они не используют специально что-то нестандартное).

Бгг. Теперь перескочил на внешний вид.

я не знаю, как это реализовано в винде, но вижу, что ты пишешь явный бред: мы все переделали, чтобы гонять картинку, а теперь вы как хотите, так и решайте проблему

Чтобы реализовать как в винде, нужно всех заставить один тулкит использовать, и его команды слать по сети. Wayland этому никак не мешает.

Управление сессиями и отправку всего вместе по сети нужно реализовывать на стороне композитора. Но вообще, не только композитора, а скорее DE/ОС. И этому Wayland тоже никак не мешает.

Я тебе про то, что Xt выкинули, а без него все по-разному у себя рисуют и команды иксам отправляют более низкоуровневые. А ты в ответ опять свои «наполеоновские» бредни.

Я тебе про то, что Xt выкинули, а без него все по-разному у себя рисуют и команды иксам отправляют более низкоуровневые.

Что ты несёшь, чел, реально.

К тебе тот же вопрос.

Чтобы реализовать как в винде, нужно всех заставить один тулкит использовать, и его команды слать по сети. Wayland этому никак не мешает.

Как можно слать КОМАНДЫ тулкита, если у тулкитов не бывает никаких команд?

КОМАНДЫ могут быть у API рисования, например. У Xrender, cairo, OGL…

Оригинальные иксы вообще за 3 года с нуля разработали. Это на 10 лет быстрее, чем вэйланд пытается создать его упрощённую замену.

Тулкит может использовать разные API рисования. Слать в идеале нужно то, что он преобразует в команды этих API. Чем более высокоуровневое, тем лучше. Но можно и команды API типа OGL слать. Только не факт, что получится эффективно.

переписывание чего-то с нуля — это абсолютно всегда неверное решение?

Только Ситхи всё возводят в абсолют! Но, вообще, да, часто именно так. Стремление переписать с нуля происходит от неспособности понять оригинальный код в силу низкого профессионализма. Что, понятное дело, не способствует высокому качеству получившегося продукта.

Уже давно есть унифицированный API для захвата экрана, который и в Wayland, и в X11 работает. Проблемы у пользователей Zoom исключительно по вине разработчиков Zoom.

Афигительно информативно. Разработчики Zoom (или любого другого продукта) пришли в тему, посмотрели на твоё сообщение, и сразу всё поняли.

То есть про org.gnome.Shell.Screenshot нагуглить смогли, а про xdg-desktop-portal не смогут?

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

Нет результатов на первой странице гугла?

Есть.

Есть.

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

Серьёзно? Remote desktop and screen casting in Wayland.

Серьёзно. Я специально пробовал гуглить. Для Windows, правда, первым результатом вылезло сообщение в их блоге, но оттуда уже можно плясать. Вторым результатом были ссылки на документацию. Для Mac OS просто первым результатом была документация. Для Linux первым результатом был вопрос на StackOverflow от 2012 года, где самым быстрым способом снимать данные с экрана был признан композитор на VirtualGL. Ну а следующими результатами были сравнения программ для захвата видео с экрана, типа OBS. Доков нет.

По твоей ссылке не написано, что это универсальный API. Более того, там даже явно указано, что это для Wayland. Если в Zoom уже используют какое-то специфичное для Gnome API, какой смысл им переходить на другое специфичное для Gnome API? Если бегло взглянуть, это API даже ещё более специфичное, чем предыдущее, потому что только для Wayland.

Результаты по запросу «linux screencast api» не лучше, чем по запросу «wayland screencast api».

не написано, что это универсальный API. Если в Zoom уже используют какое-то специфичное для Gnome API, какой смысл им переходить на другое специфичное для Gnome API?

Про то, что это DE-специфичный API, тоже не написано. А название xdg-desktop-portal и документация к нему (на которую дана ссылка) как бы намекают на обратное.

И про xdg-desktop-portal по обоим запросам информации уж точно больше, чем про org.gnome.Shell.Screenshot. Почему-то только разработчики Zoom додумались его использовать для записи видео.

В Electron вообще desktopCapturer, который уже сам какой надо API использует.

Результаты по запросу «linux screencast api» не лучше, чем по запросу «wayland screencast api».

Неужели ты сам не видишь, что это просто отмазка, причём очень слабая? Как и всё дальше в сообщении.

теперь вейланд по дефолту должен быть

«Должна быть поддержка вейланда в библиотеках» и «должен юзаться вейланд вместо иксов» - это разные вещи.

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

Личный пример. Я делал себе демон а-ля RedShift для Wayland (собственно, это был один из принципиальных моментов перехода на Wayland по-дефолту для меня). Мне удалось из этого нагуглить zwlr-gamma-control-unstable-v1, который хотя-бы описан и можно подглядеть, как заюзали в gammastep (несколько странновато, но поправимо). С другой стороны, zwrl и unstable как-бы намекают, что работает это, если повезёт, только в wlroots, который я не использую. Т.к. я хочу поюзать GNOME и API для этого у него нет, но есть настройки «Night Light» и дополнение NightLightSlider, которое как-то работает.

По итогу, не найдя ничего внятного и расковыривая nl-settings (GNOME благо открыт), понятно, что порулить нам не дадут и гамму обновляет композитор по собственной логике, а «настройки» просто дергают композитор по DBus и сохраняются через GSettings. А, расковыривая расширение, мы понимаем, что автор просто захачил это растянув диапазон на 6 часов в обе стороны (чтобы композитор не вмешивался) и обновляя настройки периода и температуры раз в минуту. Я думаю, что там есть ещё как-минимум пара ходов, но это тоже грязные хаки.

Итог спича, а нафига авторам коммерческого софта вот эти все лишние телодвижения? Не нашли в первых страницах гугла доку - до свидания. Максимум, дадут SDK или справку по API, авось кому надо, что-нибудь и напилит.

Ну вот, шлангование пошло. Изначальный аргумент был как раз про то, что использование org.gnome.Shell.Screenshot вместо xdg-desktop-portal в Zoom — это якобы проблема Wayland, а не Zoom.

Допустим, проблема с документацией у GNU/Linux/XDG. Где тут вина Wayland?

Ну вот, шлангование пошло.

Допустим, проблема с документацией у GNU/Linux/XDG. Где тут вина Wayland?

лол

А по сути можешь что-то сказать?

По сути я всё сказал саркастическим комментарием вот здесь: Тор не поддерживает системы без wayland (комментарий)

На случай, если у кого-то есть сложности с пониманием сарказма, переведу на язык попроще: «всё скрытно и запутанно. Видимая часть современного «линукс-сообщества» состоит из зазнаек, которых нужно упрашивать наводящими вопросами.»

1. Почему я вообще должен был в изначальном комментарии расписывать про xdg-desktop-portal, если он не был адресован разработчикам Zoom?

2. Ну вот есть проблема с документацией у XDG/GNU/Linux. Но она же не специфична для Wayland или для графической подсистемы. Если ты онтопиком давно пользуешься, то должен это понимать.

3. Документация по xdg-desktop-portal — третья ссылка в «гугле». Плюс он так или иначе упоминается в большей части ссылок на первой странице по запросам «linux screencast api» и «wayland screencast api». А вот про org.gnome.Shell.Screenshot там точно нет, тем более в контексте записи видео. Использовать этот API, да ещё и не по назначению, додумались только в Zoom.

Почему я вообще должен был

Ты никому ничего не должен. Но ты — отличный пример современного линукс-сообщества. Люди из-за этого боятся ходить в линукс.

Ну вот есть проблема с документацией у XDG/GNU/Linux. Но она же не специфична для Wayland или для графической подсистемы. Если ты онтопиком давно пользуешься, то должен это понимать.

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

Документация по xdg-desktop-portal — третья ссылка в «гугле»

Я искал по «linux capture screen video api» и на первой странице ничего не нашёл. Если заменить Linux на Windows, то первый результат даст ссылку на новое API для захвата экрана. Дальше там можно уже докопаться до старых API. Если заменить на mac os, то просто первая ссылка — на документацию API по захвату экрана.

по запросам «linux screencast api» и «wayland screencast api»

Классический пример «знаю, что искать». Кстати, попробуй поискать с чистым профилем. Нужная ссылка уже будет ближе к концу страницы. Хорошо, что вообще есть.

Само использование слова screencast в API — ошибка. Screencasting это комбинация захвата экрана (capture, record) и трансляции (broadcast). Ты когда хочешь звук записать, делаешь audiocasting? Или всё-таки audio capture/recording? Тогда почему для захвата видео нужно делать сразу трансляцию?

Использовать этот API, да ещё и не по назначению, додумались только в Zoom.

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

Ну серьёзно, что нашли, то и заюзали. Ты же не думаешь, что там какие-то инопланетяне сидят. Простые люди. Гуглят, вставляют первое заработавшее решение.

Ты никому ничего не должен. Но ты — отличный пример современного линукс-сообщества. Люди из-за этого боятся ходить в линукс.

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

Так у нас никто и не спрашивал ссылок на документацию, и дискуссия не с разработчиками была. Если разработчики придут и спросят — так мы им ответим.

Классический пример «знаю, что искать».

Что первое в голову пришло, то и искал.

Кстати, попробуй поискать с чистым профилем. Нужная ссылка уже будет ближе к концу страницы. Хорошо, что вообще есть.

Не использую поисковики, которые составляли бы на меня «профиль». Выхлоп «гугла» смотрел через Searx.

Смотрите, как он набивает себе очки высмеивая разработчиков ПО.

Ты ещё веб-макак предложи прекратить высмеивать.

Разработчиков я гнать не собираюсь и даже готов им помочь. Но ведь использовать org.gnome.Shell.Screenshot для записи видео — это уже слишком. Если уж хоят GNOME-специфичные API, то пускай хотя бы org.gnome.Shell.Screencast используют.