LINUX.ORG.RU

Solus отказывается от GTK

 , , ,


3

2

Один из лидеров проекта Solus Linux, Джошуа Стробл (Joshua Strobl), объявил о намерении отказаться от GTK при разработке как будущих версий Budgie, так и всей экосистемы приложений в Solus. В своем блоге он высказал ряд упреков в адрес текущего состояния и планов развития GTK, а также философии разработки GNOME.

По его словам, повсеместное насаждение Adwaita как единственно верной темы рабочего стола и попутное удаление части API для разного рода кастомизации добавило головной боли разработчикам, поддерживающим стек GNOME в дистрибутивах или интегрирующим в него свои приложения. Все предлагаемые варианты настройки внешнего вида приложений на базе GTK и сопутствующих библиотек отклоняются, а участники команды GNOME в ответ грубят в тикетах и соцсетях.

Жалуется Джошуа и на то, что выпущенный чуть менее года назад GTK 4 немного усложнил код для работы с виджетами, запретив прямое наследование. Но гораздо более важной проблемой ему видится упразднение API X11, в частности для получения конфигурации подключенных мониторов. Двигаясь в сторону полной поддержки Wayland, GNOME удалил функции опроса X-сервера, поручая разработчику писать собственные интерфейсы для обращения напрямую к X11 (либо к API других ОС, если приложение оказалось кроссплатформенным).

В то время как рабочая функциональность удаляется, многие известные ошибки в GNOME не исправляются месяцами и годами (в частности, автор приводит в пример ошибки с прокруткой в GtkListView и с переключением на другое окно при открытом выпающем списке в GtkPopover). При этом Джошуа описывает это в разрезе собственного опыта написания с использованием GTK своего аудиоплеера Koto.

Релиз GTK 4 не оправдал ожидания авторов Solus, надеявшихся на ряд обещаемых изменений в libhandy, которые в итоге так и не были добавлены. А дорожная карта к GTK 5 предрекает ещё большее закручивание гаек в части кастомизации и общий регресс как в UX, так и для использования библиотки в сторонних приложениях. Джошуа прямым текстом утверждает, что использование в разработке GTK 4 и выше — это выстрел себе в ногу.

По итогам этих размышлений лидеры проекта Solus приняли решение отказаться от использования GTK в Budgie и в целом минимизировать присутствие GNOME в своем пользовательском окружении, перейдя к выбору одного из следующих GUI-тулкитов:

  • EFL (библиотека в основе Enlightment Desktop);

  • Qt;

  • iced (кроссплатформенная GUI-библиотека для Rust).

В случае Qt разработчикам Solus не хочется писать код на C++, и к тому же смущает «коммерческая лицензия» Qt и неприятный осадок. iced находится в ранней стадии разработки и многие полезные вещи придется писать с нуля, а ресурсов для этого нет.

Остаётся EFL, который в итоге и был выбран. Постепенно планируется написать на EFL свои виджеты, а затем и основные десктопные приложения, либо адаптировать существующие, по возможности не связанные с GNOME.

Что касается дистрибутива, то версия с GNOME будет собираться в отдельный образ, и ей будет уделен минимум внимания, будет обеспечена лишь базовая работоспособность. В Budgie 11 не будет никаких зависимостей от GTK.

>>> Подробности

★★★★★

Проверено: hobbit ()
Последнее исправление: sudopacman (всего исправлений: 9)
Ответ на: комментарий от khrundel

Что ещё должно предоставить?

Список можно перечислять долго, но не нужно - упоротым гномосекам с их уникальным видением это все равно что горох об стену

Собственно никто не заставляет эти приложения использовать Wayland. Есть же X11 и реализующий его XWayland. Ну а если приложение всё-таки решило мигрировать на Wayland - пусть реализует его корректно.

Для, например, kde и других ос - использование server side decorations полностью корректно и активно используется, игнорируя личные проблемы гномосеков

Ford_Focus ★★★★★
()
Ответ на: комментарий от bhfq

оно заюзало 100мб EFI раздел венды ну и out of space.

