I made a simple kio servicemenu addition for Dolphin, and it works just fine when I put it either ~/.local/share/kio/servicemenus/touch_file.desktop or /usr/share/kservices5/ServiceMenus/touch_file.desktop. As the name implies, it allows me to change a file’s timestamp (using the “touch” command").
Now, i’d like to be able to do the same in Gwenview, either while viewing a single file, or in browse mode. I tried adding a “servicemenus” directory under ~/.local/gwenview (it didn’t exist by default) and copying the .desktop file in there, but it doesn’t seem to work. Is there some documentation about this? Can it be done in the same way as for Dolphin, or is this a development task?
I doubt you can add it as a servicemenu. I’m not sure what exactly your desktop file does and how it works but I added some functionality to gwenview in terms of “set as wallpaper” ( which is lacking in Gwenview for some reason). But that is a desktop application I made in ~/.local/share/applications and uses a script. If you can use the touch command, either as a script or as direct exec in the desktop file, you can use it in Gwenview in “open with”.
Example with the wallpaper thingie.
@dzon Thanks for the quick reply! I like the alternative approach via “open with” for Gwenview. I was just hoping that KDE would have standardized all this by now, but there’s more important things to do.
My little .desktop file is as as follows…
#Place in ~/.local/share/kio/servicemenus/touch_file.desktop or /usr/share/kservices5/ServiceMenus/touch_file.desktop
When placed in the correct directory, it adds a context menu item to Dolphin, as you can see in the attached screenshot…and that’s what I’d like for gwenview…
Like I said, you can make an app desktop file for it. Assuming that’s a working command, it would be something like in the screenshot. Make sure to make the file executable and add it to the programs, associations ( image) in system settings so that it pops up in Gwenview. No idea if that will work as far as the command goes, but you get the idea.
TouchStuff. What an idea to name it like that
any KDE app, that somehow supports / provides file (system) actions should have the ability to get exetended by service menus and that’s what the name implies. Gwenview does(!) allow the creation of directories and moving or renaming files, so it qualifies easily for the extensibilty as defined. actualy i would like to believe, that this was the original concept of service menus. a simple key in the desktop entry files filters the apps, that display a specific menu item, such as: Apps=dolphin;konquerer;gwenview;ark;
No, as servicemenus as such wouldn’t work depending on the app ( I’m thinking keyboard emulating commands with xdotool for example). However, what WOULD be a biiiiiig + is a customizable toolbar button. This has been on a wishlist for yeeears and at some point there was a git version of dolphin that allowed just that, adding custom made actions to the toolbar. There are many file managers that have that function ( nowadays thunar, always caja, nemo, pcmanfm-qt, krusader,sweet lord spacefm…). But this functionality shouldn’t be restricted to the file manager but implemented in any kde “core” app. Sure, you can add some to kate but…that’s about it.
Script? There’s no script involved here. I used the same command for the desktop application. Put it in ~/.local/share/applications. Make it executable. Afterwards go to system settings and add it to any file type you wanna use it with. Works both on thumbnails as main image in Gwenview.
Of course, if you want a more elaborate ( dunno, something which requires a yad or kdialog or whatever) thing which does require a script, point the exec to the script.
As an example:
That’s odd, I thought that the whole idea of service menus is to have a consistent way of invoking the same scripts in every kde application, at the very least ones as popular as gwenview. Gwenview has the same browse mode as okular, so I don’t see why service menus wouldn’t work here, is this just a bug?
Well, guess you thought wrong. There are mediaplayers that have browsing capabilities. Doesn’t mean they have service menus. Why would that be a bug? If you look at gtk fm’s like, O I dunno, most, you can add custom user actions to those if you want. Some use inbuilt shortcuts as exec,some link to scripts, some downright desktop application commandline options etc… That doesn’t mean you can add those to gtk image viewers. I don’t see why this , what you call “inconsistency” shouldn’t apply to kde? I don’t see why it’s the normal in every single non-DE or DE yet it’s considered a bug in kde.
Fair enough, I don’t have much experience with internals of KDE Frameworks, I just though that if mechanism like service menus exists it will work anywhere where context menus exist as OP initially posited. I don’t mind adding .desktop entry to open with dialog although it’s one more unnecessary click.
Actually I wish gwenview had a way to add actions independent of the rest of kde framework. Adding .desktop entry now for gwenview will make it show in all different places where they shouldn’t.
I could just use nsxiv, but it’s preview grid isnt as good as gwenview. I hope that custom script will become eventually available.
A service menu takes just as many clicks. And, you have a bunch of other image viewers that have a bunch of functions and gridview. And you don’t NEED to have a particular desktop app shown in ALL different places. Just add whatever you want to the application itself and access it by right clicking the task.
For example, Qimgv.
If you want to avoid one of those commands to show as an option ( if they even would) anywhere else you can always set the command to a simple bash script or simply have it ignored in system settings.
I was hoping for a single entry in context menu, or a shortcut ideally, but it’s not a huge deal.
And, you have a bunch of other image viewers that have a bunch of functions and gridview
thanks, I’ve completely missed that program. It seems really good, very agile, can pass it images on command line same way as to gwenview or nsxiv (I didn’t even try to pipe them on stdin as too few image viewers support it, so it’s fine), it seems to support custom scripts, which I still need to test. One minor problem is that it doesn’t let you zoom in as much as gwenview, it leaves a lot of empty space (but more than nsxiv, please see comparison below)
Custom scripts, large image previews (with antialiasing), pass image paths as arguments on command line, custom shortcuts, fast. Both qimgv and gwenview are 80-90% there, I think I just need to dive deeper into their configuration to get them to work with a specific use case (changing paths of selected images and passing them to another program). qimgv seems the best right now.
