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)
Ответ на: комментарий от Ford_Focus

Если множество приложений, используемых людьми, нуждаются в server-side decorations, DE должно его предоставить.

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

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

Да что ты? А ты в курсе где хостится репозиторий wayland-protocols?

И? Принятие в репу приравнивается к голосованию? Да ты вообще упоротый

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

И? Принятие в репу приравнивается к голосованию?

К какому голосованию? Wayland - официальный проект Freedesktop, wayland-protocols тоже. Если протокол принят в состав официального набора - то он тоже часть всего этого

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

если приложение всё-таки решило мигрировать на Wayland - пусть реализует его корректно.

А теперь найди мне здесь строки, в которых говорится что приложение должно иметь CSD заголовок. Я жду https://gitlab.freedesktop.org/wayland/wayland/-/blob/main/protocol/wayland.xml

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

Во первых речь не о GTK, во-вторых - приняли патч с реализацией старого KDEшного протокола. xdg-decorations они не реализовывали.

Тем более. Даже внутренний протокол конкурента приняли, вот так они мешают принятию SSD, ироды.

Вот это тебя плющит :) в общем ты лицо политической позиции Гнома. Если вредно для них - вредно для всех. Яснопонятно.

Почему CSD лучше объяснено уже 100500 раз. Всё, говорить больше нп о чем. Кто хотел понять - понял. Сейчас вопрос стоит так: должны ли гномовцы реализовывать хотелки людей, которые мнению гномовцев противоречат. Твоя позиция: должны. Потому что амператор Sunderland93 так хочет.

Я выше давал скриншот с демкой libdecor.

А я тебе ответил, что есть только один человек, который требует повсеместного внедрения libdecor: @EXL. Больше этот либдекор никому нахрен не сдался. Сделали как последний фоллбэк для бомжей.

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

Сначала Rootlexx, теперь ты перенял у него эстафету и по второму кругу (вернее, уже кругу по десятому) втираешь одну и ту же дичь.

@Sunderland93, @EXL, можете просто скопипастить ему мои комментарии.

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

А теперь найди мне здесь строки, в которых говорится что приложение должно иметь CSD заголовок. Я жду

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

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

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

Почему CSD лучше объяснено уже 100500 раз

Почему SSD лучше CSD не меньшее количество раз было объяснено, но ты слушать не хочешь. Зато как истинный пропагандист везде суёшь свой CSD, даже не понимая что люди, которые с тобой спорят, не против него. Им он нравится даже. А говорят тебе совершенно о другом. Но чё поделать, фанатики есть фанатики.

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

Сначала Rootlexx, теперь ты перенял у него эстафету и по второму кругу (вернее, уже кругу по десятому) втираешь одну и ту же дичь.

@Sunderland93, @EXL, можете просто скопипастить ему мои комментарии.

Забавно то, что ты считаешь что что-то вменяемое возразил и нашёл ещё себе шестёрок, которые будут твою мудрость ретранслировать. К сожалению должен огорчить. Ты - самый слабый из аполлогетов SSD. Это ты должен их аргументы копировать.

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

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

Ты вообще сам-то осознаёшь какой бред пишешь?

А ты? Ты утверждаешь, как и неадекват Classen, что если приложение работает под Wayland, или собирается на него портануться - оно должно реализовать CSD заголовок. Я тебе задал вопрос - где в корневом протоколе это написано, и написано что SSD ему просить нельзя. Ты не ответил. Дальнейшую дискуссию об этом продолжать не вижу смысла.

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

Почему SSD лучше CSD не меньшее количество раз было объяснено,

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

Вот, сижу жду как ты объяснишь, почему это различие тебя не беспокоит.

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

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

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

Отвечу в последний раз: я не против CSD, и я не топлю за то чтобы его выкинули на мороз. Я топлю за то, что если в Гноме запущено стороннее приложение, написанное например без использования Qt или на чём-то своем, или вовсе игра - оно могло получить обычную классическую рамку окна, а не быть лысым. И всё. Ты же какую-то ахинею несешь уже какую страницу обсуждения, и в упор не видишь что тебе пишут.

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

А ты? Ты утверждаешь, как и неадекват Classen, что если приложение работает под Wayland, или собирается на него портануться - оно должно реализовать CSD заголовок.

Да.

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

Нигде. Но нигде и не написано, что SSD ему должны предоставить. Более того, в описании XDG-Decoration написано, что даже поддерживающий это расширение сервер имеет право проигнорировать запрос: «The compositor can decide not to use the client’s mode and enforce a different mode instead.» Самая мякотка: «After requesting a decoration mode, the compositor will respond by emitting an xdg_surface.configure event. The client should then update its content, drawing it without decorations if the received mode is server-side decorations.»