Обращайтесь к разработчикам Solus. systemd-boot можно использовать вместе с виндой, но это требует чуть больше работы, чем простое bootctl install. При этом systemd-boot очень маленький, простой и удобный.

Siborgium ★★★★★
()
Ответ на: комментарий от mertvoprog

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

Что там гном целится покорять - проблемы его разработчиков. Если потащат «на мобилки» инструментарий, предназначенный для нормальных больших мониторов - сами себе злые дендроантропоиды. А на кой чорт «сплющивать окно по горизонтали» (в заголовок?) - не знаю. Чтоб место не занимало, когда не нужно - окно скрывают. В DE, авторы которых не страдают гномьим религиозом с боязнью вендоподобия, есть таскбар или что-то аналогичное, позволяющее развернуть скрытое окно обратно.

redeyedanonymous
()
Ответ на: комментарий от redeyedanonymous

Вот, кстати, да, а зачем и кто в реальной жизни сворачивает окна в заголовок? Я всегда думал, что это пережиток древнего прошлого, но даже тогда, в те древние времена не понимал, зачем?

R_He_Po6oT ★★★★★
()
Ответ на: комментарий от AP

Вообще они изрядно подзадрались таскать с собой километровые патчсеты.

Могу себе представить. Вообще разрабы Qt очень медлительные на приём патчей. Обсуждение какой-нибудь 5-ти строчной заплатки может месяцами висеть, а то и дольше.

Sunderland93 ★★★★★
()
Ответ на: комментарий от mertvoprog

Кукаретики, которые топят за xdg-decoration, уже сделали патч для его поддержки в Mutter?

Гномеры ясно дали понять, что принимать такое не будут.

Или хотя бы для Muffin

Он не поддерживает Wayland, хотя в Cinnamon везде стараются отрисовать обычную рамку окна, даже окнам с CSD. Так что думаю здесь такой проблемы не будет.

Sunderland93 ★★★★★
()
Ответ на: комментарий от EXL

https://baat.z-lab.me/~exl_lab/screens/GNOME3_wayland_mpv_fuckup.png

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

При этом в KDE – всё нормально, потому что там я способен закрыть окно не «выкусывая блох» курсором мыши.

Ну да, если не использовать фичу то баг в ней не мешает. Логично чё.

Претензии тут не только эстетические (в GNOME 3 такие заголовки выглядят как говно), а ещё и практические и связанные с функциональностью программы: в кнопки нормально невозможно попасть,

Пардон, в какие кнопки? В кнопку play/pause? В кнопку переключения аудиодорожки? В кнопку субтитров? Ну, наверное, тогда MPV не для тебя. Используй другие плееры. Вон, гномеры форкнули его в целлюлоид, добавили гткшные кнопки и гткшные же декорации.

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

khrundel ★★★★
()
Ответ на: комментарий от EXL

И да, наш оппонент @khrundel почему-то забывает, что декорации окна это не только вот эта TitleBar-нашлёпка сверху к которой он так сильно прицепился и строчит какие-то адские простыни, но ещё и методы ресайза и перемещения оконных контекстов. И если SSD обеспечивает единую UX-модель для этой функциональности, то в случае с CSD каждое приложение обязано имплементировать это поведение самостоятельно.

Сразу видно что ты не интересовался темой. Вся эта модель состоит в том, что в некоторых местах в ответ на mousdown клиент посылает композитору сообщение «меня двигают» или «мне ресайзят правый край» или т.п. Композитор в ответ начинает отслеживать мышь и сам уже двигает окно (вейланд не позволяет это делать самому приложению), и реализует перенос между мониторами или всякую пургу типа snap to left. Ну и в ответ на клик в другом месте может послать «меня минимизируют». Вейланд не дураки проектировали, сделали максимально просто.

khrundel ★★★★
()
Ответ на: комментарий от mertvoprog

А, шо? SSD позволяют засовывать любой набор кнопок. Помнится, например, к FVWM приделывали кнопки, которые замораживают/размораживают окно, посылая SIGSTOP/SIGCONT. Можно сделать заголовок сбоку или поверх окна. Можно вообще не рисовать декорации, если они не нужны. Можно сделать заголовки не на полную ширину, как в гайке, и стыковать их так же в табы.

