Hello, ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, September 27th, 2021 at 5:23 PM, Liliana Marie Prikler wrote: > Hi, > > Am Montag, den 27.09.2021, 19:04 +0000 schrieb John Kehayias: > > > [...] > > > > But back to the matter at hand. Medium to long-term I support better > > Guix services for autostart, but that doesn't address the problem of > > having packages run as intended by upstream, at least with reasonable > > expectations. I think this is expected and reasonable behavior, that > > a program can create a proper .desktop file in Guix. > > Unless you are running a dedicated desktop file/autostart editor like > alacarte or whatever gnome-tweaks has going for it, writing to > .config/autostart is not reasonable behaviour. > Sorry, I don't understand this comment. I think this is just the XDG specification, user autorun desktop files go in ~/.config/autostart. If a program wants to autostart (e.g. user enables the option) this I think is the expected and conformant behavior. I see many programs doing this (and is where you'd write if you want to change the per-user behavior of something in the system autostart, which might also be relevant). Anyway, we are getting sidetracked and that's not important for the matter at hand, I don't think. > > Looking at another non-Guix system, the autostart files I have > > in ~/.confg/autostart mostly (syncthing-gtk being the main > > exception) use just > > > > Exec=program-name > > The "full path" desktop files used in Guix do have some advantages. > Also, on other distros when using stuff like systemd in a similar > manner to shepherd, you have full paths again. > > > I see this mostly true for /etc/xdg/autostart as well (non-Guix > > system). So I think this is an easy and typical behavior we can > > implement. In this case patching syncthing-gtk to produce > > Exec=syncthing-gtk. Perhaps upstream would consider it as well, > > unless they have good reason for a full path here, as opposed to > > other programs. (Upstream is a bit quiet in activity though.) > > > > What do we think? > > I think upstream as good reasons to use full paths, e.g. to prevent the > wrong syncthing from being used when there are two in /usr and > /usr/local. Were Guix to police upstream on this matter, the decision > would clearly be to make this feature optional at the click of a button > – and not one that annoyingly pops up if Icecat is not your default > browser, if you understand what I'm trying to say. > So then I think we end up wanting to patch syncthing-gtk to create something like Exec=/path/to/profile/bin/syncthing-gtk I'm not sure off the top of my head how to do that (without ending up as it currently does with the direct /gnu/store/.../.syncthing-gtk-real since that is what the program will see as the origin of the process). I can take a look if no one has the Python incantation ready. Or else default to using $PATH and/or which; probably the right thing most of the time but I'm not sure. John