Open tulth opened 2 years ago
I am interested in reactions to this idea and if there is a better way to go about it.
I am very happy with this in my setup. It is particularly useful for launching steam games.
Mh, doesn't work on my end; a .desktop file that's only in ~/.local/share/applications but not in any of the other directories will fail to be found
Arg! How strange. I introduced some broken desktop files and logging locally to double check the behavior on my end and I cannot seem to reproduce the issue yet.
logging diffs:
modified XMonad/Prompt/DotDesktop.hs
@@ -54,6 +54,8 @@ getDirContents dir = do
getDotDesktopApps :: IO [DotDesktopApp]
getDotDesktopApps = do
appFolders <- getAppFolders
+ appendFile "/home/tulth/.xmonad/debug.log" $
+ unlines $ ("appfolder: " ++ ) <$> appFolders
contentsPerFolder <- mapM getDirContents appFolders
let folderFiles = join $ rights contentsPerFolder
dotDesktopFiles = filter isDotDesktop folderFiles
@@ -63,6 +65,7 @@ getDotDesktopApps = do
let parseErrs = lefts parseResults
dotDesktopApps = rights parseResults
mapM_ print parseErrs
+ appendFile "/home/tulth/.xmonad/debug.log" $ unlines parseErrs
return dotDesktopApps
I thought perhaps a parse failure in a folder would cause a bigger problem, but that was no issue on my system. It give the expected result on my system and user and system desktops are listed, and the broken files i created show up. debug.log:
appfolder: /home/tulth/.local/share/applications
appfolder: /usr/share/applications
Parse Resulted in no KeyVals in file /home/tulth/.local/share/applications/broken_user.desktop
Parse Resulted in no KeyVals in file /usr/share/applications/broken_system.desktop
Any ideas? Is XDG_DATA_DIRS
is set or no? On my system XDG_DATA_DIRS
is not set and it picks up defaults.
Any ideas?
Sorry, I was referring to gtk-launch
in that comment, not your implementation
@tulth what do you think about the idea of using gtk-launch
instead? Semms like a standard tool that people will definitely have installed and would simplify this quite a bit
@tulth what do you think about the idea of using
gtk-launch
instead? Semms like a standard tool that people will definitely have installed and would simplify this quite a bit
I was thinking about this as well, but I do not think it makes much difference. The .desktop files still have to be parsed to find the names and the filter out only applications. The only thing it saves is filtering out the %X patterns.
I was thinking about this as well, but I do not think it makes much difference. The .desktop files still have to be parsed to find the names and the filter out only applications. The only thing it saves is filtering out the %X patterns.
I don't use desktop files, so forgive my ignorance here, but the man page for gtk-launch
says that it "launches an application using the given name". Does that mean there are .desktop
files for things that aren't executable programs? What would those be? Wouldn't gtk-launch
also ignore them or does it do other things as well?
I note that gtk-launch
also knows how to activate an already running application instead of just starting a new one. (Of course, starting a new one should also do that.) This does, however, imply that some .desktop
files may contain DBus activations instead of executables.
@tulth any updates?
@tulth friendly ping
Description
Add a prompt bar that can launch
.desktop
files.Example use
Checklist
[X] I've read CONTRIBUTING.md
[ ] I've considered how to best test these changes (property, unit, manually, ...) and concluded: XXX
[ ] I updated the
CHANGES.md
file