autostart 0.1

У XDG есть хорошие инициативы, но конкретно вот эта клоунада с .desktop-файлами — полнейшая чушь и усложнение ради усложнения. Я ими не пользуюсь совсем, и очень рад. Да, у них есть одно достоинство: их никто прям уж активно не нгавязывает.

Гораздо проще и удобнее автозапускать приложения из конфига WM/композитора (это умеют все, известные мне), либо вообще из скрипта построчно. Без всяких desktop-файлов.

Если что, за проект в любом случае зачёт — кому-то, кто по каким-то причинам вынужден пользоваться этими desktop-файлами, или почему-то вдруг знает толк в извращениях и даже предпочитает их, это может быть вполне полезно. Не стоит воспринимать мой комментарий как критику в свой адрес или в адрес своего проекта. Я здесь критикую именно то, что в данном конкретном случае придумали в XDG.

может стоит выбрать белее уникальное название? например уже есть такое https://github.com/snail007/autostart

До появления XDG каждая DE реализовывала автозапуск по-своему. Гном, крыска, кеды имели свои конфиги и способы автозапуска, что создавало хаос в поддержке.

XDG создали единый стандарт. Любое DE, понимает одинаково. Это сдеалло кросс средовую поддержку приложений.

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

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

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

До появления XDG каждая DE реализовывала автозапуск по-своему. Гном, крыска, кеды имели свои конфиги и способы автозапуска, что создавало хаос в поддержке.

DE — это в принципе ущербная концепция.

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

Там нечего распространять. Юзер либо кладёт desktop-файлы в условленное место (зачастую, прописывая в них команды, вместо скриптов), либо прописывает команды запуска, нужные ему, в конфиг своего WM наряду с остальным. Второй подход на мой взгляд намного удобнее и проще, несмотря на то, что синтаксис не везде одинаков.

Не думаю, что требуется, в мире опенсорс таких решений очень мало

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

не все оконные менеджеры не умеют работать

Одна из «не» лишняя.

А зачем -std=c17 в makefile?

Чорт, где ты был пару недель назад, когда я ещё сидел на бспвме и городил костыльные скрипты автозапуска?

Потому, что проект будет развиваться, а учитывая что вводят новые стандарты что С что С++, есть шанс что по дефолту смахнут с std17 на что-то новее

Я надеюсь все же этот проект будет полезен?

.xinitrc

Даже не третий комментатор в теме про это написал. ЛОР уже не торт.

Уже нет, теперь использую cinnamon, однако если снова установлю bspwm обязательно воспользуюсь.

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

snprintf(path, MAX_PATH, "/etc/xdg/autostart.conf");

Ну зачем же так хардкодить пути, без возможности переоределения? К примеру, во фряхе директория xdg находится в /usr/local/etc.

Это будет переделываться, и добавляться возможность переопределения и вероятно порядка запуска, какой за каким

iron: Ну зачем же так хардкодить пути, без возможности переоределения?

ivanika: Это будет переделываться, и добавляться возможность переопределения и вероятно порядка запуска

надо реализовать свой конфиг, в котором как-раз это и будет, где какие конфиги лежат.

Больше конфигов, хороших и разных !

DE — это в принципе ущербная концепция.

Почему? Сам факт того, что большинство используют ДЕ говорит скорее в пользу обратного.

.xinitrc

Вот, кстати, да ivanika, почему не так, если речь идёт об оконных менеджерах? Или речь именно об оконных менеджерах, сессии с которыми стартуют из менеджеров сессий, которые игнорируют .xinitrc? Зачем отдельный автостарт в ВМ, «как в ДЕ»? Кто-то решит переехать с ДЕ на ВМ, а у него уже всё и запускается, что раньше запускалось? Кандидат на унификацию для ДЕ, чтобы не городили свое, а использовали одно общее решение?

Почему?

Потому что смысла в том, чтобы собирать кучу разного софта в бандл, а затем пытаться разрабатывать и распространять совместно, никакого. Это имеет смысл для Microsoft с их Office, и другими подобными — там понятно, таким образом они могут продать сразу несколько продуктов тем, кому нужен только один или два. Но в случае с опенсорсом это не требуется.

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

Сам факт того, что большинство используют ДЕ говорит скорее в пользу обратного.

Этот факт вообще ни о чём не говорит. Большинство вообще на десктопе винду использует.

Но в случае с опенсорсом это не требуется.

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

Но тут, возможно, это ломается с серьёзными изменениями в DE, не знаю - я на ДЕ не долго сидел, быстро на ВМ+подобранное окружение перешёл - было интересно в этом ковыряться.

Этот факт вообще ни о чём не говорит. Большинство вообще на десктопе винду использует.

Винду могут использовать вынужденно - например какой-то софт только в ней работает и т.д. С Линуксом такого нет (или, по крайней мере не было очень долгое время). Так что тут аргумент работает - есть куча дистрибутивов с кучей вариантов окружений, к выбору никто не принуждает. Но при этом многие свободно выбирают ДЕ.

DE — это в принципе ущербная концепция.

Ну вот, пошло-поехало! Зачем свои личные, крайне спорные, крайне субъективеые, не выдерживающие минимальной критики, аргументированные только «я художник, я так вижу» странные идеи, уровня психологических комплексов, сходу вываливать в тред о новой разработке в виде программы, которая даже не касается самих DE?

Вот просто по совести, зачем так делать?

Это будет переделываться, и добавляться возможность переопределения и вероятно порядка запуска, какой за каким

