LINUX.ORG.RU
ФорумTalks

Почему всё так всрато?

 


0

5

Навеяно программированием.

Вот сижу, никого не трогаю, программирую. Я не то что бы нубас в системном программировании, в прошлом под ДОС даже многозадачные оболочки писал на пассале, но и не гуру, тем более не гуру красноглазия.

Но все таки некоторые «решения» меня откровенно удивляют.

Вот взять например «системный трей».

Первая реализация этой штуки была реализована в 2002 году, уже после выхода XP, во время скажем так «претензии Линукса на десктоп». Реализаторы этой срани почему-то посчитали, что для вывода иконки приложения в определенную зону, и вызова контекстного меню по нажатию на эту иконку - нужно создавать целую сороконожку на костылях и сажать ее на велосипед с квадратными колесами. По логике реализаторов, приложение которое хочет в трей, обязано общаться с этим треем через протокол в протоколе в Иксах, при этом этот трей прежде должен был правильно инициализироваться и создать свою область (именно поэтому мы иногда могли видеть «another instance of systray already running», когда запускали вторую копию панели или системтрейного плагина). Если его не было - то приложение не могло быть затреено, соответственно при запуске трея, трей был обязан послать сообщение через Иксы всем приложениям, что вот он, я, запущен, треемся. Регистрация «действия», таких как активация или контекстное меню - так вообще сплошная головная боль. В итоге самая минималистичная программа, у которой три задачи: а) вывести иконки, б) обрабатывать их изменения, в) кидать вызов программе для активации ее, или контекстного меню - занимала почти тысячу строчек.

Шло время, и индеец Зоркий Глаз через ~15 лет увидел, что как-то это все не тру, и решил с подачи Каноникла и Кедов переделать этот велосипед, чтоб на нем было приятнее ездить.

И не нашли ничего лучше, чем срать через d-bus. Типа приложение, которое хочет в трей - создает сервис в d-bus'е, StatusNotifierItem, вместе с фичами которые оно хочет, а другие приложения обязаны это читать, опять же через этот d-bus, и если хотят что-то с приложением сделать - должны через d-bus послать сигнал, который приложение застолбило.

Какой же это бред.

С 1985 существует ProcFS. Она следовала юниксовому принципу «все есть файл». Она предназначена для взаимодействия процесса с ядром, ядра с процессом, и процесса с процессом.

Ну вот что мешало приложению создать в своем пространстве запись «/proc/PID/i_want_to_be_trayed», «/proc/PID/my_tray_icon», и «/proc/PID/tray_menu», куда можно сделать «echo activate > /proc/PID/tray_menu» или echo «contextmenu» > /proc/PID/tray_menu ? Соответственно приложение которое хочет в трей - создает у себя в пространстве запись, а приложение которое хочет прочитать треевые приложения - просто пробегается в поиске «i_want_to_be_trayed»? И все! Все чтения изменений через простой inotify.

В порыве экспериментизма, я сделал вменяемую, простую, работающую реализацию такого трея за 4 часа. Эта реализация работает на PHP, C, Python, Pascal, Bash. Она не требует знаний третьей технологии (иксов, dbus, etc). В клиентском приложении она реализуется 10 строками на PHP, 25 строками на С, из которых 10 строк - строки и память.

О работе с иксами, d-bus, и wayland я расскажу в следующей серии.

Ну вот почему пингвинятники вечно идут каким-то своим, оверинжинирнутым путем? Ведь это снижает порог входа тех кто знает ЧТО писать, но не знает КАК.

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

кроме тебя есть еще люди, у которых эти фичи востребованы

А мне с этого что?

и их большинство

Статистику в студию.

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

Будешь на каждый чих новый файлик добавлять?

О, я как раз дочитал обсуждение на предмет, не запилил ли кто до меня камент про «ну дичь же медленная – всё через файлы делать». Оно конечно надо бы посмотреть-сравнить количества syscall-ов в решениях с файлами и с dbus, но по общефилософским соображениям, в задаче прямой передачи данных между двумя процессами, файл – лишняя сущность-посредник.

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

Библиотеки для dbus есть практически для любого языка.