SIGSTOP/SIGCONT принимается. Неадекватный правда, но это моя оценка, можешь списать на вкусовщину. В принципе в гноме есть овервью, в КДЕ есть таскбар, так что можно обойтись и без этого. Я бы предпочёл чтоб правый клик по заголовку также переадресовывался серверу с командой «покажи оконное контекстное меню» и туда уже композитор мог бы запихать туда всякое, типа always on top или show on all desktops, вот эти сигстопы/сигконты. В любом случае эта фича не стоит просирания полоски экрана.

Заголовки сбоку и поверх - идиотизм клинический, такое не надо.

Сокрытие декораций - ни в коем случае нельзя. Приложение считает что заголовок видно, соответственно может выводить туда важную информацию. Например MDI приложение для почты может выводить в заголовок «у вас N новых писем» пока пользователь пишет ответ.

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

khrundel ★★★★
()
Ответ на: комментарий от khrundel

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

Т.е. клиент завис - композитор ничего не получает и окно приколочено гвоздями? Гениально.

redeyedanonymous
()
Ответ на: комментарий от Ford_Focus

Для, например, kde и других ос - использование server side decorations полностью корректно и активно используется, игнорируя личные проблемы гномосеков

Другие OS в своих оконных библиотеках имеют и готовые кнопки, и прочие классные контролы. Должен ли Вейланд предоставлять и их тоже? А если нет, то как ты разграничиваешь что должен, а что можно отдать тулкиту? Ещё раз повторяю, для полных дебилов: декорации по сложности обработки примерно соответствуют 11 кнопкам, часть из которых обрабатывает mousedown, а 3 - клики. Комбобокс реализуется гораздо сложнее. Соответственно нужно как-то аргументировать, почему приложение должно реализовывать комбобоксы само, а заголовок и рамки для него должен рисовать кто-то другой.

khrundel ★★★★
()
Ответ на: комментарий от redeyedanonymous

Т.е. клиент завис - композитор ничего не получает и окно приколочено гвоздями? Гениально.

Да. А ты не знал? Этот момент, что характерно, указали вот в той самой первой статье про CSD от гномеров и сказали что с этим можно жить, в конце концов зачем двигать зависшую прогу, один хрен работать с ней нельзя. Не лучше ли вывести предложение прибить её? Если пользователь хочет дать ей шанс, он просто переключится на другое окно и даст первому время подумать.

Удивительно, что все кто тут за SSD топят вообще походу ничего по теме не знают.

khrundel ★★★★
()
Ответ на: комментарий от khrundel

Между заголовком окна и кнопками внутри окна есть принципиальная разница: рамка окна используется для многозадачности и управлением окна, а кнопки внутри окна – нет. Рамка должна быть всегда доступна и надёжно работать. А что там внутри рамки – дизайнерам программы виднее, на работу системы в целом это не влияет.

X512 ★★★★★
()
Ответ на: комментарий от khrundel

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

за контролы в других ОС отвечает вм? к чему тогда этот глупый вопрос?

Ford_Focus ★★★★★
()
Ответ на: комментарий от khrundel

Удивительно, что все кто тут за SSD топят вообще походу ничего по теме не знают.

Ну так кедерасты и гномосеки — этож суть сектанты и фанатики, им не важны такие мелочи, им главное как это сделано в их фетише.

anonymous
()
Ответ на: комментарий от khrundel

Я так не понял, что тебе не нравится.

Кривое CSD в этом окне.

Пардон, в какие кнопки?

Кнопки заголовка окна: свернуть/развернуть/закрыть.

что в некоторых местах

Ты до сих пор не можешь понять, что эти «некоторые места» в случае с CSD каждый разработчик тулкита определит на свой лад? Более того, гноморазрабы не осилили адекватно сделать эти «некоторые места» в QGnomePlatform, из-за чего границы ресайза под XCB и Wayland различаются. Различаются они и в сравнении GTK+-приложения vs. Qt-приложения на Wayland, чего на XCB/X11-backend’ах обоих тулкитов нисколько не наблюдается.

