LINUX.ORG.RU

Архитектура опен сурс программ не должна зависеть от GUI-библиотек (gtk, qt и подобные)

 , , , ,


0

3

Появилась у меня мысль. Что программы на открытом исходном коде не должны быть привязаны к какой либо ГУИ-библиотеке. Т.к. положение этих ГУИ-библиотек (и их владельцев) позволяет им диктовать и портить чужие программы. Пример это файловые диалоги открытия и сохранения файлов. Которые намеренно не фиксятся владальцами проекта Gnome. А альтернативные файловые диалоги по простому не прикрутишь. В идеале правильная разработка опен сурс программ должна вести по архитектуре без привязки к какой либо ГУИ-библиотеки. Типа написание бакенда отдельно от фронтенда. Большинство программистов этого не понимают и создают будущие проблемы для своих программ. Или в линуксе должна быть какаята прослойка между программами и гуи-библиотеками. Хотя есть Wxwidgets. А Wxwidgets поддерживает только С++. Но должно быть чтото более универсальное. Поддерживающее все языки (большинство популярных).

К подобным плохим библиотекам также относятся DE-библиотеки такие как Gnome, KDE. Которые обманчивао создают иллюзию упрощения разработки програм. Но в результате привязывают программиста к своим ГУИ-библиотекам. Примером является хорошая программа Ktorrent которая теперь сильно привязана к KDE.

А вы что думаете ? Я прав или нет ?

Какие ещё средства существуют для написания программ не привязанных к одной ГУИ-библиотеке ? Чтобы не было типа как вендорлока.

Поведение ГУИ библиотек напоминает мне поведение проприетарщиков с их вендор локом.

Привязка к поставщику (англ. vendor lock-in, proprietary lock-in, customer lock-in, «барьер для смены поставщика») — бизнес-модель, в которой устанавливается зависимость потребителя от продуктов и услуг одного поставщика, намеренно создаются осложнения для смены поставщика из‑за высоких затрат на переход.

Поставщики заинтересованы намеренно создавать замыкание для завоевания большой доли рынка, что иногда приводит к появлению монополии и «стандартов де-факто».

https://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%B8%D0%B2%D1%8F%D0%B7%D0%BA%D0%B0_%D0%BA_%D0%BF%D0%BE%D1%81%D1%82%D0%B0%D0%B2%D1%89%D0%B8%D0%BA%D1%83

Ответ на: комментарий от wandrien

в одном процессе не запустишь из-за конфликта имён функций

С помощью symbol versioning можно избежать коллизии имён и разрешать символы с указанием динамической библиотеки как в Windows DLL.

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

Читаю этот список изменений, и вроде почти каждое само по себе – полезное улучшение. А потом вспоминаю, что как gtk не улучшай, всё равно трамвай из буханки хлеба…

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

С помощью symbol versioning можно избежать коллизии имён и разрешать символы с указанием динамической библиотеки как в Windows DLL.

Ну ты же знаешь, что это фантазии, да?

Ты еще скажи, что в RH заботятся о совместимости старого кода…

Они целый GNOME3 выкатили с конфликтами имён на уровне файлов с GNOME2, а уж такая мелочь как символы, пффф… скажите спасибо, что хоть soname поменяли. А то могли как недавно в pango.

wandrien ★★
()

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

anonymous
()

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

Если нужен какой-нибудь сложный кроссплатформенный интерактивный интерфейс с графическими эффектами и т.п. - ну да, наверно имеет смысл использовать GTK или Qt. Но сколько таких программ, 1%, или еще меньше? А для всего остального, может, вполне подойдет что-нибудь сильно попроще? Dear ImGui какой-нибудь. Или вообще TUI, например.

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

А нарисуй на ImGui UI ну хотя бы для DeadBeef…

И вообще, попробуй составить список «всего остального», которому достаточно ImGui. Браузеры туда попадут? Видеоредакторы? Офисные пакеты?

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

Нет конечно. Там даже drag&drop без боли не реализовать, ибо immediate mode. Про более сложные вещи типа полноценной поддержки текста, hidpi и accessibility можно даже не заикаться.

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

