<mkg20001>
I'm thinking there could be some kind of "desktop common" module that DEs could import which would include all services that are essential - not sure about KDE, might also be a "GNOME-common" module
<mkg20001>
That would help devs like me, because now with cinnamon I've got to keep track of changes there, with such a module I wouldn't have to worry, even when building custom stuff
<mkg20001>
stuff like gvfs, nm-applet, basic fontconfig, etc seems pretty common
<worldofpeace>
mkg20001: I think some of the things in the gnome module were restructured like this, like core-os-services.
<worldofpeace>
but it seems not everything is homogeneous like this
<mkg20001>
Hrm.. core-os-services doesn't seem to be used by pantheon. What I was thinking was most GNOME drvs use the same stuff, nm-applet, gvfs, etc by default.
<worldofpeace>
yeah, we thought for a second that maybe pantheon could share this. but pantheon doesn't really follow gnome that closely (because it isn't gnome)
<mkg20001>
ok
<worldofpeace>
it sounds like you saying something like "requiring" a runtime. I think it would be cool if a package could define what dbus services etc. it needs at runtime
<mkg20001>
that would be really cool
<mkg20001>
prob a game changer
<worldofpeace>
I think that's something Jan Tojnar and I talked about. It would make things feel a lot more solid than me just inferring stuff and activating the proper config for x program. or having a module for some programs and not others.
<mkg20001>
and the few exceptions that need to be handled could be somehow handled internally, so that the right stuff is in share without the user having to do anything
<samueldr>
ideally the same software should run in non-nixos, or even nixos, through nix-shell -p
<samueldr>
nix-shell won't go through the modules system
<worldofpeace>
so basically nix will inherit features from flatpak 🤣
<mkg20001>
<samueldr "ideally the same software should"> stuff gets problematic when there's something that needs system access running via nix-shell in userspace, making that possible would be kindof breaking security... that makes it more complicated
<samueldr>
oh, I know
<samueldr>
I'm just saying that it's a hard problem
<samueldr>
pointing out an issue to know about
<mkg20001>
I've copied the pantheon DE config to cinnamon and adjusted stuff, the overrides still won't get picked up EVEN THOUGH the .gschema.override file is in $NIX_GSETTINGS and mint-artwork.gschema.override exists
<jtojnar>
did you add the package itself?
<mkg20001>
what do you mean package itself? the schemas or the mint-artworkj?
<mkg20001>
I've now tested it with both, none seem to work
<jtojnar>
the package containing the schema you are overriding needs to go to extraGSettingsOverridePackages
<mkg20001>
It's there
<mkg20001>
so it's clearly there
<mkg20001>
also $NIX_GSETTINGS..../mint-artwork.gschema.override exist in the VM
<mkg20001>
unless there's some other extraGSettingsOverridePackages aside from the DE option..
<worldofpeace>
we actually have a very similar wallpaper (just black and white) that's used for gnome and etc.
<mkg20001>
so I should just use the gnome one then?
<worldofpeace>
yep
<worldofpeace>
It would make a lot more sense if cinnamon shipped a cinnamon-distro-settings with an agnostic configuration and then it could be configured for their linux mint. alas we're using mint-artwork
<worldofpeace>
so in licenses.nix it will be marked `unfree = true`. So any error in that needs to be purposed in a separate PR so someone can review it carefully
<mkg20001>
I can also possibly use the nixOS logo, depends which one looks more harmonic
<mkg20001>
also the artwork features settings for lightDM - should those get applied when DE is enabled or not?
<worldofpeace>
mkg20001: you mean etc/lightdm/lightdm-gtk-greeter.conf.d?
<mkg20001>
that's also there? I found something in mint-artwork.gschema.override
<worldofpeace>
I believe those are settings for lightdm-gtk-greeter, and I think cinnamon actually uses their slick-greeter. I'd think those should be enabled if lightdm-gtk-greeter and cinnamon are enabled
<worldofpeace>
mkg20001: which key? I only saw it for slick-greeter
<mkg20001>
x.dm.slick-greeter
<mkg20001>
at the top
<mkg20001>
so mkIf lightdm & cinnamon then apply etc/lightdm/lightdm-gtk-greeter.conf.d/99_linuxmint.conf
<mkg20001>
?
<worldofpeace>
I believe so, but it's lightdm-gtk-greeter, not just lightdm
<worldofpeace>
it has nm-applet as a required component
<worldofpeace>
because of this it needs to start nm-applet through the xdg autostart. meaning you can just have that in systemPackages and not use the nixos service
<mkg20001>
so nm-applet.enable should be removed?
<worldofpeace>
yes
<mkg20001>
Could use another round of review
<worldofpeace>
mkg20001: gotcha
<worldofpeace>
mkg20001: did cinnamon ever update to a newer spidermonkey in cjs?
<mkg20001>
not aware of it, last major bump just had something with "fixed one test"
<worldofpeace>
Jan Tojnar: do you remember the pr by romildo that changed stuff for icons majorly?
<worldofpeace>
mkg20001: okay, that's the next round of review
<hpfr>
lowly user here, I was wondering about interactions between the keyring and ssh-agent
<hpfr>
with NixOS's gnome setup the SSH_ASKPASS variable appears to be unset, despite `programs.ssh.askPassword` being set to the seahorse askpass program
<hpfr>
with `ssh-add -c test-key` (where the -c prompts for yes via SSH_ASKPASS every time the key is used), I enter the password in my terminal and the key is added to the agent
<hpfr>
but then `ssh-add -T test-key.pub` fails with "Agent signature failed for test-key.pub: agent refused operation" instead of bringing up the seahorse askpass for confirmation
<hpfr>
I believe this is because adding a key via `ssh-add` alone doesn't add it to Gnome's "passwords and keys" app (which I think is seahorse)
<hpfr>
because when I add a key in that app the confirmation works fine
<hpfr>
so I found a github issue and tried to disable the keyring in my config and just use the default ssh agent
<hpfr>
this is working as intended, but as you can see I had to manually add SSH_AUTH_SOCK and SSH_ASKPASS in home.sessionVariables, even though I think those should be set properly by `programs.ssh.startAgent` and `programs.seahorse.enable` which are true on my system
<hpfr>
also, these manual `home.sessionVariables` additions don't propagate outside of my terminal it seems, because keepassxc thinks the auth sock variable is unset. luckily it has an override option in its application settings, so everything is working now
<hpfr>
but I was wondering if there's a cleaner way to disable the keyring and use the bare ssh agent than setting these variables as I've done