A simple and silly question. I want deactivate default "Device actions" like "Download Photos with Digikan" but I can't delete this action because button was disabled.

On the other side, I can't see a deactivation button for device actions so, how can I deactivate this action?

Is a new installation with openSUSE 11.2.

It isn't possible to deactivate default actions at this stage. Please file a wish list report at bugs.kde.org ( under systemsettings/kcm_solid-actions ) so that I can track it.

Unfortunately since the feature freeze is now in effect, this will be in KDE 4.5 at the earliest.

bcooksley wrote:It isn't possible to deactivate default actions at this stage. Please file a wish list report at bugs.kde.org ( under systemsettings/kcm_solid-actions ) so that I can track it.

Unfortunately since the feature freeze is now in effect, this will be in KDE 4.5 at the earliest.

Such ultra complex system and developers forget one of the three basic operations, delete. Thanks good that there is only three .

I think that add so many unfinished features to KDE 4 is damaging it's image.

The feature is finished. I didn't think that a user would want to delete a system provided action ( in fact, they can't since they won't have the permissions to ).

I will allow the user to disable the action however ( by making the predicate never evaluate as true ) but that can only happen in 4.5.

Note that the Device Actions KCM has been improved further for 4.4 ( will now be able to handle everything Solid itself can, and the UI has been simplified and made more safe. Not to mention that significantly more modularised code itself )

bcooksley wrote:The feature is finished. I didn't think that a user would want to delete a system provided action ( in fact, they can't since they won't have the permissions to ).

I will allow the user to disable the action however ( by making the predicate never evaluate as true ) but that can only happen in 4.5.

Note that the Device Actions KCM has been improved further for 4.4 ( will now be able to handle everything Solid itself can, and the UI has been simplified and made more safe. Not to mention that significantly more modularised code itself )

I think that we talking about this module in the past and, well, is really powerful but so complex for simple users.

I understand why this button was disabled and a check would be a good improvement. By the why, if you are changing things, the proper place to add or remove actions for a basic users was in plasmoid an not in Device Manager, that is so complex. Yes, you and I can handle it without problems and is really powerful but many people can't.

I recognized the background work in that module or, for example, in Nepomuk, but it's important to note that without an easy interface few people can use or understand it.

I remember a beautiful Pirelly advertisement. In that, Carl Lewis was ready to run but he wearing red heels and slogan was "Power is nothing without control". My English is not good but I hope you understand what I try to explain you .

Unfortunately, I don't think this can ever be much simplified ( its better in the 4.4 version, see http://imagebin.ca/view/s4EJYtK.html ) as the underlying system, Solid is extremely powerful.

The only possible way to simplify it would require removing all the functionality that would make it useful to Developers, and would probably still confuse users ( due to the AND / OR nature of containers )

That reminds me.... need to update the documentation

bcooksley wrote:Unfortunately, I don't think this can ever be much simplified ( its better in the 4.4 version, see http://imagebin.ca/view/s4EJYtK.html ) as the underlying system, Solid is extremely powerful.

The only possible way to simplify it would require removing all the functionality that would make it useful to Developers, and would probably still confuse users ( due to the AND / OR nature of containers )

That reminds me.... need to update the documentation

I try to explain better .
The new form are great!. There is no changes to do here because it do it's job perfectly. But you must think from a not powerful user too.

When a device was connected to your computer, plasmoid must offer an add or remove actions that easily do thing in "Device Actions" configuration.

For example, if I connect my camera, open with Dolphin could be stupid so disable this action easily and maintain only "Download Photos with digikam" would be developed. Probably is the thing you want to do so, an additional form and a click is a lost of time any time you plug your camera.

The same for an usb player or for usb harddisks. If I plug my mp3 player the only action I need is Amarok but if I plug my external hard drive probably I want to launch Dolphin.

All the previous things can be made with "Device actions" but you need a lot of knowledge to create these rules.

The core of "Device action" is great and, I think, few things can be doing to improve it and offer more powerful so don't must be changed. But develop must be focused in create an easy method to handle all this powerful too, something like "Device Actions for Dummies" , without changing anything in current "Device action", with the exception of disable check for system actions (or default actions, I'm not sure which is the correct name).

I think that the best place to put this "Device actions for Dummies" was "Device notifier" plasmoid.

If you try to simplify "Device actions" probably you must remover power so, it's better a new point of view to avoid damage current power of "Device actions" system.

