By default, Bugzilla does not search the list of RESOLVED bugs.
You can force it to do so by putting the upper-case word ALL in front of your search query, e.g.: ALL tdelibs
We recommend searching for bugs this way, as you may discover that your bug has already been resolved and fixed in a later release.
Bug 565 - klipper action menu can no longer start a KDE app
Summary: klipper action menu can no longer start a KDE app
Status: RESOLVED WORKSFORME
Alias: None
Product: TDE
Classification: Unclassified
Component: tdebase (show other bugs)
Version: 3.5.13 [Trinity]
Hardware: i386 Debian Squeeze
: P5 normal
Assignee: Timothy Pearson
URL:
Depends on:
Blocks:
 
Reported: 2011-10-27 13:53 CDT by Nick Leverton
Modified: 2012-10-19 15:39 CDT (History)
2 users (show)

See Also:
Compiler Version:
TDE Version String:
Application Version:
Application Name:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Nick Leverton 2011-10-27 13:53:22 CDT 
When klipper detects a URL and pops up, if I choose an action based on "kfmclient exec", "kview" or "kaffeine" then the program is not started.

Other browsers such as Firefox, Mozilla or Opera are started OK if I choose them from the klipper popup.
Comment 1 Timothy Pearson 2011-10-27 13:59:21 CDT 
Was this popup fully functional in 3.5.12?
Comment 2 Nick Leverton 2011-10-27 15:05:45 CDT 
Hi Tim, yes it was.
Comment 3 Timothy Pearson 2011-10-27 16:12:38 CDT 
I am unable to reproduce this problem on any test systems here.  Check for invalid paths or an old configuration that could be pointing to invalid locations.

Also ensure that your $PATH is set correctly, and that kfmclient exec '<something>' actually works from the terminal.
Comment 4 Nick Leverton 2011-10-27 16:24:10 CDT 
Certainly I can still run kfmclient exec '$URL' from the krunner box, apols I forgot to mention it once I'd found other k-apps don't work either.

I know I have some path strangeness as I have KDEDIRS=/usr/local so that I can add overrides for various desktop files and a few locally compiled bits of software.  I haven't tracked the root problem here down yet hence hadn't bugged anything, but parts of kdeinit seem to make incorrect assumptions on this, especially assuming that $KDEDIRS[0]{item} will always exist.  Nothing I've yet found is fatal, so I was working through the functional changes in 3.5.13 first as I find them.  I'll remove the KDEDIRS entry when back on the main desktop and see if it changes anything here.

I should perhaps mention that all my issues are new to 3.5.13, except where I said it was older.  Sorry for the flood of them but I didn't run the nightlies until this week !
Comment 5 Timothy Pearson 2011-10-27 16:39:51 CDT 
(In reply to comment #4)
> I should perhaps mention that all my issues are new to 3.5.13, except where I
> said it was older.  Sorry for the flood of them but I didn't run the nightlies
> until this week !

No problem.  In the future we will try to have a more organized release schedule, with a longer pause after the soft freeze so that you and others have time to find these kinds of bugs.

If you do manage to track down the cause of the problem, set this bug to reopened and give the SVN version number of the change that broke things.

Thanks!

Tim
Comment 6 Nick Leverton 2011-10-28 07:06:06 CDT 
Just to document that this problem too doesn't show up in a newly created user on the same machine (with KDEDIRS set), so must be settings-dependent.