Version: 1.5.3 (using KDE 3.1.3) Installed from: SuSE Compiler: gcc version 2.95.3 20010315 (SuSE) OS: Linux (i686) release 2.4.18-4GB I am using a filteraction on to trigger a sound from kmail on the reception email that fits a certain criteria. That works ok. Basicly, it is triggered if no other filter matches, as the last filter in the list. I use the execute command action to execute this command: play /home/andre/.kde/share/sounds/ogg/New_Mail_Notification.ogg Now, if I am playing a MP3 using XMMS, I run into a problem. XMMS seems to block arts, which seems to block the play command, which lockes KMail. So basicly, if I am running XMMS and a new message arrives that triggers a sound, KMail freezes. It is debatable where this error is located. Would it be possible for KMail to just trigger the action and not look back at the result? After all, KMail doesn't need te result (unlike with the pipe through action). In general, I think that the interface should not be frozen solid because some filterprocess is taking it's time. BTW: thanks for a great mailclient!
*** This bug has been marked as a duplicate of 41514 ***
Oops, this isn't really a dupe of #41514. Yes, in theory we don't have to wait for the command to finish and we probably shouldn't. But this could lead to hundreds of commands started in quick succession without waiting for the others to end. Is this really a good idea?
Subject: Re: kmail freezes if filter-triggered process takes forever >Yes, in theory we don't have to wait for the command to finish and we > probably shouldn't. But this could lead to hundreds of commands started in > quick succession without waiting for the others to end. Is this really a > good idea? True, but... I am wondering if freezing KMail is better alternative? I think it is not. People who execute commands on a filter should know what they are doing ;-) OTOH: Might I propose a feature here? It would be cool if I could have a filter _scedule_ a command, and have that command executed as soon as the action that triggered the sceduling has finished. To take my mail-sound again as an example. I could have the filter scedule to play my sound. The command would be put in a queue if the same command is not allready in the queue. As soon as the mailfetching that triggered the filters in the first place is ready, the commands in the queue would be executed. This would allow me to play a sound on the arrival of email that matches certain criteria, but would only sound it once, even if multiple matching emails would arrive. If I were to attach another sound to another class of messages, and such a message would arrive too, the sounds would both be played, because the commandline differs. This could also possibly avoid the problem you sketch above. Andr
Subject: Re: kmail freezes if filter-triggered process takes forever This command scheduling sounds like a good idea. Please file a new wishlist item for this unless you think that this scheduling is exactly what is needed to fix the freezing problem.
Subject: Re: kmail freezes if filter-triggered process takes forever I don't think it would completely solve the problem (not if these sceduled processes would be waited for to complete too, at least). So, I entered a wishlist. It can be found as bug 62942. Andr
Fixed in CVS resp. KDE PIM 3.3 (by Ingo).