Bug 88932

What do you want that can't be done as a kipi-plugins?

Achim

> -- What do you want that can't be done as a kipi-plugins?

- export files from digiKam just by copying them to external dir
- use cdigi from inside digiKam

Just look at kde-apps to see what can be done with service menus.

Additional things I came across:

- add gradient filters to image
- create shadowed images

Anything which can be possible with ImageMagick.

>>What do you want that can't be done as a kipi-plugins?
>>Achim
The idea is to avoid having to re-implement everything as kipi-plugins when it is not necessary. And also allows to use home-made scripts written in other languages.
For example : Why implementing a calendar kipi-plugins when there are 100's of scripts on the net doing the job very well ? 
.
I closed 128915 since it is a kind of duplicate of that one. 
But the current solution in konqueror is far too complex. having it in the background as the implemention might be Ok but this needs a much simple interface in tool/settings where everybody can write its own command. without having to mess with the desktop files.


 

If someone is able to write his own script (or even ImageMagick
oneliner) he will be perfectly able to "mess with the desktop files".
Also using whole .desktop file features will make possible to share
those scripts.

>If someone is able to write his own script (or even ImageMagick
>oneliner) he will be perfectly able to "mess with the desktop files".
As someone pointed out on the mailing list this is not because someone is able to write scripts that he can/"has time"/wants to edit desktop files.  

>Also using whole .desktop file features will make possible to share
>those scripts. 
That is why .desktop files in the background might be the technical solution. But in my opinion it is not something to present to all users.
People cannot be expert in everything. Writting "create_album.pl %s" in a field is not the same as having to read documentation about "service menu"

What I use to get additional actions for a right click is

  cd MyDesktopFiles
  # create folder if not already available:
  mkdir ~/.kde/share/applnk/.hidden
  cp *.desktop ~/.kde/share/applnk/.hidden

A desktop file may then look like (without the #)
#########################################
[Desktop Entry]
Comment=
Comment[en_US]=
Exec=$HOME/MyScripts/digikam_test.py  %U
GenericName=Test
GenericName[en_US]=Test
InitialPreference=7
MimeType=image/jpeg
Name=Test
Name[en_US]=Test
Path=
StartupNotify=true
Terminal=false
TerminalOptions=
Type=Application
X-DCOP-ServiceType=none
X-KDE-SubstituteUID=false
X-KDE-Username=
######################################

The script may then for example look like
# --- cut here 
#! /usr/bin/env python

import os
import sys

img_name = sys.argv[1]
# Remark further selected images would be in sys.argv[2], sys.argv[3], ...

# Get the name of the folder:
img_folder = os.path.split(img_name)[0]

print "img_name=", img_name
print "img_folder=", img_folder

print "now do whatever you want with the image (or images)"
# --- cut here

So it is not too complicated, but, as mentioned in #6, 
writing something like "create_album.py %U"
is simpler than the above.

Question: is it possible to assign keyboard short-cuts 
corresponding to such .desktop files?

Hmm, this remembers me I had an idea a few weeks ago which corresponds to this wish.

What about having a "script" kipi-plugin that would allow us to create our own scripts to do specific job ?

I guess this corresponds to desktop files + scripts as described above. That would be quite useful...

BTW, shouldn't this bug be reassigned to kipi-plugins instead of digiKam ?

*** This bug has been confirmed by popular vote. ***

Ad #9: "script" kipi-plugin: 
In the context of the F-Spot-->digikam thread Mikolaj  mentioned
http://techbase.kde.org/Development/Languages/Kross
for scripting  with KDE4.
For example this looks nice
http://techbase.kde.org/Development/Tutorials/Krita_Scripting#Import_and_Export
and might offer a framework to build more complicated scripts
or even plugins to digikam (without the need to go via
kipi-plugins). 


Ad #10: I am not sure whether this should be dealt with on the digikam
or the kipi-plugins level...

Some more thoughts on what is really needed here:
a) in principle the functionality of adding calls to a separate programm
   on a right-mouse click can be done using .desktop files