RazrFalcon ★★★★★
()

Давно уже так и стараюсь делать. Есть пара поделок на этом принципе и гуйня к ним на CLI, QML, Qt, GTK (ужо дописанная сторонними юзерами)

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

И вообще, попробуй составить список «всего остального», которому достаточно ImGui

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

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

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

Так и прикладных программистов осталось не так много, чтобы их так ценить. Кого ценят, тем платят.

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

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

И что же тогда «всё остальное», кроме, может быть, плееров (и даже к плееру ImGui ты пока ещё не приделал)?

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

P.S. mpv вообще консольный, кстати. К нему есть оболочка — smplayer — и она, внезапно, на Qt. :) (Возможно, есть и другие.)

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

stdin, stdout, stderr.

using namespace std не забудьте.

using

Владимир

anonymous
()

Такие программы уже есть. Например - Transmission. Клиент-серверная архитектура и несколько доступных оболочек.

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

Единственный «вездесущий» язык - это C. Но он не для всех.

Либо, как вариант, тоже утопичный, отказаться от прямой линковки и использовать микроархитектуру/клиент-сервер. А для связи между компонентами использовать Socket/IPC(DBUS)/REST/RPC/Protobuf/gRPC/Whatever. В таком случае становится неважным, на чём ты пишешь Core-сервис, а на чём оболочку. Главное представить API интерфейс. Но становится важным способ взаимодействия, потому что у каждого есть свои достоинства и недостатки. DBUS например - небыстро и *nix-only. Сокеты - заморачиваться с сериализацией + ЕМНИП в Windows это работать не будет.

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

Либо, как вариант, тоже утопичный, отказаться от прямой линковки и использовать микроархитектуру/клиент-сервер. А для связи между компонентами использовать Socket/IPC(DBUS)/REST/RPC/Protobuf/gRPC/Whatever.

Хотя, учитывая, что единственный кроссплатформенный, безтулкитный и универсальный гуй сейчас - Web, оно не так уж утопично.

FixingGunsInAir
()

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

Вот когда напишут нормальный тулкит на Rust, тогда все другие тулкиты станут ненужными. Вот тогда заживём.

anonymous
()

Архитектура опен сурс программ не должна зависеть от GUI-библиотек (gtk, qt и подобные)

transmission уже упомянули. Ещё есть Wireshark: библиотека, консольный клиент, Gtk-клиент (который можно продолжать развивать сообществом), Qt-клиент.

Но должно быть чтото более универсальное. Поддерживающее все языки (большинство популярных).

Для этого изобрели GObject Introspection в glib. Пишешь один раз на Си, используя GObject, используешь на многих-многих других языках. GObject не без недостатков, но пока так и не взялись за его 2-ую версию или что-то с другим названием.

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

Вот когда напишут нормальный тулкит на Rust

У него есть стабильное ABI и возможность обращаться из других языков без обёрток?

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

то почему его можно установить в Гайке?

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

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

У него есть стабильное ABI и возможность обращаться из других языков без обёрток?

Вот когда напишут, тогда и узнаем

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

Нет в десктопе никакой принципиальной разницы со времён Mac OS Classic, а может даже Xerox Star (1981). Тулкиты никак не мешают делать новые оболочки, доки и т.п. Можно и на WinApi написать DE, что от GNOME 3 не отличишь

Sic! Это тяжелое наследие разработки ксерокса, у которог интерфейс прогибал пользователя под упрощение программной реализации. Игры довольно давно избавились от этих оков, получив целостную логику интерфейса, где на отдельные сущности могут быть разбиты разве что данные. Могу представить, сколько понадобилось усилий у нанятых MS дизайнеров, чтобы заставить кодеров сделать предпросмотр нового стиля текста при наведении курсора. А OpenOffice/LibreOffice еще лет десять эту фичу не подхватят.

byko3y ★★★★
()

Какие ещё средства существуют для написания программ не привязанных к одной ГУИ-библиотеке ?

Lazarus, который кучу GUI поддерживает https://wiki.lazarus.freepascal.org/Widgetset

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