ИМХО, лучше закрепить порядок, что сначала системное, а потом - пользовательское. Это стандарт, этого ожидают, нет смысла делать иначе, и такая настройка будет лишней.

.xinitrc

а если это вяленая бадяга

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

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

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

имеются в виду .desktop файлы из .config/autostart

У меня там только то, что автозапускать не надо.

[Desktop Entry]
Hidden=true

А что надо в /etc/xfg/autostart

для такого пользуюсь uwsm. но программа может быть полезной для анализа того, что будет запускаться. есть режим «покажи, что будет запущено, но ничего не делать»?

не все оконные менеджеры умеют работать с автозапуском приложений

Не знаю таких WM, где нет соответствующего конфига. Зачем там дектоп-файлы для меня загадка. Кроме того, обычно добавляют параметры приложений, путь к нужному конфигу, ключи запуска и т.д. Пользователю придется создавать кастомный десктоп-файл, это двойная работа.

.xinitrc

xinitrc, xprofile, xsession, всё это от Иксов и запускает как попало.

Не знаю таких WM, где нет соответствующего конфига

но они есть

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

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

всё это от Иксов и запускает как попало.

ничто не мешает сделать xinitrc исполняемым и вызывать откуда угодно

назови композитор

я таких не знаю и всегда думал в любом de или wm обязательно свой автостарт есть - не совсем понимаю для чего вообще эта программа, очевидно для тех кто не хочет использовать встроеный автостарт… я там кстати интел ковыряю - вчера удалось его раскочегарить в иксах до 722 попугаев, но это смешно против 2400 на вяленом

прикол в том, что он его использует для запуска своего автостарта

прикол в том, что он его использует для запуска своего автостарта

могу только аплодировать - вы не поленились посмотреть что там у ТС и «вообще что в мире твориться» :-)

из серии «не читал но осуждаю», есть же классический путь : каталог а-ля .xinirc.d/ (или .authorname.d) в котором по алфавиту отдельные скрипты start|stop|restart|check всякой хрени, ведь не обязательно чтобы нечто всегда работало. Надо чтобы что-то запустилось при входе в сессию, и если сработало то другое при выходе.

на уровне sh и .xinitrc это не особо длинный скрипт. Или эпичный модуль systemd

Который раз захожу в трекер и читаю «астрал 0.1»…

У оконных менеджеров, по крайней мере популярных есть свои собственные механизмы для назначения автозапуска. У icewm, WindowMaker точно есть своё, вполне себе адекватное. У *Box (Flux-, Black-, Open-) тоже..

Конфиг есть.

Потому, что не умеет читать директории автостарта!

Потому, что не умеет читать директории автостарта!

А это надо в WM? Зачем, например, в i3 демон xfce4-settings (xfsettingsd)? В конфиге прописано только то, что необходимо.

я не единственный кому это понадобится. Поэтому собственно проект и появился

я не единственный кому это понадобится

Можно хоть какой-то сценарий? Допустим у вас fluxbox, у него есть файл ~/.fluxbox/startup, по сути аналог ~/.xinitrc, чтобы иметь собственный набор для автозапуска.

А какой сценарий нужен?!? Есть оконный менеджер, который не умеет запускать приложения из автозапуска, а вот надо чтобы они запускались!
Что fluxbox/startup, что xinitrc не умеют читать xdg директории автостарта

Есть оконный менеджер, который не умеет запускать приложения из автозапуска

А зачем в WM запускать desktop-файлы из автозапуска? Объясните.

Как тот же picom.desktop будет запускаться в xfce4 в i3 или в fluxbox? Мне наклепать три picom.desktop?

$ cat ~/.config/autostart/picom.desktop
[Desktop Entry]
Hidden=true

$ grep 'picom' ~/.config/i3/config
exec_always --no-startup-id picom --config ~/.config/picom/picom.conf &

$ grep 'picom' ~/.fluxbox/startup  
picom --config ~/.config/picom/blurred.conf &

Зачем нужен этот велосипед, если во всех дистрах давно есть dex (github.com) с поддержкой всего связанного с desktop entry?

Расскажите пожалуйста больше деталей про механизм запуска. Что именно запускает запускалку и с какого места (в процессе включения ПК) она стартует и когда начинает софт запускать.

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

Довольно много комментариев: а зачем это, а что делает, так есть же dex!
По порядку, проект уникален своей реализацией, мне очень интересно понять как работает автозапуск приложений, поэтому, собственно, и появился этот проект. Я не говорю бегите использовать, а лишь хочу услышать что было бы лучше добавить, ведь проект в своей нише востребован.
Что делает? Проект автоматически запускает приложения из директорий автозапуска. Запуск происходит на уровне оконного менеджера, нужно лишь добавить команду. Я знаю что есть dex, но его проблема в том что он не имеет централизованного конфигурационного файла, я же создаю проект с централизованным, дабы можно было что-то настроить, добавить ограничение, изменить задержку запуска и тп, и да, мой проект также переймет часть функционала из dex. Проект не задуман под массовое пользование, но в дальнейшем будет добавлен в aur или еще куда, после более менее эталонной реализации. Кому надо, тот найдет и воспользуется.
И не стоит расценивать ответ как критику и оскорбление в свой адрес, всем добра!

Файлы, зачастую, создаются самими приложениями по типу тг или discord, когда вы нажимаете startup with session. Сам запуск можно ограничить только для каких-то de, например, OnlyShowIn или же NotShowIn.
Почитайте Autostart Of Applications During Startup