drawing it without decorations IF the received mode is server-side decorations.

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

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

Отвечу в последний раз: я не против CSD

Мне, извини, плевать против ты или не против CSD, я задал тебе конкретный вопрос: ты не можешь не видеть, что шрифт и цвет текста в заголовке SSD окна не соответствует содержимому. Соответственно как получается, что это несоответствие тебя не беспокоит, а несоответствие заголовков разных окон для тебя нестерпимо. Я бы хотел услышать ответ именно на этот вопрос, а не очередную попытку переформулировать «а ну, суки, делайте как я сказал» менее наглую форму.

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

что без соответствующего сообщения клиент должен рисовать сам.

Не должен, а может. А может и не будет. Потому что это всё переключаемо. Вот я к примеру самолично добавил поддержку xdg-decoration в RetroArch. Это такой мультисистемный игровой эмулятор. И во всех нормальных композиторах он корректно получает рамку окна, и только в гноме (и Weston) он без рамки. И что я должен делать? Ради одного рабочего стола, который «не такой как все» и не хочет думать о пользователях, должен накатать лапшу кода, который нарисует черный прямоугольник и три кнопки управления окном? Да можно libdecor прикрутить но зачем? Вот для таких случаев и нужно xdg-decoration в Гном добавить.

А ты? Ты утверждаешь, как и неадекват Classen, что если приложение работает под Wayland, или собирается на него портануться - оно должно реализовать CSD заголовок.

Да.

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

Нигде.

Ясно, так решил khrundel

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

Не должен, а может. А может и не будет.

Тут не поспоришь. Захочет быть без рамки - будет. Мне вот что интересно, как по-твоему они должны были сформулировать «должен»? Ну должен же текст как-то различаться, чтоб ты понимал, когда «может», а когда «должен». Что должно было быть написано? «Клиент должен нарисовать заголовок не менее N пикселов высотой, как минимум с кнопкой «закрыть» и с рамкой, позволяющей ресайз, толщиной минимум M пикселов»

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

Вот я к примеру самолично добавил поддержку xdg-decoration в RetroArch. Это такой мультисистемный игровой эмулятор. И во всех нормальных композиторах он корректно получает рамку окна, и только в гноме (и Weston) он без рамки. И что я должен делать?

Абсолютно ничего. До тебя, очевидно, у них вообще рамки не было, ты сделал полработы. По-моему сделал неправильно, но это твоё право и право мейнтейнеров решать, принимать или нет. Придёт другой и переделает. Ну или хотя бы исправит баг.

Ясно, так решил khrundel

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

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

реакцию на приход данных в скоет

А при чём здесь графический тулкит? Вы хотите всю функциональность Qt туда запихнуть, иначе не тулкит?

клик мышкой

Мышевозопроблемы.

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

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

Тебе не лень писать новый текст, но лень дать ссылку на мегааргумент? Ну-ну.

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

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

Нет. Это может быть вызвано чем угодно, например, загруженностью разработчиков другими багами. Может свидетельствовать о пренебрежении важностью бага, да — но не о его непонимании.

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

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

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

Вот это всё в теории хорошо, а на практике вообще не разруливаемо в общем случае.

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

Во-вторых, банальная ситуация: пользователь запускает программу. В зависимости от жирности программы и загруженности диска, программа может наконец показать окно моментально, а может через несколько минут. В первом случае, опять же, неудобно на него отдельно переключаться, во-втором — неудобно, когда программа без спросу внезапно таки выползает. Как эти две проблемы различить и совместить? Формально — никак… Вот и страдаем уже много лет. В компизе вот даже настройка упреждающей фокусировки есть, которая имеет эвристические уровни по свойствам окна — но и она не всесильна.

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

виджет-контейнер

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

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

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

Ути-пути!

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

Надейтесь, ага.

Мир дихотомии GTK+/Qt мёртв. Его надо сжечь и на этом пепелище вырастить что-то новое. С серьёзным тулкитом для пошеръюзеров и прочих людей, которые делом занимаются, а не вот этих вот хомячков с «домашними пекарнями», которые вносят путаницу из-за того, что в это понятие влилось понятие «рабочей станции» (ещё хуже, собственно, чем со смартфонами и коммуникаторами было). Самое забавное при том, что ниша «домашних ПК» вымирает, а рабочие станции пока никуда не деваются; нафиг в 2$21-м таргетироваться на тупых — непонятно.

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

Какой может быть одинаковый laf, когда полезный софт (а не только лишь примитивные DE-шные NIH-поделки) на зоопарке несовместимых тулкитов?