EXL ★★★★★
()
Последнее исправление: EXL (всего исправлений: 2)
Ответ на: комментарий от Mischutka

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

wrkngu0
()
Ответ на: комментарий от X512

В Windows – да. Там можно даже кнопку из другого процесса вставить.

Внезапно, есть протокол XEmbed (который гномеры, в смычке с бандой Вяленого, успели объявить deprecated), через который работают виджеты GtkSocket/GtkPlug (которые тоже уже deprecated) и трей в не-гномовских DE. GtkSocket/GtkPlug как раз позволяют вставить виджет от одного процесса в окно другого процесса. Это вовсю используется в XFCE, где все элементы панелей - плагины, работающие в отдельных процессах, т.е. падение, к примеру, таскбара или ещё чего не уронит остальное DE (а не как в гноме). Как команда XFCE будет изворачиваться в процессе перехода на вяленого с иксов (а им придётся) - мне очень интересно.

redeyedanonymous
()
Ответ на: комментарий от khrundel

декорации по сложности обработки примерно соответствуют 11 кнопкам, часть из которых обрабатывает mousedown, а 3 - клики

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

Декорации правильно написать и всё это учесть не так-то просто, поэтому это должно быть в тулкитах (которые интегрируются в конкретную среду соответствующими плагинами/темами), а остальные должны использовать библиотеку типа libdecor — когда её допилят. Это покроет 99,999% приложений, а остальные типа Google Chrome — раз уж взялись за реализацию всего самостоятельно, то долбитесь сами.

Rootlexx ★★★★★
()
Ответ на: комментарий от redeyedanonymous

есть протокол XEmbed (который гномеры, в смычке с бандой Вяленого, успели объявить deprecated), через который работают виджеты GtkSocket/GtkPlug (которые тоже уже deprecated) и трей в не-гномовских DE

KDE — это «гномовское DE»? Ибо давным давно XEmbed deprecated и там, а используют приложения давно уже AppIndicator/StatusNotifierItem, причём последний разработали угадайте кто.

Rootlexx ★★★★★
()
Ответ на: комментарий от annulen

Поддержка есть, но это не делает данный механизм менее устаревшим. В одно время его из KDE даже выпилили, но затем вернули через прокси в SNI.

Rootlexx ★★★★★
()
Ответ на: комментарий от X512

Между заголовком окна и кнопками внутри окна есть принципиальная разница: рамка окна используется для многозадачности и управлением окна, а кнопки внутри окна – нет.

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

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

khrundel ★★★★
()
Ответ на: комментарий от Ford_Focus

за контролы в других ОС отвечает вм? к чему тогда этот глупый вопрос?

Какой ВМ? В Вейланде нет WM. Это в X11 был, решили что нахрен не нужен.

Вот взять другую OS,называется Windows, там можно попросить систему нарисовать окно с заголовком, всё как ты любишь. Для этого нужно вызвать функцию из user32.dll. А ещё там можно создать кнопку. Для этого нужно вызвать функцию откуда? Правильно, из того же user32.dll. Более того, вызвать нужно ту же самую функцию, только с немного другими параметрами.

Вот такие пироги. Рамка окна живёт вместе с кнопками. В случае Вейланда - в GUI-тулките. В случае винды - в модуле User. Белой вороной являлся скорее X11.

khrundel ★★★★
()
Ответ на: комментарий от khrundel

Фактически есть только 2 функции у декораций, которые композитор мог бы обработать на зависшем окне: перетаскивание и минимизация

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

Rootlexx ★★★★★
()
Ответ на: комментарий от wrkngu0

Думаю многие поступают аналогично.

Ясно. Вопросов больше не имею.

Mischutka ★★★★★
()
Ответ на: комментарий от redeyedanonymous

Как команда XFCE будет изворачиваться в процессе перехода на вяленого с иксов (а им придётся) - мне очень интересно.