b) To make things work more integrated it would be good to
   - be able to assign keyboard short-cuts 
     (maybe this is already possible right now?)
   - have a menu entry with such scripts?
   
Simpler than a), and maybe needed for b), 
might be some way to add several scripts to a custom menu?

> ------- Additional Comments From fabien.ubuntu gmail com  2007-04-30
> 16:51 ------- BTW, shouldn't this bug be reassigned to kipi-plugins
> instead of digiKam ? _______________________________________________


Only if implemented as kipi-plugin.
BTW - additional feature would be some sharing service and getting new
scripts by GetHotNewStuff dialog.

BTW, shouldn't this bug be reassigned to kipi-plugins instead of digiKam ?

If i remember, Achim have already open a file in kipi-plugins B.K.O...

Gilles

Gilles, I am not sure whether this should go to kipi-plugins or not.

One simple implementation within digikam could be the following:
- add a new menu: "External Tools" (etc.)
- the entries can be added using a simple dialog with fields:
   programm  commmandline_arguments  keyboard-short-cut
- the entries are stored in the digikam config file
Whenever there is an active selection, all selected images are passed
to the command on activation.

I understand one of the reasons to not implement that wish are potential conflicts with database  and its contents. It could be avoided with KROSS backend where provided API would be limited to actions not damaging to database reliability.

Amarok has an interface that is doing all the things mentioned above. It has the possibility to create a menu with your own menu-entries. With the use off  dcop-calls you are also able to make use off specific programfunctions. Have a look at http://amarok.kde.org/wiki/Script-Writing_HowTo.

This is nice!

Just to provide one more K/cross link:
http://bugs.kde.org/show_bug.cgi?id=146866

As far as I remember, dbus is going to replace dcop in KDE4.

From the discussion in this wish, I am not sure
about the right approach/solution
A) Provide a way for users to create .desktop files,
   which would then be available in the right-mouse button menu
   (but not just within digikam but also in konquerer,
    which can be seen as an advantage, but also as a drawback!).
   Mikolaj, are you thinking of konquerers 
   "File association" configuration here?

B) An additional menu point to which own scripts maybe added
   via a simple interface 
   (visually similar to http://amarok.kde.org/wiki/Image:Scriptmanager.png).
   These scripts would just get the currently selected
   images as argument and can do whatever they want with it
   (see #c6 and #c14 above).

C) KROSS scripting: http://bugs.kde.org/show_bug.cgi?id=146866

I think that any discussion about C) should go to bug 146866.
For this wish here, I am personally in favour of B),
while the original wish had something like A) in mind,
if I interpret things correctly.

So what should be done here?

> A) Provide a way for users to create .desktop files,
>    which would then be available in the right-mouse button menu
>    (but not just within digikam but also in konquerer,
>     which can be seen as an advantage, but also as a drawback!).
>    Mikolaj, are you thinking of konquerers
>    "File association" configuration here?


I think digiKam should use concept but scripts should stay exclusively
for digiKam use. And vice versa - digiKam should stay away from general
Konq scripts.

This is probably simplest thing. Problem is with installation of such
scripts.

> B) An additional menu point to which own scripts maybe added
>    via a simple interface

This solves aforementioned problems with installation/uninstallation and
general maintenance of scripts. Also this interface could be used for
the same purpose of KROSS programs.

> C) KROSS scripting: http://bugs.kde.org/show_bug.cgi?id=146866


Agree - KROSS is completely different beast.

I am not developer and don't know how much work all those things
require and how much overlapping is there. I would go through all those
steps looking how "market" reacts:

Implement step A, ask kde-apps maintainer for creation of new section
of programs or try other way to track created scripts and users
comments. If they would whine about installation and removal of scripts
add simple manager. If this will be still not enough think seriously
about KROSS. Don't think about this like three separate ways to solution
but more like a roadmap :)

