trinity-devel@lists.pearsoncomputing.net

Message: previous - next
Month: May 2012

Re: [trinity-devel] Mysterious hard-coding

From: Darrell Anderson <humanreadable@...>
Date: Tue, 29 May 2012 15:53:46 -0700 (PDT)
> I'm starting to recognize this pattern....try grepping for
> /kde in your XDG directories (that means your system XDG directory as
> well as your profile and the XDG directories under the TDE prefix). 
> I suspect you will run across at least one .desktop file that contains the
> string.

Nothing there:

grep -rna "/kde" $TDEHOME

grep -rna "/kde" /opt/trinity | grep -v doc

Using a new profile, I disabled konqueror preloading. I started konqueror with strace using konsole.

Next I created a sym link (ln -s /opt/trinity/share/applications/tde /opt/trinity/share/applications/kde) and restarted the session. I again deleted the ksycoca cache and created another strace.

Other than the typical memory address differences, the two straces are identical. I had hoped to catch some kind of reference to "applications/kde" but there is none.

Interestingly, when I create the sym link I notice all TDE menu items repeat.

Because only core packages are installed, I can't test a variety of apps. Of those that are installed, I started kate, kwrite, kjobviewer, kcontrol, konsole. No noticeable problems.

Curiously, the same configuration items that are missing in the konqueror configuration icon list all appear in kcontrol -> Internet & Network -> Web Browser. Therein is a likely clue.

I'm starting to think the bug is in konqueror or in one of my *.desktop patches.

The thing about the patch set is there is no problem when I install all desktop files to $PREFIX/share/applications/kde during the build process or create the same sym link. Thus far I seem to notice the breakage only with konqueror.

Searching for "/kde" in my tdelibs and tdebase patches produced nothing.

I'm building the remaining packages of the main suite in order to have more apps to test. Please let me know what usability tests might help further isolate the problem.

I don't know where in the konqueror sources the configuration icon list is populated, but I suspect that is a good place to begin snooping. If I knew how konqueror populated its configuration icon list, then perhaps I could narrow the search to konqueror or related snippets in the patch set. Because the same configuration options appear in kcontrol, I'll take a wild guess that somehow konqueror parses the related desktop files incorrectly or simply can't find them.

Darrell