| 19 Nov 2023 |
 Vika (she/her) | How do I go about debugging why does Nautilus, when launched from a terminal, allows to properly open files in respective applications from ~/.config/mimeapps.list, but refuses to do so when launched via GIO mechanisms (e.g. gtk-launch and other invocations of g_app_info_launch{_*} functions, such as wofi?
| 16:32:21 |
| Vika (she/her) | * How do I go about debugging why does Nautilus, when launched from a terminal, allows to properly open files in respective applications from ~/.config/mimeapps.list, but refuses to do so when launched via GIO mechanisms (e.g. gtk-launch and other invocations of g_app_info_launch{_*} functions, such as wofi)?
| 16:32:47 |
| Vika (she/her) | It doesn't seem to show any .desktop file not having an absolute Exec= path, which only two of my applications in /run/current-system/sw/share/applications seem to have.
| 16:33:22 |
| Vika (she/her) | This problem doesn't seem to be Nautilus-specific, which makes me thing it's something GIO related. But then Telegram Desktop, a Qt app, refuses to open links in Firefox if launched via wofi?... which is weird, unless Qt somehow uses GLib stuff?...
| 16:39:23 |
| Vika (she/her) | It's all so confusing and so annoying. | 16:39:40 |
| Vika (she/her) | ok, the gtk app chooser widget seems to be one thing responsible for collecting .desktop files in Nautilus's case, let's see what it calls to get a list of .desktop files
| 16:48:56 |
 Jan Tojnar | Vika (she/her): I would guess it has something to do with XDG_DATA_DIRS environment variable | 16:50:42 |
| Jan Tojnar | compare strings /proc/$pid/environ of Nautilus being launched by the different methods | 16:51:21 |
| Jan Tojnar | * compare strings /proc/$pid/environ of Nautilus launched by the two different methods | 16:52:19 |
| Vika (she/her) | Jan Tojnar That was my first thought! But... XDG_DATA_DIRS is almost the same between launching anything from wofi and my terminal, and both entries include /run/current-system/sw/share at the end, as they should.
| 16:54:26 |
| Vika (she/her) | In fact, almost the entire environment is the same! Sans a few variables GIO sets when launching an application using g_app_info_launch.
| 16:55:06 |
| Vika (she/her) | Specifically, these variables are XDG_ACTIVATION_TOKEN, GIO_LAUNCHED_DESKTOP_FILE{,_PID}, DESKTOP_STARTUP_ID and some minor variables like GPG_TTY (surely they don't affect this?). PATH is sometimes a bit different, but it's because of prefixes — the end is always /run/current-system/sw/share as expected.
| 16:57:49 |
| Jan Tojnar | Vika (she/her): I would try running it in terminal with XDG_DATA_DIRS=/run/current-system/sw/share and maybe some other variables cleared | 17:01:30 |
| Vika (she/her) | ...wait a second. | 17:10:27 |
| Vika (she/her) | Why does specifically Nautilus have its PATH reset only when launching via GIO?
| 17:10:41 |
| Vika (she/her) | This might be a systemd/d-bus thing. | 17:11:07 |
| Vika (she/her) | ok new theory: something resets/doesn't properly export PATH and anything started via D-Bus (and therefore anything launched via GIO) doesn't have its PATH set.
| 17:12:37 |
| Vika (she/her) | aha. dbus-update-activation-environment PATH does the trick. Looks like I forgot to call it in my sway session script.
| 17:18:38 |
| Vika (she/her) | i'm really stupid sometimes. | 17:18:46 |
|  pbsds changed their display name from pbsds (federation borken, may not see reply) to pbsds. | 20:38:54 |
| 20 Nov 2023 |
 piegames | Gnome extensions should be good to go now | 10:00:55 |
 @ThorHop:matrix.org | ElvishJerricco Since you asked in "Off Topic", I decided to try out a few GNOME extensions that replicate the window stacking effects that are found in Windows. Ended up settling for one directly inspired by it. I like this one because like in windows Win+Left and Win+Up will put one window on 1/4th of the screen. You can add other columns and rows, but I like this standard. Hope this helps! -> https://github.com/fmstrat/wintile | 15:26:44 |
|  @iromanyshyn:matrix.org left the room. | 17:29:26 |
 hpfr | because of https://github.com/nix-community/home-manager/issues/1011, I know GNOME Wayland doesn’t source ~/.profile. but I can tell that /etc/profile is sourced at some point because Alt+F2 printenv shows things it sets. I have looked through NixOS modules quite a bit but I can’t seem to find where a bash login shell is spawned under my user. does GDM do this? | 18:58:10 |
| hpfr | * because of https://github.com/nix-community/home-manager/issues/1011, I know GNOME Wayland doesn’t source ~/.profile. but I can tell that /etc/profile is sourced at some point because `Alt+F2 printenv` shows things it sets. I have looked through NixOS modules quite a bit but I can’t seem to find where a bash login shell is spawned under my user. does GDM do this? | 18:58:45 |
| hpfr | * because of https://github.com/nix-community/home-manager/issues/1011, I know GNOME Wayland doesn’t source ~/.profile. but I can tell that /etc/profile is sourced at some point because Alt+F2 printenv shows things it sets. I have looked through NixOS modules quite a bit but I can’t seem to find where a bash login shell is spawned under my user. does GDM do this? | 19:00:10 |
| hpfr | from what I am reading upstream gnome Wayland doesn’t source /etc/profile either, which makes sense, but on my nixos machine it sure seems like something is sourcing it | 19:06:16 |
| hpfr | and since this workaround works it must be run as my user https://github.com/nix-community/home-manager/issues/1011#issuecomment-606869802 | 19:07:01 |
 uep | add a line in there to dump something like pstree to a tmpfile each time it's run? | 21:25:30 |
|  @git_lit_mit_ohne_dir:matrix.org joined the room. | 21:37:29 |