Помнится, когда-то пробегал слушок, что парни из интела, сделавшие iwd, настолько преисполнились качеством тех библиотек, что запилили свою реализацию.

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

Я не против файлов. Напротив, я за файлы, но не file-per-chih же. Да еще и в ядерном /proc.
Как я понимаю Иксы так и работают: общаются через сокет.

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

Это не WM, а wayland compositor. Любишь на конструкторе кататься, умей и док прикрутить, интерфейс для дока там есть.

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

Потому что это сложные вещи. Ты вот предложил проблему решить парой файликов-флагов в /proc (или другом месте). А события обрабатывать как? Пользователь кликнул на иконку; программа захотела перерисовать иконку. Будешь на каждый чих новый файлик добавлять?

Оно УЖЕ так реализовано, только в другом месте, точнее в xdg_menu.

Открой практически любой .desktop-файл в /usr/share/applications и увидишь там нечто типа

[Desktop Action new-private-window]
Exec=/usr/lib/firefox --private-window %u

И это самая ПРАВИЛЬНАЯ реализация, благодаря которой приватное окно вышеупомянутого фаерфокса может запустить любой запускатор без привязок к любой 3rdparty-всратой технологии.

А мы предлагаем приложению сидеть с открытым в Иксы сокете ждать в loop'е пока с этого сокета прилетит ивент на открытие контекстного или иного меню, который запишет в Иксы через уже другой открытый сокет другое приложение, отлавливающее правый клик по иконке. Бред. И привязка к Иксам.

D-bus сделал то же самое кстати, только вместо Иксового сокета теперь открыт d-busно-сессионный, т.е. идиоты-кедерасты даже не осознали что для активации контекстного меню программы не нужно никаких сокетов и костылей.

Поначалу может показаться, как так, ведь это будет два разных окна, и тд. Но к счастью все все фреймворки и даже голые X умеют как в вывод в другое окно, так и в отлов событий. Иными словами ./app;./app --menu может вывести меню в окне предыдущего ./app. Как нибудь так:

#include <gtk/gtk.h>
int main(int argc, char *argv[]) {
    GtkWidget *window;
    gtk_init(&argc, &argv);
    window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
    gtk_window_set_title(GTK_WINDOW(window), "My Window");
    gtk_window_set_default_size(GTK_WINDOW(window), 300, 200);
    gtk_window_set_wmclass(GTK_WINDOW(window), "MyWindow", "MyWindowClass");
    g_signal_connect(window, "destroy", G_CALLBACK(gtk_main_quit), NULL);
    gtk_widget_show(window);
    gtk_main();
    return 0;
}
#include <gtk/gtk.h>
int main(int argc, char *argv[]) {
    GtkWidget *button;
    gtk_init(&argc, &argv);
    // Ищем наше уже открытое окошко
    GtkWindow *window = (GtkWindow *)gtk_window_lookup_for_display(gdk_display_get_default(), "MyWindow", "MyWindowClass");
    if (!window) {
        g_error("Окна нет, можем сообщать ошибку, а можем просто рисовать приложение далее");
        return 1;
    }
    button = gtk_button_new_with_label("Кнопка в окне №1");
    gtk_container_add(GTK_CONTAINER(window), button);
    gtk_widget_show(button);
    return 0;
}

Даже на Си это фонарный код, с которым даже школоло разберется. Ну, можно добавить еще проверки, на PID, на UID и прочая и прочая, это уже мелочи.

Главное как я сказал, похожая концепция уже есть, она уже работает, она понятна и логична.

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

У сокета от файла – только путь, на диске он не хранится. Путь (имя) нужен только чтобы два процесса смогли найти общий канал передачи данных. Тогда уж «всё есть файл» надо переформулировать «всё адресуется как файл».

Пример ТСа с докбаром был бы хорош, будь он релевантен. Там персистентная конфигурация, и добавление файлов в условный config.d во всех смыслах проще, удобнее и надёжнее, чем правка общего конфига. И для людей, и для пакетных менеджеров. Поэтому для конфигов в линуксе используется повсеместно:

# find /etc -name '*.d' -type d 2>/dev/null | wc -l
112
[a1 ~]# find /etc -name '*.d' -type d 2>/dev/null | grep -vF /etc/s6 | wc -l
57

(И это я ещё не вспомнил про /usr/share/applications, ~/.idesktop, и наверняка про многое другое.) Но это не значит, что эту идею надо присобачивать повсюду.

Даже по поводу /proc есть у меня сомнения, не шило ли это на мыло: добавить файл (linux-way) vs добавить системный вызов или поле в структуре (windows-way). Вызовы-то побыстрее будут: один syscall против трёх: open + read/write + close. Разве что в /proc можно сделать иерархию каталогов, а в сях (в отличие от плюсей) нету namespaces, ну дык это претензия к сям. Получается, отсутствие в языке средств структурирования имён как фактор выбора неэффективного решения. Ещё и числа все в текстовом виде передаются…

Гы, а почему чел с ником windows10 топит за linux-way?

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

в задаче прямой передачи данных между двумя процессами, файл – лишняя сущность-посредник

Не уверен что в задаче «область уведомления» есть какие то необычные данные.

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

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

в окне с заведомым именем или классом

Во-первых, convention over configuration – злое зло.

Во-вторых, а если я хочу из приложения две иконки нарисовать?

А в-третьих, я перестал понимать, ты говоришь о пользовательском (т.е. доступном прикладному программисту) API, или о том, как оно внутри реализовано? Если мне дадут удобную функцию addSystrayIcon(), мне будет насрать, как оно там внутри с x-сервером коммуницирует – файлы, dbus или что ещё. Не нравится тебе нынешний dbus api? Нарисуй к нему фасад.

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

У сокета от файла – только путь, на диске он не хранится. Путь (имя) нужен только чтобы два процесса смогли найти общий канал передачи данных. Тогда уж «всё есть файл» надо переформулировать «всё адресуется как файл».

В тот то и дело, что под файлом и понимается абстракция/интерфейс не обязательно представляющая данные на диске. UNIX-socket есть файл.

Даже по поводу /proc есть у меня сомнения, не шило ли это на мыло: добавить файл vs добавить системный вызов или поле в структуре. Вызовы-то побыстрее будут: один syscall против трёх: open + read/write + close. Разве что в /proc можно сделать иерархию каталогов, а в сях (в отличие от плюсей) нету namespaces, ну дык это претензия к сям. Получается, отсутствие в языке средств структурирования имён как фактор выбора неэффективного решения.

Фундаментальная разница в том, что ядро не должно знать про иксы. И это успешно реализовали.

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

Фундаментальная разница в том, что ядро не должно знать про иксы.

Да при чём тут иксы. Я про идею /proc как таковую: помойка виртуальных файлов вместо помойки системных вызовов.

// То, что ТС предлагал общаться с иксами через ядерную ФС, – это разумеется настолько дикая дичь, что я её сразу оставил за скобками. В конце концов, может имелась в виду возможность создания собственной виртуальной ФС.

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

Первый протокол систрея (на x11) был правильным. Он позволял систрею и приложению общаться через x11 сервер. Это важно, когда систрей и приложение запущены на разных хостах. Например систрей на том же хосте, что и x11 сервер, а приложение — на другом хосте по ssh x11 forwarding.

Второй протокол на dbus такую возможность убил.

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

Во-первых, convention over configuration – злое зло.

Это почему ?

Во-вторых, а если я хочу из приложения две иконки нарисовать?

Хоть десять. У тебя условный gtk_container_add, им ты можешь добавлять что угодно вкуда угодно, лишь бы у этого вкуда был идентификатор. И тогда ты сам себе определяешь меню, реакцию на него, сам рисуешь свою иконку и обрабатываешь события. Ну а приложению трея останется лишь чистить мусор :)

А в-третьих, я перестал понимать, ты говоришь о пользовательском (т.е. доступном прикладному программисту) API, или о том, как оно внутри реализовано?

Как внутри.

Как по мне, концепция «оба приложения общаются друг другом через установленное соединение сквозь посредник» избыточнее концепции «хотящее в трей приложение кладет себя в папку, хотящие вывести трей приложения читают папку» :)