Additional remark to the desktop files discussed in #c7:
It seems necessary to run kbuildsycoca.
Moreover, it might be necessary to run this a couple of times
until it works? (At least I just had a situation where it did
not work immediately for whatever reasons ...)
(One way to check is to use konqueror and see if the new
entry is visible under the right-mouse pop-up menu "Open with" of a jpeg file.)

When using gqview, you get a very simple "edit" option, which is configurable from the preferences. This would basically cover a lot of instances. 

I don't like the .desktop file idea, because most of the script would be only useful when run from digikam (or similar, but I don't want to generalise too much). But mostly I don't like it, because it doesn't work for me, even after running kbuildsycoca and restarting my kde session.

I'd be in favour of combining such edit "commandlines" with the "Open With..." menu or the "Edit..." menu, because the right mouse menu should be kept as small as possible.

Arnd,

This can be done to create a dedicaced kipi-plugins to add menu action about external scripts, configurable by users. There is a file in B.K.O about this subject

I can help you to study this way if you want...

Gilles

I have added a Services-Menu like in Dolphin. So you can select an application from the list for the associated mimetypes. If the program is not listed, you can also open some custom command.
This is the KDE default dialog for opening custom applications.

Does this somehow solve the problem here?
The services menu is only found in current SVN I guess, not sure if it was released with 0.10 already.

Andi

You mean extended "Open with..." menu entry? This is not classic "Actions" menu (aka service menu) known from Konqueror or Dolphin.

Trick with applnk/.hidden is working and with your fixes reaches its full potential.

I'd like to wait how "Custom commands" will be implemented finally in BQM.

Also maybe other voters would write :)

One thing I forgot to write (as usual): applnk/.hidden is limited in possibilities comparing to full service menus.

About crowding of context menu: Actions could be moved as submenu to "Open with..."

This one can be closed, right?

Since "call custom, external scripts from digikam" came up on the mailing list, I stumbled upon this bug. As far as I would say, this wish is still not fulfilled with digikam / kipi-plugins in version 3.1.0. (KDE 4.10.3, gentoo linux)

In comment #22 Gilles mentions: "There is a file in B.K.O about this subject"
Does anyone know this issue's id?

My current workaround (excerpt from mailing list):
  ------------------------------------------ 8< ------------------------------------------
Digikam does have an "Open With" context menu entry.
So in the directory "~/.local/share/applications" I added a
file "myAction.desktop".

  --------------------- 8< ---------------------
> [Desktop Entry]
> Name=myAction
> GenericName=Cool photo tool
> Comment=some comment to set
> Icon=resizeimages
> Exec=/usr/bin/konsole --noclose -e perl /usr/local/bin/myAction.pl %F
> Type=Application
> MimeType=image/jpeg
> Terminal=false
  --------------------- >8 ---------------------
------------------------------------------ >8 ------------------------------------------

This works well. But it does not feel to be correct. ;)

I first thought of dolphins "service menu", too. Since dolphin and digikam both are KDE products, I expected similar behaviour. But while reading the comments of this wish, I realized that keyboard-shortcuts would be very handy. And this, as far as I known, can't be done with "service menu entries". So I personally would like the solution, mentioned in comment #14, to be implemented.

Gwenview up to version 1.4.x had a very nice "external tools" functionality. It was like mentioned in comment #14:

  1) create menu entry: "external tool"
  2) assign command line
  3) select images
  4) call external tool from context menu

But for some reason, the external tools disappeared, when going from 1.x to 2.x. :(
See wish #215880.

I really would love to have one way or another to add scripts to DigiKam.

I came with the question about context menu because it works so well in dolphin where I have a seperate menu entry and sub menu for all my scripts. About 60% of all my scripts (about 120 at the moment) honestly are just replacements for batch sets using Phatch just because of a bug in the batch scripts in DigiKam. The rest are mostly automation scripts i.e. HDR

Sure one can use dolphin for all this but this would be a great thing to have in DigiKam too

*** This bug has been marked as a duplicate of bug 220402 ***

Fixed With bug #220402