Howdy :cool:,

I've tried making my own 66 service for Picom, since it regularly stops working and I thought doing this might fix it. So I followed the directions in the wiki, but I'm not too sure where I'm meant to actually place the file so that it can be added to a tree. I thought it might be ~/.66/service, but running $ 66-tree -t graphics -S picom didn't work.

This is the service file at the moment: 
[main]
@ type = !longrun
@ name = !picom
@ description = "X compositor that may fix tearing issues"
@ depends = !( hicolor-icon-theme libconfig libdbus
              libev libgl libx11 libxcb
              libxext pcre pixman xcb-util-image
              xcb-util-renderutil picom )
@ optsdepends = !( dbus python xorg-xprop xorg-xwininfo )
@ user = !( user )    # got a little confused here, wasn't sure if was literally meant to put "user" or my username

[start]
@ build = !auto
@ shebang = !"/usr/bin/picom"
@ execute = !( --experimental-backends )

[stop]
@ build = !auto
@ shebang = !"/usr/bin/killall"
@ execute = !( -q picom )
Huh!!
Are you sure to have read the frontend documentation page?

Well,
I thought it might be ~/.66/service
This is correct. The directory ~/.66/service will be checked before the directory /usr/lib/66/service. That's mean that for a same service name the one found at ~/.66/service will be pick.

A general error on your service frontend file:
the '!' exclamation mark is used to specify at 66 to not export key=value pair on the environment variable. It's only used (for the moment) at the [environment] section and have nothing to do with the keys @ <whatever_the_key> of the frontend file.

So,
- @ name: this key is only used with instantiated service on a very specific case. You shouldn't need to define it. The name of the frontend file will be pick as the name of the service.
- @ depends: we talk about service here not packages. This key is used to set dependencies between service. So, 66-enable will expect the name of an another service name.
- @ optsdepends: same thing. 66-enable expect a name of an another service. This key is used when you want a dependency with a service
if an only if the service is already present on your system.
- @ user: this key is used to specify which user has the permissions to use the service. So, yes you can put on user name but in this case only your user will be able to use this service. Or, you use the general name 'user' (as you do) to allow any valid regular user on your system to use this service.
- @ build: this field is no longer mandatory from the 0.4.0.1 version
- @ shebang: it's only used when you set @ build to custom

And it miss you the field @ version which is mandatory

So, your service file become
[main]
@ type = longrun
@ version = 0.0.1
@ description = "X compositor that may fix tearing issues"
@ user = ( user )
@ options = ( log ) # it's a good idea to have a logger

[start]
@ execute = ( picom --experimental-backends )

[stop]
@ execute = ( killall -q picom )
Personaly i use this one named ~./66/service/picom@ and i enable it with: 66-enable picom@ <name_of_my_user>. 
[main]
@ type = longrun
@ version = 0.1.0
@ description = "Picom daemon for transparency"
@ user = ( user )
@ options = ( log env )
@ extdepends = ( dbus-session@ @I )
@ down-signal = KILL

[start]
@ execute = ( execl-cmdline -s { picom ${cmd_args} } )

[environment]
cmd_args=!--log-level=DEBUG --show-all-xerrors
eric wrote
@ extdepends = ( dbus-session@ @I )
Why are there 2 @ @
eric wroteThat's mean
That means* :P
Thanks, that mostly worked. I was able to add and enable services to the trees I wanted, but there seems to be a bug any using cmd_args under the [environment] header. The last two characters seem to get repeated. As in 
...
[environment]
cmd_args=!--experimental-backends --log-level=DEBUG --show-all-xerrors
becoming 
picom: unrecognized option '--show-all-xerrorsrs'

in the logfile. This same bug occurs for my unclutter and mpd services, but the dwmblocks service runs without issue (the only differences being the lack of a cmd_args variable in dwmblocks@ )
Everything works fine if I remove the environment section and env from the options (placing the arguments in the execute part directly), the bug only happens with them there.
@ magicalsenpai
hum, maybe you hit a bug here, i need to check what happens.

@ Mounerje
Appreciated, thanks

@ fungal_net
picom need dbus-session@ <user> to work properly. My personal picom@ is an instantiated service and so all @ I character onto the frontend file will be replaced by the name given at enable time (e.g 66-enable picom@ oblive, well you know that). So, at the end the dbus-session@ @ I become e.g. dbus-session@ oblive.

Powered by Obarun