Нарисуй к нему фасад

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

Introspect:

<method name="GetAll">
<arg type="s" name="interface_name" direction="in"/>
<arg type="a{sv}" name="properties" direction="out"/>
</method>

Окей, получили метод GetAll, вызываем. Ответ: Error: No such interface “”. Каааак? Ты же только что мне вывел что он у меня есть. Это кстати пример как работает реализация SNI. И вот уже чтобы мне побороть эти костыли, мне нужно писать свой костыль. За таймаут 25 с я чуть позже расскажу =)

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

Первый протокол систрея (на x11) был правильным. Он позволял систрею и приложению общаться через x11 сервер. Это важно, когда систрей и приложение запущены на разных хостах. Например систрей на том же хосте, что и x11 сервер, а приложение — на другом хосте по ssh x11 forwarding.

Сначала стоит выяснить, сколько людей из тысячи опрошенных в твоем городе, запускают систрей и приложение на разных хостах. Мне кажется что это совсем нелогично добавлять код, который будет занимать место у всех, а работать у 1%.

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

Во-первых, convention over configuration – злое зло.

Это почему ?

Потому что не контролируется компилятором. В т.ч. никаких подсказок от IDE в процессе написания кода, никакого битья по рукам если что не так. Т.е. нужно дохрена помнить самому. И если convention вдруг поменяется, ты узнаешь об этом только когда твоя программа рухнет.

Как по мне, концепция «оба приложения общаются друг другом через установленное соединение сквозь посредник»

Где в сокете посредник? Ядро, передающее данные от отправителя к получателю? Гы, а файлы создаются сами, без ядра, святым духом?

избыточнее концепции «хотящее в трей приложение помечает кладет себя в папку, хотящие вывести трей приложения читают папку» :)

Как часто читает папку, чтобы вывести? Или мы теперь ещё и inotify(7) должны заюзать, чтобы ядро нас уведомляло сразу же как только кто-то запишет файл? По сравнению с тупой передачей данный между процессами, тут лишних движений на порядок-другой больше – и в приложении, и в ядре (не забываем про количество syscall-ов).

реализация шины нелогичная и непонятная с кучей шелухи

Выше я про обычный сокет с кастомным протоколом (или например, как чуть выше написали, с тем же x11). В dbus я пару раз пытался вгрызться – и плюнул. Дикая дичь. Мне не нужно было с чужим софтом коммуницировать, а сам с собой я и попроще могу договориться. %-)

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

dbus может сам по сети работать. При корректной настройке можно и трей увидеть и другие нотификации получать.

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

Сначала стоит выяснить, сколько людей

X11 это изначально клиент-серверная архитектура, можешь успокоиться и ни кого не спрашивать))

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

Да при чём тут иксы. Я про идею /proc как таковую: помойка виртуальных файлов вместо помойки системных вызовов.

Аа. Ну мне идея /proc нравится. То что ее превратили в помойку это уже другой вопрос. Системные вызовы это самый низкоуровневый интерфейс недоступный простому пользователю. А использовать /proc с помощью стандартных инструментов для работы с файлами это круто и удобно.

urxvt ★★★★★
()

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

то что даже ты можешь что-то там ПоЦ-нуть (т.е. PoC сделать) за вечер под пивас - не является хоть каким-то аргументом.

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

Ведь это снижает порог входа тех кто знает ЧТО писать, но не знает КАК.

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

Я не то что бы нубас в системном программировании, в прошлом под ДОС даже многозадачные оболочки писал на пассале, но и не гуру, тем более не гуру красноглазия.

тоже когда-то в качестве пранка над одноклассниками на турбопаскале написал оболочку 1 в 1 имитирующую редактор паскалевского кода. наверно все так делали.

Ну вот что мешало приложению создать в своем пространстве запись «/proc/PID/i_want_to_be_trayed», «/proc/PID/my_tray_icon», и «/proc/PID/tray_menu», куда можно сделать «echo activate > /proc/PID/tray_menu» или echo «contextmenu» > /proc/PID/tray_menu ? Соответственно приложение которое хочет в трей - создает у себя в пространстве запись, а приложение которое хочет прочитать треевые приложения - просто пробегается в поиске «i_want_to_be_trayed»? И все! Все чтения изменений через простой inotify.

