LINUX.ORG.RU
ФорумTalks

Устанавливать программы вместе с зависимостями, не портя стиль

 


0

1

Решение большинства проблем - поиграться с версиями программы. А при использовании разделяемых библиотек это невозможно. Вроде бы для установки программ вместе с библиотеками существует AppImage и его альтернативы, но все они портят стили (или темы или look & feel) приложений. Попробуйте запустить например mkvtoolnix-gui установленный через apt и AppImage и вы увидите, что интерфейс не одинаковый.

Как я понимаю, за внешний вид графических программ отвечает тема Qt или Gtk, эти библиотеки передают X-серверу команды типа «нарисуй такие-то пиксели», а не «нарисуй такую-то кнопку и напиши такой-то текст». Тогда возможное решение - не паковать Qt с приложением, а использовать системную, но такой AppImage будет не совсем переносимым, потому что в Qt обратной совместимости нет и программа, которой нужна Qt3, на современных дистрибутивах не запустится, насчет Gtk не знаю.

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

★★★

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

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

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

papin-aziat ★★★★★
()

Как же это так сделано и почему мы не можем сделать так же?

Потому что в винде нет зоопарка тулкитов, графических подсистем и прочего.

alex1101
()

В Винде программы тащат все либы с собой

Неправда. Часть использует только системные библиотеки, часть срут прямо в system32, от чего dll hell и поломка других приложений, но формально эти dll полноценно shared.

но там все программы выглядят одинаково и согласно стилю той версии Винды, на которой они выполняются и настройкам персонализации

Неправда. Только поколений нативных контролов виндового GUI было штук 20, не считая всяких плиток и риббонов. Запусти программу 20летней давности (а лучше с win3.11), увидишь как она отличается. Потом, под виндой есть те же qt, gtk и wx не считая всякой маргинальщины, которые даже используя нативные контролы применяют свои движки и правила компоновки (layout), либо же вообще используют полностью свои темы. Ну и естественно полностью собственные UI движки есть у винампов, игрушек и штук типа blender.

Как же это так сделано и почему мы не можем сделать так же?

Это не сделано и сделано не быть не может. Система может в той или иной степени пытаться насаждать единую библиотеку GUI или гайдлайны типа MD или HIG, но пока есть возможность задавать руками координаты кнопочек, да и вообще выводить произвольные растры и векторную графику, кто-то будет лепить своё. Аналогично, даже при использовании нативного GUI и следования всем возможным гайдлайнам, из-за того что мир меняется (от текущих представлен6ий об UX до разрешений и диагоналей мониторов и средств ввода), приложения неизбежно перестанут выглядеть нативно (или вообще адекватно) с течением времени.

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

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

slovazap ★★★★★
()

Решение большинства проблем - поиграться с версиями программы. А при использовании разделяемых библиотек это невозможно.

Пользователи NixOS смотрят на тебя с недоумением.

t184256 ★★★★★
()

В Винде программы тащат все либы с собой, но там все программы выглядят одинаково и согласно стилю той версии Винды

На сколько я понимаю те программы которые «выглядят одинаково и согласно стилю той версии Винды», используют системные библиотеки для отрисовки интерфейса (WinAPI или как его там, я ХЗ). Ну или предпринимают отдельные усилия чтобы мимикрировать под приложения использующие системные библиотеки (кажется Qt делает так). Но это не точно, в GUI и винде я слабо разбираюсь

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

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

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

Поэтому таки да, было бы здорово, если бы какие-нибудь базовые функии GTK\Qt\Tk\прочего, были бы причесаны и стандартизированы.

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

Но ведь для нее пишут на тех же самых Qt, Gtk и еще каких-то проприетарных тулкитах.

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

У меня как раз есть минутка поговорить о дистрибутивах Linux.

Насколько эффективно в NixOS решается проблема dependency hell? У меня впечатление, что это для серверов, чтобы сисадминам удобно было всякие апачи поднимать. А насколько она пригодна для десктопа? Там просто, как я понял, все настройки текстовые.

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

Пишу с лаптопа на NixOS, ни на что не променяю.

Проблему dependency hell надо еще сформулировать, как-то целый тред кто-то пытался применить это к NixOS и никак.

t184256 ★★★★★
()
Последнее исправление: t184256 (всего исправлений: 1)
6 января 2023 г.
Ответ на: комментарий от fox_mulder

Но оно не работает

flatpak override --filesystem=xdg-data/themes --user org.kde.kontact
flatpak run  --command=sh org.kde.kontact
/app/bin/akonadictl restart
/app/bin/kmail
Открывается в том стиле, с которым опакечен.

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

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

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

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