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

Бабки

У них ещё есть корысть в том что эти ГУИ-проекты живут на донаты (возможно большие от больших компаний). И им выгодно привязывать любой ценой программистов (жертв) к своим библиотекам.

ukazatelnastek
() автор топика

DE-библиотеки такие как Gnome, KDE. Которые обманчивао создают иллюзию упрощения разработки програм.

Однако!

MaxPower ★★
()

ммм, ты наверно хочешь чтобы всё было ещё кроссплаформенным и без багов?

sparks ★★★
()

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

Electron же. Ты можешь распаковать любое приложение и запустить его в любом браузере который тебе нравится.

А вообще, чувак, ты просто описал современный Web сейчас. Сам посуди: бэкенд может быть написан на любом языке, умеющем сокеты. Фронтенд пишется на специальном стандартизированном языке разметки. Для фронта есть минимум две независимые реализации рендеринга. Всё как ты хочешь.

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

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

Begemoth ★★★★★
()

Появилась у меня мысль

Так почему ты эту мысль не высказал? А вместо этого запостил какую-то шизофазическую бредятину?

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

Так аффтор же сетует на то, что файловый диалог дескать в его Electon-приложении или браузере плохой и негодный. Из ненавистных KDE или GNOME. Qt или GTK+.

Нужны файловые диалоги на HTML+JavaScript+CSS под управлением самого Electron’а. Неужели такого ещё нет? Не верю.

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

Мысль надо иллюстрировать на примере.

andalevor ★★
()

Аминь. «Продолжайте наблюдение» (с)

slackwarrior ★★★★★
()

Взял и написал файловый диалог для GTK программы на SDL2 и всё, ты независим. Но судя по твои словам все программы должны быть серверами и при запуске открывать порт тот или иной, а графический тулкит выбранны пользователем просто должен подхватывать сигналы парсить унифицированный формат и показывать. Тоесть если не изобретать ничего нового, а использовать то что есть ты предлагаешь по сути WEB. А чё давай все приложухи запукать под nginx libc и другие библиотеки будут замененны через LD_PRELOAD на врапперы которые будут транслировать вызовы в json который будет отправляться gtk/qt/иное серверам те с свою очередь будут спавнить процессы с виджетами набор которых выбрал пользователь или даже открывать TUI варианты виджетов или даже открывать браузер где на js реализован нужный функионал. Ога, гибко, независимо, модульно. Где мой проц на 7 гигагерцев и полтеррабайта памяти.

LINUX-ORG-RU ★★★★★
()

Указатель Настек?

Где твой код?

wandrien ★★
()

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

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

papin-aziat ★★★★★
()

А вы что думаете?

Я думаю, что нужно сделать дефолтный тулкит и проблема исчезнет сама собой. 80% станут ориентироваться на него, 15% продолжат писать на своих тулкитах и проблемы консистентности интерфейса лягут на их плечи. Оставшиеся 5%, естественно, запилят свои дистрибутивы, с тулкитом отличным от мейнстримного. Куда ж без этого.

qtm ★★★
()

Да вообще эти корпорации обнаглели!!! Заставляют разработчиков привязываться к определенной технологии. Каждая прогрмма должна быть написана на асемблере! Нет, на машинных кодах! И каждый раз программист должен писать все низкоуровневые функции самостоятельно (от работы с файлами, до рендеринга окон).

А тепепь серьезно. В идеале конечно хочется иметь знания и опыт без привязки к определенному поставщику библиотеки. Но мы не живем в идеальном мире, поэтому у нас десятки библиотек для одних и тех же нужд и даже языков. Поэтому приходится выбирать. К тому же от выбора библиотеки для gui очень сильно зависит методология построения работы с этим gui. Поэтому сильно разносить фронт и бэк (чтобы легко было поменять gui библиотеку) - иногда долго и заказчик не готов за это платить. Так или иначе с точки зрения архитектуры программа должна быть постороена таким образом, чтобы отдельные компоненты выполняли небольшое количество обязанностей (лучше одну), т.е. программа дробилась на небольшие функции/классы/библиотеки. Тогда в случае необходимости замены gui библиотеки часть этих компонентов можно будет использовать без изменений.