т.е. ты и с деревом файлов толком ни разу не работал? inotify хорош если надо следить за каким-то конкретным одним файликом, про который четко известно где он лежит по абсолютному пути, типа несерьезно приглядывать за неочень нужным файликом и то там куча подводных камне по пути (в частности просер череды быстронаступающих евентов, они склокиваются в один последний и тому подобное и еще куча приколов и интересностей тебя ожидают, как только начнешь им пользоваться плотно). а ты вдобавок еще хочешь за развесистыми древовидными структурами следить, которые будут генерить очень много лишнего шума. и самое главное что до тебя не доходит, что для более-менее эффективной реализации это барахла тебе придется где-то создать копию состояния дерева /proc и тщательно сдедить за ней, чтобы воссоздать полную актуальную копию в твоих недоделках, не пропуская ни одного события во всем поддереве, чтобы потом в самом конце нацелить inotify на очень редкие файлики.

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

хочешь угадаю, какая твоя профессия. повар?

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

Очевидное решение: включить трей в ядро. На ПХП. А чем трей хуже systemd? И вообще, пусть будет systemd-trayd!

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

Впрочем проблема не в иксах. Проблема в том, что создавая реализацию стандарта - выбрали самую всратую и неочевидную, о чем и пост.

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

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

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

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

А использовать /proc с помощью стандартных инструментов для работы с файлами это круто и удобно.

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

А для питона какого-нибудь кто-нибудь обязательно запилит байндинги ко всем системным вызовам. После PyQt5 я ничему не удивляюсь.

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

Не помню точно, но в какой-то из BSD систем нет proc-fs.

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

Free мне сильно сложней и больше показалась. Достаточно сравнить объем вывода `sysctl -a` не обех системах. Комбинация /etc + /usr/local/etc вообще мне показалось очень сложной. И, что совсем неожиданно, на Open заработали из коробки и иксы и хибернация. На Free проблемы с видео (возможно, нужно что-то подкрутить еще), которые иногда приводят к зависанию.

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

У «непингвинятников»

Так в винде трей рисует вообще explorer.exe, который как бы проводник/файловый менеджер. Все ок? Нет оверинжиниринга?

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

/proc/PID/i_want_to_be_trayed

Не. Лучше в виде отдельного, уникального системного вызова сделать. И трей в ядре, конечно же!

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

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

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

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

Нет. У них немного разная парадигма изначально, и она правильна\удобна.

Нахрена мне например индикатор раскладки или звуковой регулятор в таскбаре? Зачем мне там торрент-трекер?

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

Ты предлагаешь достать еще две больших папки, на которых большими буквами будет написано «Баня» и «Строитель», а внутри на одном из сотни листов будет дописано «Вечером» и «000-123-456-78, Вася»?

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

Я - сторонник стикеров.

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

И кстати, не факт, что в трее не должна отображаться иконка какого-нибудь mpd, запущенного от пользователя audio.

MPD знать не знает, да и не должен, ни о каких иксах :)

skiminok1986 ★★★★★
()

Ну вот почему пингвинятники вечно идут каким-то своим

То не настоящие пингвинятники, то неверные, которые отрицают юникс-вей. Тут толпы таких же.

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

В линуксах нет трея. Его давно выпилили и заменили на апплеты.

Конечно же есть.

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

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

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

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

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

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

А. Удобство в использовании, в чем же еще.

Люди тратят время на написание велосипедов, когда пишут прикладные программы, и видят, что существующее решение - тоже велосипед, просто с квадратными колесами и на костылях.

Вот касательно примера из сабжа: стандартная реализация трея на С занимает более двух тысяч строк суммарно. Ну или полторы тысячи если в ее современном варианте - с привязкой к d-bus. При этом код не может быть интегрирован в другой код, да и сам по себе занимает несколько файлов не считая Makefile.