Также как команда MATE - запускать их в одном процессе

Sunderland93 ★★★★★
()
Ответ на: комментарий от sudopacman

топят за libdecor

Так оно реально существует? любопытненько.

mertvoprog
()
Ответ на: комментарий от redeyedanonymous

Если потащат «на мобилки» инструментарий, предназначенный для нормальных больших мониторов

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

Чтоб место не занимало, когда не нужно - окно скрывают

А если нужно, но места мало?

mertvoprog
()
Ответ на: комментарий от AP

Когда это повторяется постоянно в ответ на примерно одни и те же претензии («пожалуйста, сделайте так, чтобы постоянно скрытая и доступная только при нажатии кнопки обзора панель с иконками запущенных приложений вела себя так опционально, а не безальтернативно - ведь так сделали разработчики Dash to Dock и не сказать, чтобы это было как-то чрезмерно трудоемко - или хотя бы не саботируйте работу сторонних расширений, чтобы мы могли кастомизировать Gnome и делать его удобнее для нас») - это уже не особенно тонкое хамство, подпитываемое религиозным фанатизмом. Как-то приходилось слышать от гноморазрабов и такой перл: «мы не хотим поддерживать работу расширений, потому что они могут содержать ошибки, а все претензии по этому поводу будут направлять нам».

IRASoldier ★★
()
Ответ на: комментарий от hateyoufeel

Тогда нафига они пишут об этом, как о каком-то страшном достижении, требующем от них превозмогания? Поменять цвета в css - прямо ужас какие человеко-часы…

Не, они реально там с ума посходили.

IRASoldier ★★
()
Ответ на: комментарий от R_He_Po6oT

Таскбаров в нынешнем понимании в те времена не было, от силы иконификация. Так что это более наглядная, но менее компактная, замена иконификации.

Можно также представить тайлинг по вертикали, работающий по типу виджета «аккордеон»: когда весь экран забит окнами, одни развёрнуты, а другие свёрнуты в заголовок. На мониторах 4:3 имело смысл. Сейчас можно сделать то самое по горизонтали, разместив заголовки сбоку.

Позже эта концепция трансформировалась в плавающие мини-виджеты управления программой, в которые сворачивается полное окно программы — как в Download Master или AIMP. В более изкажённом виде оно присутствует в Android, в виде уведомлений с элементами управления в шторке, и ровно в таком же виде из Android это слизали в gnome-shell, расширив уведомления freedesktop. Но к заголовкам окна это всё уже отношения не имеет, а зря. Ведь из возможности напихать произвольные виджеты в заголовок окна вполне напрашивается возможность засунуть туда всё самое необходимое, а остальную часть окна сворачивать.

mertvoprog
()
Ответ на: комментарий от Sunderland93

Гномеры ясно дали понять, что принимать такое не будут.

Насколько Мы помним обсуждение в соответствующем тикете, то там такого нет. Или есть?

Он не поддерживает Wayland

Как всё запущено-то. Неужто пора ещё один форк гомощели делать?

mertvoprog
()
Ответ на: комментарий от khrundel

В любом случае эта фича не стоит просирания полоски экрана

Зато принудительные хедербары стоят, да.

В принципе в гноме есть овервью, в КДЕ есть таскбар, так что можно обойтись и без этого

_NET_WM_STATE_SKIP_TASKBAR тоже не нужен, ясно.

Заголовки сбоку и поверх - идиотизм клинический, такое не надо

Потому что исторически сложилось™, что заголовки должны быть вверху и должны быть в принципе — значит, других вариантов не надо?

Сокрытие декораций - ни в коем случае нельзя

Тогда будет некрасиво. Идут нафиг сплешскрины, идут нафиг красивые плавающие окна типа тех же вышеупомянутых мини-виджетов, идут нафиг всякие xeyes, QtPonies, и т.п.

Например MDI приложение для почты может выводить в заголовок «у вас N новых писем»

Потому что больше ему выводить некуда?

Почему в макоси, например, сто лет как сделали для этого счётчик на иконке в доке, а линуксоиды до сих пор жрут костыли из 90-х?