Кастомизация как раз сильно упрощается, когда весь софт послушно использует системную тему. Но на линуксах о таком и мечтать не стоит. Да и не только на линуксах.

Вообще в последнее десятилетие тенденция такая, что понятие «системной темы» яростно закапывается, наоборот — каждое приложение должно иметь свой неповторимый, узнаваемый, брендовый вид, по возможности одинаковый между разными платформами. Особенно на мобильниках. На Symbian, S40, A100/A200, REX OS темы отлично менялись и приложения на нативных тулкитах их слушались, а на Android с этим испокон веков всё плохо: либо рут и костыли, либо вендороспецифичные рюшки, либо, если повезёт — оверлеи. На iOS/WP и подавно ахтунг. А уж веб…

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

А что вырвиглазного-то

цвет УГ + IMHO моноспейсные Ш для гуятины Г

в недоделанном состоянии уже больше года

хренасе… яб не выдержал.

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

Эту претензию вон к @EXL отправляй, он тут проповедует libdecor как некое правильное решение, утверждает, что он ещё год назад предлагал такое.

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

В который раз уже повторяю: если хочешь понять суть философии CSD - смотри на то как сделано в MPV.

То есть убого и на отвались. Именно так в MPV сделан заголовок и декорации окна под GNOME в сеансе Wayland:

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

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

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

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

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

Ой, а можно ещё вернуть grp_led:scroll? O:-)

Буду отвечать тебе в стиле GNOME-разработчика: использование LED-светодиодов Caps/Scroll/Num Lock для индикации смены раскладки клавиатуры или ещё чего-либо – ломает существующий UX в некоторых программах.

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

К примеру, вот этот вот эпичный случай в kUbuntu: Инициатива по исправлению бага #112876 в Libreoffice где какой-то кали-школьник из мейнтейнеров этого дистрибутива навесил на grp_led:scroll индикацию смены раскладки языка по умолчанию и сломал LibreOffice Calc.

Так что, «fix your workflow first». Этой вредной функциональности в GNOME/Wayland быть не должно.

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

Таким образом если вдруг qt-company совсем скурвиться, кдешники могут под своим началом опубликовать код под bsd/mit лицензией, что поставит крест над бизнес моделью qt-company, ибо зачем платить деньки, когда есть вариант разрабатывать на кутях и при этом остоваться проприетарщиком.

Да не может это поставить крест на The Qt Company и их бизнесе. Ты реально думаешь что KDE-разработчики будут усиленно фиксить и развивать Qt в направлениях Windows/macOS/Android/iOS?

В случае такого печального развития событий будет просто две версии Qt: одна от KDE-разработчиков под MIT или подобной лицензией, которая KDE-шниками будет развиваться только под Linux и другая – коммерческий Qt от The Qt Company который будут покупать как и покупали для Windows и Embedded в первую очередь.

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

Ты реально думаешь что KDE-разработчики будут усиленно фиксить и развивать Qt в направлениях Windows/macOS/Android/iOS?

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

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

Если так они видят повсеместное внедрение CSD - то пусть валят на свою GNOME OS и не засирают нормальные дистрибутивы своей похабщиной.

Справедливости ради ты говорил что этот libdecor подвязан на XDG-Decoration, а значит у приложений, которые используют эту библиотеку вне GNOME-based окружений будут нормальные декорации окна, то есть похабщина останется только в GNOME.

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

И самостоятельная имплементация всего этого каждым разработчиком тулкита выливается в раздражающие отличия при перемещении и ресайзе оконных контекстов построенных разными тулкитами или даже просто запущенных на xcb vs wayland.

Банальный пример из жизни – QT_QPA_PLATFORM=xcb qbittorrent vs QT_QPA_PLATFORM=wayland qbittorrent в любом GNOME-окружении где есть QGnomePlatform. В первом случае программа имеет адекватный UX из-за SSD, а во втором адекватно пользоваться этим невозможно потому что GNOME-разработчики не смогли реализовать в QGnomePlatform схожий с GTK+ или SSD вариант UX/UI.

В общем, такая хрень из-за CSD будет повсеместно. Когда в одних приложениях границы для ресайза окна определены в 1 px, а в других в 10 px. В одних приложениях ресайзить окно будет сущим адом, а в других – нормально.

Стандартные гайдлайны и HIG’и под это дело, где были бы определены различные стандартные параметры вроде границ и прочего, никто не предоставил. Всё что было опубликовано GNOME-разработчиками на тему CSD это гуманитарный высер их дизайнера «мы сделаем революцию!»*

* – но прошло шесть лет и они вместо революции пилят libdecor и QGnomePlatform.

EXL ★★★★★
()
Последнее исправление: EXL (всего исправлений: 5)

