gtk2 сам себя не форкнет

GTK2 хорош, вопрос только в том, что делать со всем софтом, который перешёл на GTK3? Реализовывать конверсию GTK3->GTK2 или делать уже отдельный форк GTK3?

И нужно другое название, чтобы не нарушать торговую марку GNOME Foundation - NextTK, NovaUI…

Но можно и без фотка патчи отправлять.

Нужен полноценный независимый форк. Официальные репозитории GTK2/3 как минимум модерируются неадекватами, которые ещё потирают неудобные комментарии. Тот кто владеет доступом к кнопке merge владеет проектом. По другому никак.

https://sourceforge.net/projects/classiclooks/

https://www.pling.com/u/thefrankenstein

css, engine-murrine и очень хорошая совместимость с qt5/6gtk2 плагином.

Бэкпортировать из gtk3 некоторые улучшения в диалогах открытия/сохранения файлов.

Как насчёт поменять gtk-шные файловые диалоги на … На что угодно другое поменяй их, пожалуйста.

Будем делать gtk 2.26

Не нужно.

Нужно.

gtk-engines буду пилить помаленьку:

https://github.com/sde-gui/gtk-engines/issues

Я там попутно пытаюсь с разработчиками LXDE на связь выйти.

Написал одному. Подождал 2 дня. Написал другому.

Может кто-то найдётся.

Разработчик LXDE слушает последнее сообщение wandrien спустя 23 года

Зашел на минутку в гугл с запросом interstellar memes. Провёл там семь часов реальной жизни.

ЧОрная дыра в действии. Работает даде через ютуб.

Та самая, внутри которой ничего нет.

хватит прокрастинировать. гтк сам себя не пропатчит

Чем вызван приступ некрофилии?

Тащемта это давно напрашивалось, поелику GTK+2 это один из немногих нормальных (шустрых и фичастых) графических тулкитов под фрюниксы, из адекватных можно вспомнить разве что FLTK и еще от силы парочку. Будет круто, если дистрибутивы начнут переходить на активный форк вместо выпиливания, несколько лет у wandrien в запасе есть.

Коротко о поддержке переменного DPI в этих наших линуксах.

• Весь такой из себя векторный гипертекстовый GTK3 не в состоянии масштабировать элементы UI под DPI. Полосы прокрутки в нём и так микроскопические, а при увелечении DPI они превращаются просто в какой-то позор. С остальными виджетами не лучше.
• Вместо плавного масштабирования под DPI гытыка может предложить юзеру только целочисленное масштабирование интерфейса. Которое мылит половину иконок. При этом пользователям экранов с DPI 130 предлагается только пососать лапу, например. Потому что с масштабом 1 на таком экране нихрена не видно, а с масштабом 2 - всё гигантское.
• Отдельного порицания заслуживает XFCE. При попытке выставить там в настройках это самое масштабирование 2, получаем это: https://ibb.co/m8wFVFp Если вы тоже не поняли, что за срань из артефактов на экране вместо окон, то вы не одиноки. А разрабам норм, это пошло в релиз.
• Дохренадцать мест в коде жестко прибиты гвоздями к пиксельным размерам, и никто это чинить не собирается. Снова пну XFCE, потому что размеры её панелей никак не масштабируются под размеры шрифта. Шрифт-то с изменением DPI меняется, а вот размер панели - хрен.
• Ну и в третий раз пну, уж не знаю кого, XFCE или GTK, но у XFCE менюшки, такие как меню приложений или меню выхода из системы, не умеют пересчитывать свой размер динамически. Изменяем DPI в настройках, и вёрстка в менюшке разъезжается. Красота!

И вот на фоне этого мрака EXL носится со своим скриншотом кривой поделки на wxwidgets, которая якобы доказывает, что gtk2 не годен для переменного DPI. А вот эта вся срань годна что ли?

Снова живующие под кроватью зелёные человечки из зубной пасты помешали Матиасу, мать его, Класену адекватно спроектировать тулкит?

Тут вон в теме выше вопрошали: это что же, для полной поддержки DPI нужно патчить прикладной софт?

Нужно!

Потому что если не патчить, то получается описанная выше херня, и никакой волшебный тулкит не спасает. А если он не волшебный и запроектирован как курица лапой - тем более.

А может просто в качестве костыля для GTK3 сделать тему для HiDPI, xHiDPI, xxHiDPI экранов?

Может и нужно, но вряд ли осилят.

пользователям экранов с DPI 130 предлагается только пососать лапу

ССЗБ. При удалении от магических 96 линуксовые гуи начинают рассыпаться, какие бы там нанотехнологии не были заявлены. Ещё и растровые шрифты отыквляются. Мне кажется всем пофиг, потому что линукс это система для сисадминов и нищуков. В консоле можно терминус покрупнее выставить, а на ноуте с 1366x768 эти проблемы совсем уже не беспокоят.

Какова цель вашего форканья?

Нужно.
posixbit ★

Ахах, нужнист выпилился. Это смешно.

Умерла затея?

ждем автора треда

Судя по ГХ даже не начавшись))

Пишите ваши соображения.

сделать масштабирование и добиться принятия этого в апстримдистры.

всё.

блин, некромант

Что с тобой было эти 4 месяца, спустя которые тебя так прорвало? :)

А, это некротред.

А тем временем GTK2 уже форкнули:

В звуковом редакторе Ardour 8.4 создано собственное ответвление GTK2 (21.02.2024).

https://github.com/Ardour/ardour/tree/master/gtk2_ardour

Ну а вдруг прокатит, на чужом горбе в рай вывезти, лол

Что там с форком?

