Hello Florian, "pelzflorian (Florian Pelz)" writes: > Arnaud Daby-Seesaram writes: >> "pelzflorian (Florian Pelz)" writes: >>> Perhaps for more hackability, we could deviate from upstream and put in >>> a call to guile with a Scheme script in a computed-file that opens a >>> pipe to/from wmenu and does the same as dmenu_path without cache only on >>> ~/.guix-home/profile/bin. >> >> Yes indeed. Do you think that the Guile script should replace all of >> "$menu", or just the dmenu_path part? >> > > All of "$menu", because it looks nicer? But I should not imply that > such deviation from upstream were necessary for getting your patch in. No worries. I think that finding a better solution now would be better (and should not delay this issue for too long). It would avoid opening a second issue and delaying/forgetting the cache problem. > Basically my issue was that dmenu_path did not work. > > Indeed stest is part of the dmenu package, so when dmenu is installed to > the profile, dmenu_path would work. So a more upstream conformant > solution would be to just add the dmenu package to sway’s packages. > > However, dmenu_path’s cache means that if we used dmenu_path like > upstream, it would never recognize changes to the installed packages. > OpenBSD opted for wmenu_path which is like dmenu_path without cache > and a guile script seems more appropriate for Guix’ defaults. Yes, adding dmenu would work (minus your second point). However, to rely on both wmenu and dmenu feels a little weird, especially since the latter is only used for a bash script. It seems that Sway recently switched[1] to a utility called wmenu-run (C program shipped with the last version of wmenu) to get rid of their dependency on dmenu. [1] https://github.com/swaywm/sway/commit/b44015578a3d53cdd9436850202d4405696c1f52 >>> only on ~/.guix-home/profile/bin. >> >> What is the rationale for restricting the menu to this directory (and >> not all directories in >> (filter directory-exists? (string-split (getenv "PATH") #\:)) >> ? >> > All my graphical applications are in the home profile and non-graphical > programs will not be used and clutter wmenu. Do others put graphical > apps in the system profile? Perhaps so. But then non-graphical > coreutils would be in the wmenu as well. Hmm I am not sure and would be > fine with either. Yes, this is a good point. I also agree that using a single script for all of the menu would make it clearer and more maintainable. For both these reasons, here is a draft proposal for a script that could replace the current content of "$menu". As suggested, it uses `scandir' and only focuses on packages of the "home profile". --8<---------------cut here---------------start------------->8--- (define sway-menu (computed-file "sway-menu.scm" #~(begin (use-modules (ice-9 receive) (ice-9 rdelim) (ice-9 ftw) (guix build utils)) (define (directory->files dir) (define (executable-file? f) ;; Cf. `(@@ (guix build utils) executable-file?)' for an ;; explanation of `(zero? ...)'. (and=> (stat f) (lambda (s) (not (or (zero? (logand (stat:mode s) #o100)) (eq? (stat:type s) 'directory)))))) (with-directory-excursion dir (scandir "." executable-file?))) (let ((path (string-append (getenv "HOME") "/.guix-home/profile/bin")) (wmenu #$(file-append wmenu "/bin/wmenu")) (swaymsg #$(file-append sway "/bin/swaymsg"))) (receive (from to pid) ((@@ (ice-9 popen) open-process) OPEN_BOTH wmenu) (for-each (lambda (c) (format to "~a~%" c)) (directory->files path)) (close to) (let ((choice (read-line from))) (close from) (waitpid pid) (execl swaymsg swaymsg "exec" (string-append path "/" choice)))))))) --8<---------------cut here---------------end--------------->8--- WDYT? Best regards, -- Arnaud