Архитектура опен сурс программ не должна зависеть от GUI-библиотек (gtk, qt и подобные)
Появилась у меня мысль. Что программы на открытом исходном коде не должны быть привязаны к какой либо ГУИ-библиотеке. Т.к. положение этих ГУИ-библиотек (и их владельцев) позволяет им диктовать и портить чужие программы. Пример это файловые диалоги открытия и сохранения файлов. Которые намеренно не фиксятся владальцами проекта Gnome. А альтернативные файловые диалоги по простому не прикрутишь. В идеале правильная разработка опен сурс программ должна вести по архитектуре без привязки к какой либо ГУИ-библиотеки. Типа написание бакенда отдельно от фронтенда. Большинство программистов этого не понимают и создают будущие проблемы для своих программ. Или в линуксе должна быть какаята прослойка между программами и гуи-библиотеками. Хотя есть Wxwidgets. А Wxwidgets поддерживает только С++. Но должно быть чтото более универсальное. Поддерживающее все языки (большинство популярных).
К подобным плохим библиотекам также относятся DE-библиотеки такие как Gnome, KDE. Которые обманчивао создают иллюзию упрощения разработки програм. Но в результате привязывают программиста к своим ГУИ-библиотекам. Примером является хорошая программа Ktorrent которая теперь сильно привязана к KDE.
А вы что думаете ? Я прав или нет ?
Какие ещё средства существуют для написания программ не привязанных к одной ГУИ-библиотеке ? Чтобы не было типа как вендорлока.
Поведение ГУИ библиотек напоминает мне поведение проприетарщиков с их вендор локом.
Привязка к поставщику (англ. vendor lock-in, proprietary lock-in, customer lock-in, «барьер для смены поставщика») — бизнес-модель, в которой устанавливается зависимость потребителя от продуктов и услуг одного поставщика, намеренно создаются осложнения для смены поставщика из‑за высоких затрат на переход.
Поставщики заинтересованы намеренно создавать замыкание для завоевания большой доли рынка, что иногда приводит к появлению монополии и «стандартов де-факто».