Ardour, причём ни на какие gtk3 или qt они принципиально переходить не собираются.

Ardour не собирается уходить от gtk2

Так у вас же есть xlibe, что мешает собрать gtk2 для haiku с его помощью?

Во-первых, СДВГ не страдают, как не страдают альбинизмом.

Во-вторых, раз не нужны, значит, не нужны, удачи в начинаниях.

Так у вас же есть xlibe

Эта штука довольно кривая и неполная. Сделать полноценную альтернативную реализацию X11/xlib с нуля – это очень сложная задача. Wayland намного проще X11.

Скорее всего в итоге полноценная поддержка протокола X11 будет добавлена через XWayland.

Черновик по DPI, сюда скину.

Сижу над черновиком кода.

Понимаю, что ничего не соображает голова. Не знаю, то ли это побочка от гриппа, то ли я просто тупею от возраста. Уже 4-й день как прошла температура, но ясность сознания не возвращается. Вчера с трудом код SDE читал, та же петрушка.

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

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

Я прошу прощения за злорадство, но уж очень СДВГшная картинка.

То же, что и с остальными форками ТСа: планы, черновики, полурабочие демки. Ты чего-то другого ждал?

Ещё в зависимостях нету ffmpega и не планируется системД )) я бы с удовольствием помог, тока тупой по гтк2((

Не, сдвг иначе проявляется. Сдв это вот что я год к проекту не возвращался.

А что мысли в кучу не могу собрать, это когнитивка просела. Надо витаминов каких купить, что ли.

Ну вроде собрал кпртинку методов. Ща прогуляюсь по магазинам и с компа попробую изобразить.

Понимаю, что ничего не соображает голова. Не знаю, то ли это побочка от гриппа, то ли я просто тупею от возраста.

попробуй меньше торчать на лоре, сливая силы в пустоту

Подписался на тред, готов поучаствовать в отладке и тестировании.

Надо витаминов каких купить, что ли.

Обычно советуют глицин, но лучше сделать анализы, в том числе на разные D.

Скейлить UI в приложении можно либо на уровне всего приложения целиком, либо на уровне отдельных окон.

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

Первая задача требует меньшего объёма изменений со стороны кода приложений, вторая – большего. Это связано с тем, что масштабирование на уровне отдельных окон требует контекста в виде объекта типа GdkWindow. Не во всех случаях, когда приложение вычисляет какие-либо размеры, у него доступен объект этого типа. То есть может потребоваться более сущестенная переделка кода приложения.

Теперь собственно к самому GTK.

GdkScreen – это класс, соответствующий понятию Screen в X11. В рамках одного Screen может быть сконфигурировано произвольное число мониторов.

Каждый GdkScreen держит указатель на экземпляр GtkSettings – класса, отвечающего за хранение и получение настроек.

Работа с иконками в основном сосредоточена в модуле gtkiconfactory.c. Там содержится функция, которая возврвщает пиксельные размеры иконки для заданного логического размера:

gboolean
gtk_icon_size_lookup_for_settings (
        GtkSettings *settings,
        GtkIconSize  size,
        gint        *width,
        gint        *height);

Документация в качестве лучшей альтернативы предлагает использовать функцию gtk_widget_render_icon().

gtk_widget_render_icon() через цепочку вызовов обращается к gtk_icon_size_lookup_for_settings() для получения размеров иконок.

Отсюда такой вывод:

Прикладной код, который использует gtk_widget_render_icon(), может быть легко переведён на per-window скейлинг иконок. Прикладной код, который напрямую использует gtk_icon_size_lookup_for_settings(), будет требовать более существенной модификации.

Пока такой прикладной API вырисовывается:

GtkUiScale
        gtk_ui_scale_apply_for_int()   // метод для фактического масштабирования
        gtk_ui_scale_apply_for_double()// метод для фактического масштабирования
        event: "changed"               // срабатывает, когда настройки масштабирования изменились

GdkScreen:
        property: "ui-scale"       // GtkUiScale для данного экрана
        gdk_screen_get_ui_scale()  // возвращает ui-scale
        gdk_screen_set_ui_scale()  // устанавливает ui-scale
        event: "ui-scale-changed"  // срабатывает когда срабатывает "changed" у GtkUiScale
                                   // или когда свойству ui-scale назначен новый объект
GdkWindow:
        property: "ui-scale"       // GtkUiScale для данного окна
        gdk_window_get_ui_scale()  // возвращает ui-scale
        gdk_window_set_ui_scale()  // устанавливает ui-scale
        event: "ui-scale-changed"  // срабатывает когда срабатывает "changed" у GtkUiScale
                                   // или когда свойству ui-scale назначен новый объект
gtkiconfactory.c:
        gtk_icon_size_lookup_for_settings_with_ui_scale()

GtkUiScale – это либо абстрактный базовый класс, либо интерфейс. Пока не решил.

В простейшем случае реализация GtkUiScale подписывается на уведомления от объекта GtkSettings, а также на события со стороны оконной системы и пересчитывает масштабные коэффициенты в соответствии с меняющимися настройками.

При необходимости приложение может подсунуть собственную реализацию GtkUiScale окну внутри своего процесса и напрямую управлять его масштабированием. (Например, для отображения макета окна в каком-нибудь редакторе UI.)

(Башка капец в тумане сегодня. Вечером жахну триптофану, чтобы выспаться. Может поможет…)

А зачем приложению вообще что-то знать о масштабировании? Да и об отрисовке как таковой? По идее оно должно накидать виджетов layout manager'у и это станут ЕГО проблемы, как он их расположит, а потом передаст рендереру.