А оставшаяся реализовывается и без SSD.

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

mertvoprog
()
Ответ на: комментарий от khrundel

Затем, что зависшая != зависшая навсегда.

Может, программа просто думает.

И с какого перепугу она всё это время должна мешаться?

mertvoprog
()
Ответ на: комментарий от EXL

Кривое CSD в этом окне.

Это лишенная смысла фраза. Примерно как «всё плохо».

Кнопки заголовка окна: свернуть/развернуть/закрыть.

Ты надеешься что я забуду свой вопрос? Так я не гордый, я повторю. Насколько удобно нажимать на кнопку «play/pause»? Или ты используешь mpv только в режиме «запустил - закрыл»?

Ты до сих пор не можешь понять, что эти «некоторые места» в случае с CSD каждый разработчик тулкита определит на свой лад?

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

khrundel ★★★★
()
Ответ на: комментарий от Rootlexx

давно уже AppIndicator/StatusNotifierItem

Это только замена трея. И та убогая — всё квадратное, декларативное и прибито гвоздями.

У XEMBED есть другие применения. Про крысиную панель выше уже писали. Также есть, например, плагин для Double Commander, который через XEMBED встраивает в панель предпросмотра любые внешние приложения.

mertvoprog
()
Ответ на: комментарий от khrundel

некому будет перерисовать его в новом размере

Позвольте-с — по-Вашему, когда приложения не зависшие, они всегда мгновенно перерисовываются при подобных атомарных изменених?

Композитор просто масштабирует последний буфер под новый размер до того момента, пока приложение не отрисует новый. То же самое происходит на мобилках при переходе между книжной и альбомной ориентацией, например.

mertvoprog
()
Последнее исправление: mertvoprog (всего исправлений: 1)
Ответ на: комментарий от khrundel

Белой вороной являлся скорее X11

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

mertvoprog
()
Ответ на: комментарий от IRASoldier

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

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

mertvoprog
()
Ответ на: комментарий от EXL

Самые обычные комбобоксы. Давай ты для разнообразия попробуешь думать разумно.

Какие программы используют SDL? Игры. Какие игры нуждаются в оконных декорациях? Может 3д шутеры? Нет, они неиграбельны в оконном режиме. RTS? Нет, кликнешь чуток мимо окна, потеряешь время и проиграешь. Оконный режим в принципе интересен в 3х жанрах: пошаговая тактика, типа Цивилизация, Xcom или Герои, квесты или хентайные визуальные новеллы. Что общего есть у этих жанров? У них есть GUI. Кнопки, текстовые поля, и иногда реально комбобоксы. Следовательно, игры, которые работают в оконном режиме и которым требуются оконные декорации, имеют нормальный гуй. А там где ты выбираешь шпёхать Сузуку или Мазуку, ты жмакаешь кнопки, следовательно у разработчика есть всё необходимое для реализации нормального CSD.

khrundel ★★★★
()
Ответ на: комментарий от mertvoprog

Вот и на лине выросло поколение которому чтоб закрыть окно или приложение нужны декорации :(

anonymous
()
Ответ на: комментарий от Rootlexx

Это не так. Нужно ещё отрисовать тень

Я понимаю эстетическое желание сделать красиво, но тень совсем не подпадает под обязательное. Если бомж-программа типа MPV, ввиду отсутствия тулкита, будет рисовать окно без тени, то и дай бог здоровья авторам, я ни слова ни скажу против них. С тенью красивее, но и без неё тоже можно.

khrundel ★★★★
()
Ответ на: комментарий от khrundel

Рамка не должна быть всегда доступна, толку от этого никакого.

Для фанатов тайлинга может быть никакого, но для меня это основной инструмент управления окнами.

Невозможно отресайзить зависшее окно

В Haiku можно.

некому будет перерисовать его в новом размере

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

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

Это очень важные функции чтобы окно не мешало пока ждёшь чтобы оно развисло.

Ты уверен что ради этих двух функций стоит пилить SSD?

Да, уверен.

X512 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.