То есть нарисовать иконки, отловить нажатие и передать программе команду на действие - более тысячи строк? И после этого мы удивляемся, почему ДЕ такие жирные?

А ведь жирнеет не только ДЕ, жирнеет и прикладная программа, которая вместо того чтобы создать полтора файла в виртуальной и не очень ФС и держать палец на одном из них - создает целый комбайн нигде не описанных технологий (спецификация freedesktop это один сплошной лол - «function DrawIcon - drawing icon», вау, как емко), в свою очередь юзает другие технологии, которые кстати говоря тоже занимают место. Программа, юзающая вызовы ГТК, которые юзают вызовы Иксов - занимает меньше места, чем программа, юзающая вызовы ГТК, которые юзают вызовы Иксов, и юзающая вызовы Иксов.

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

Я вообще не очень понимаю, зачем люди тратят время на написание своих велосипедов

Я вот пишу велосипеды, просто потому, что мне нравится изучать на практике велосипедостроение и анатомию велосипедов. Видимо в конструкторы до сих пор не наигрался…

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

Потому что они нихрена не инженеры, а макаки наркоманы, сидящие все на тяжёлых наркотиках, включая Линуса, хоть он так называл других. Хотелось бы думать, что это только беда какого-то одного сообщества, скажем того же Gnome с их gobject & bonobo, потом gobject & gjs & gnome-shell, но увы, эта беда во всех компаниях. Инжеренеров мало, и тех постоянно куда-то сливают. Вон тот же андроид за свою короткую жизнь наплодил уже такой ворох слоёв, что скоро просто девелоперов это осиливающих не останется:) Про венду и говорить нечего.

И порог входа снижается везде. Вот казалось бы ну есть тот же Qt, возьми да пиши на нём. Ну вот брали мы не раз и писали. А что происходит, когда что-то ломается, скажем на том же ведроиде? Сидишь и копаешься во всех этих говнах. И этому нет конца.

ixrws ★★★
()

Если «всё есть файл», зачем вообще трей? Достаточно cat.

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

Ты серьёзно это? Надеюсь нет.

Файл просто устоявшееся абстракция, как последний лепесток в иерархии. В действительности надо правильно понимать, что это просто путь к некоторой сущности и единый api для работы с такими сущностями. Меньше сисколов, чем если один процесс создаёт named pipes, а другой использует их - быть не может. Плюс минус такое же количество сисколов будет с просто файлами или unix сокетами и тд. А главное, что это единый API, который плюс минус единообразный на разных платформах.

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

В сях удобнее один вызов, чем файл читать.

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

А если конструкций несколько, и они не связаны между собой ? Ну вот например если XWindow возвращает один идентификатор, а GTKWindow(QtWindow) другой, и они между собой несовместимы ? Способ только один, называется «трансляция» (или «проксирование»), и его собственно файлы и реализовывают.

Да я тебе больше скажу, изучая d-bus, я вижу насколько конченная его архитектура.

Вместо предоставления всего пространства единой файловой иерархией типа /org/kde/StatusNotifier/methods/activate, который можно будет дернуть как вызовом, так и echo "1" > /run/dbus/session/org/kde/StatusNotifier/methods/activate - мы наплодили зоопарк точек и слешей, методов и интерфейсов, свойств, интроспектов в XML формате и прочей ерунды.

Чтобы получить например доступные методы - надо делать кучу лишних телодвижений, вместо того чтоб просто сделать ls /org/kde/StatusNotifier/methods/

sysfs удобна ? Удобна. Почему такое не сделать для программ - я хз.

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

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

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

Для GNU/Linux или вообще?

  • Видеоредактор, в котором есть bilateral filter
  • Сторонний telegram-клиент
  • Красивые юзерстили для ЛОР
  • Программа для скачивания с яндекс музыки по типу yt-dlp
  • Плагин для QMMP для яндекс музыки
  • Программа для прослушивания интернет-радио, в которой нет багов
  • Мультитран
  • Плагин для Sylpheed чтобы был IDLE
  • Редактор схем баз данных, в котором можно Скопировать столбцы из одной таблицы в другую
  • Пасьянс «Тройка»

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

damix9 ★★★
()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)