Установил я Solus с KDE. Я в шоке с происходящего я такого адского глюкодрома нигде не видел.

  1. systemd-boot. На ПК еще SSD с виндой то вместо того чтобы создать свой Fat32 раздел на 500мб под свой EFI, оно заюзало 100мб EFI раздел венды ну и out of space.

  2. там проблемы прямо на старте «livecd» тупо nouveau крашится только systemctl restart sddm спасает.

  3. инсталятор после указания страны Россия удаляет англ. раскладку оставляет только русскую! логин пароль говорит пишите на русском! а как я загружусь то?

  4. не вытерпел - снес.

P.S. ждем новости «автор solus закрыл проект и устроился в Apple погромистом»

bhfq ★★★★★
()
Последнее исправление: bhfq (всего исправлений: 3)
Ответ на: комментарий от anonymous

Ответ был на это:

А американские разработчики к проблемам неанглоязычных традиционно относятся как к чему-то непонятному.

А про годы Вы откуда притащили?

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

В беззаголовочных окнах также нет совершенно ничего нового.

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

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

Мне стало интересно как там KDE разрабатывают, на какой лицензии.

На тех же, что и Qt: LGPL3 и GPL3, в зависимости от модуля. А исключение нужно только на черный день, как ядерные боеголовки.

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

Ты реально думаешь что KDE-разработчики будут усиленно фиксить и развивать Qt в направлениях Windows/macOS/Android/iOS?

Кончено же нет. А вот разработчики из KDAB и некоторых других компаний вполне могут скооперироваться и сделать форк.

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

цвет УГ

Возможно, предложите лучше тогда. Мы долго пытались подобрать, каким цветом имитировать зелёную подсветку трансфлективного экрана Nokia 3310, и не подобрали ничего лучше. Вряд ли тут вообще монохром подойдёт, ибо подсветка от светодиодов неравномерная + шероховатая текстура экрана. Уж лучше серый металлический сделать, как в целом на LCD без подсветки.

моноспейсные Ш

Где?

яб не выдержал

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

Почти переписали на Rust, осталось только вид и причесать по мелочи — и тут пришлось оторваться. А нырнуть в разработку опять — уже куда сложнее. Так и сидим с развалюхой.

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

Сам видишь, за 14 страниц вы не придумали ни одного минимально-вменяемого довода в пользу его реализации

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

Тред не читали, уже было? :P

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

Кстати, а так ли нужен KDAB десктопный Linux? И вообще почему они должны развивать собственный форк? Что если The Qt Company сделает им предложение от которого они не смогут отказаться? А если The Qt Company купит их, например? Или, напротив, они сами купят The Qt Company?

В общем, пока ситуации с закрытием исходников Qt нет, все эти домыслы имеют право на жизнь. Но одно можно сказать точно – форки Qt в случае такого решения полезут как грибы после дождя. Ситуация должна быть похожей на ту, когда Oracle ограничил доступ к Java 8.

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

А при чём здесь графический тулкит? Вы хотите всю функциональность Qt туда запихнуть, иначе не тулкит?

Я хочу данные отобразить по приходу по сокету. Без полинга жрущего ЦПУ.

Мышевозопроблемы.

И в консоле мышью вы строки из одного места в другое не копируете?

Только логи смотрите?

Адимн?

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

Кукаретики, которые топят за xdg-decoration, уже сделали патч для его поддержки в Mutter? Или хотя бы для Muffin, или чего-то ещё родственного? Чтобы гордо утверждать, что гномосеки идейно не хотят SSD, а не просто не бегут реализовывать все реквесты подряд от странников, которые на халяву чего-то там хотят?

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

Я хочу данные отобразить по приходу по сокету. Без полинга жрущего ЦПУ

Ну так отображайте, в чём проблема? read не осилили? Или потоки?

И в консоле мышью вы строки из одного места в другое не копируете?

Не копируем, ввиду очевидного отсутствия мыши.

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

Помнится, в Termite (это ведь его переименовали в Kitty? или другой проект от того же автора?) реализовали даже выделение текста с клавиатуры. В Kitty оно есть тоже, надо осилить наконец.

Ну и gpm есть ;)

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

Ну так отображайте, в чём проблема? read не осилили? Или потоки?

Как без полинга сделать реакцию на приход данных и сохранить отзывчивость интерфейса?

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

Гномосеки, которые топят за libdecor, уже сделали патчи для его поддержки во всех приложениях? Или хотя бы в наиболее популярных? Чтобы гордо утверждать, что они идейно не хотят libdecor, а не просто не бегут реализовывать все реквесты подряд от гномосеков, которые на халяву чего-то там хотят?

sudopacman ★★★★★
()
Последнее исправление: sudopacman (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.