Naturally, this is a suggestion of how I think things should be and I could be wrong or even, another forum reader has a better idea .

Question. Why am I able to launch/play a DVD via the Device Notifier (Dragon Player), but a music CD won't launch with selecting Open Audio CD with Amarok?

Note that the Device Actions themselves aren't involved at all once you have selected to use the action in question. They just supply the specified command to execute.

If Amarok is started up, but then fails to do anything then that is an Amarok issue ( make sure kio_audiocd is installed )

If you cannot even select the action then that is an issue with the conditions used to match the Amarok Audio CD action.

That appears to be the problem, and I agree, not with Device Notifier. When I insert a music CD, the Device Notifier comes up with the identified device, and I have the presented options, one being Open Audio CD with Amarok, and that this 'option' is coming from System Settings > Advanced > Device Actions > Open Audio CD with Amarok.

I've looked at that item. The first thing I noticed, is that the actual command set for this device action is incorrect, at least as far as the options for Amarok show (amarok --help), which indicates that the command is amarok -p (or --play). The command in the device action entry is amarok --cdplay %u

I've changed it to amarok --play and amarok --play %u and neither launch amarok.

I've solved the mystery.

As configured, the default Device Actions "Play Audio CD with Amarok" does not work, as already posted. Two things were required to fix it.

A duplicate set of conditions have to be added and the command changed from amarok --playcd %u to amarok -p

Here is what the 'fixed' Play Audio CD with Amarok contains:

Command: amarok -p
Devices must match the following parameters for this action:

- Any of the contained conditions must match
- All of the contained conditions must match
The device's property StorageVolume.ignored must equal false
The device's property OpticalDisc.availableContents must equal 'Audio'
- All of the contained conditions must match
The device's property StorageVolume.ignored must equal false
The device's property OpticalDisc.availableContents must equal 'Audio'

I've tested this and it works flawlessly.

Well, as is usually the case with Linux, there is more than one way to do something.

By comparing /home/paul/.kde/share/apps/solid/actions/Open-Amarok.desktop to /usr/share/kde4/apps/solid/actions/amarok-play-audiocd.desktop I found that by making just four changes to the latter file, Amarok would launch and load the music CD via Device Notifier.

Here is what the unchanged /usr/share/kde4/apps/solid/actions/amarok-play-audiocd.desktop looks like with the items requiring changing in red:

[Desktop Entry]
X-KDE-Solid-Predicate=[ StorageVolume.ignored == false AND OpticalDisc.availableContent == 'Audio' ]
Type=Service
Actions=Play;
X-KDE-Priority=TopLevel

[Desktop Action Play]
Name=Play Audio CD with Amarok
Icon=amarok
Exec=amarok --cdplay %u
X-Ubuntu-Gettext-Domain=desktop_amarok

This is what the file looks like after the changes (in blue):

[Desktop Entry]
X-KDE-Solid-Predicate=[ StorageVolume.ignored == false AND OpticalDisc.availableContent == 'Audio' ]
Type=Service
Actions=open;
X-KDE-Priority=TopLevel

[Desktop Action open]
Name=Open Audio CD with Amarok
Icon=amarok
Exec=amarok -p
X-Ubuntu-Gettext-Domain=desktop_amarok

One doesn't have to duplicate X-KDE-Solid-Predicate=[ StorageVolume.ignored == false AND OpticalDisc.availableContent == 'Audio' ] which is what I did (and what results in the generated .desktop file) in the entry I created. In addition to the Exec= having been incorrect, the Actions= was also wrong. Action=Play; doesn't work, but Actions=open; does.

I made the three changes to the /usr/share/kde4/apps/solid/actions/amarok-play-audiocd.desktop (after making a backup). Tested it by selecting Open Audio CD with Amarok and again, works like it's supposed to.

Also, if you make the changes, remove the ~/.local/share/applications/amarok-play-audiocd.desktop file. If it exists, it appears to be used instead, and it will contain the incorrect values.

It is possible that the Device Notifier assumes what the name of the action will be as that seems to be one of the significant changes.

When one creates a new item in Device Actions, there is no place to identify the 'action' to be taken. My observation is that the 'action' is parsed from the action name field, taking as the action, the first word (Open Audio CD with Amarok) here, Open is the action.

The Action Name "open" is hard coded in the action editor for new actions.

Whilst the editor supports more than one action in each file, the conditions are shared by all actions in that file.