rumgot ★★★★★
()
Последнее исправление: rumgot (всего исправлений: 1)
Ответ на: комментарий от LINUX-ORG-RU

Работает. Версии тулкита ничем принципиально не отличаются от версий любого другого софта.

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

qtm ★★★
()
Ответ на: комментарий от LINUX-ORG-RU

Ога, гибко, независимо, модульно. Где мой проц на 7 гигагерцев и полтеррабайта памяти.

Люблю, когда в конце такая улыбательная концовка :-)

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

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

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

wandrien ★★
()

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

Мыслишь правильно. GUI ИМХО нужно новое. По крайней мере для своего велосипеда, поскольку Запорожец в Мерседес переделать сложно /скорее всего и не получится/.

Владимир

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

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

И много фич развили те три с половиной калеки, которые работают на gtk2?

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

И много фич развили те три с половиной калеки, которые работают на gtk2?

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

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

Лучше подумай, если переход на новую версию тулкита (а не с тулкита на тулкит) - такой затратный по человекочасам, почему же все не сидят первой версии gtk?

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

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

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

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

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

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

Сидите со своими 3 процентами и гордитесь «новьём» на обочине индустрии. Зато не говно мамонта.

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

почему в Windows компилируются и работают приложения 1995-го года

Потому что это неправда. Например, True Love не работает на WinXP и выше. И такого вагон и тележка,

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

Да кто мешает 10-15 лет использовать старую версию тулкита, епт? GIMP же использует и ничего, живой. Вот только не надо оправдывать это какой-то экстрафичастостью, ее там нет. И архисложностью тоже не надо оправдывать. Если твой софт не выдержит обновление тулкита, то это не тулкит плохой, это софт - говно.

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

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

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

Да кто мешает 10-15 лет использовать старую версию тулкита, епт?

Тебе? Религиозные убеждения. Мне? Ничего не мешает.

Если твой софт не выдержит обновление тулкита, то это не тулкит плохой, это софт - говно.

Эксперт по тулкитам. Не вижу в профиле ссылки на гитхаб.

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

Вообще, стоит полазить по рутрекеру, как окажется, что весь старый софт/игры предлагается запускать в виртуалке.

…потому что с ОС несовместим либо кряк, либо механизм защиты, использовавший глубокие потроха системы.

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

Как показывает опыт проекта wine, если делать софт строго по документации, то ни в одной винде он вообще работать не будет. Потому что документация врёт на каждом шагу.

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

Эксперт по тулкитам. Не вижу в профиле ссылки на гитхаб.

Спервадобейся!

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

Какой кряк и/или защита были в MM6, что для запуска на современных виндах ему требуется патч от ГрейФейса? Спойлер: там нет защиты от слова совсем.

gremlin_the_red ★★★★★
()

Поддерживаю афтора!

Gtk, Qt захвачено корпорастами и умышленно г-вняется.

API должно быть обратно-совместимо как минимум 15 лет!

ЗАПРЕТИТЬ:
1) изменять интерфейсы старых функций (менять список параметров и их формат, менять имена функций, имена модулей и т.д.)
2) полностью удалять старые функции (например, вырезать трей)
3) частично урезать функционал старых функций (например, убирать какие-то элементы виджета или вырезать функционал).

РАЗРЕШИТЬ:
1) добавлять новые функции и новые модули
2) улучшать тело старых функций (сорхраняя интерфейс, функционал и поведение).

Общее правило: если ты гадёнышь хочешь что-то новое, то делаешь это РЯДОМ с существующим, а НЕ ВМЕСТО него!

По идее, за этим должны следить дистростроители и безжалостно вырезать такие библиотеки из дистрибутивов. Но так как дистры щас тоже захватили корпорасты, то всё корпоративное г-но внедряется без разбора.

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

И что показывает опыт проекта wine?

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

gremlin_the_red ★★★★★
()

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

Всё верно, быстроменяющиеся стандарты - это диверсия против СПО.

Причём диверсии идут не только в ГУИ, но в других сферах: в Вебе, в компиляторах, даже в загрузчиках.

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

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

Они хотя бы работают.

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

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

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

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