[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [Bug 103215] kicker removes application link during application
From:       James Richard Tyrer <tyrerj () acm ! org>
Date:       2005-05-28 0:36:35
Message-ID: 20050528003635.27865.qmail () ktown ! kde ! org
[Download RAW message or body]

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
         
http://bugs.kde.org/show_bug.cgi?id=103215         




------- Additional Comments From tyrerj acm org  2005-05-28 02:36 -------
Re: Comment #29:

Yes this is a problem.  We need to figure out something that will addresses all \
issues.  I don't see this an an either/or problem.  There should be a solution out \
there.

I admit that I have only skimmed this bug. :-)  So, I might have missed something.

But, I was wondering if FAM could fix this.

With the current pre-release 3.4.1 (05/26/05):

Since I was upgrading KRename, I tried this.

I added an icon to my Panel and then removed (make uninstall) KRename.  I then had an \
icon that didn't work.  I killed Kicker and restarted it and the icon dissappeared.  \
Good but ...  So, I wondered if the same thing couldn't be accomplished without \
having to restart it by using FAM, KDirWatch, and/or kbuildsycoca

Then I installed the new version of KRename.  I restarted Kicker but the Icon didn't \
reappear. 

As stated above, having it reappear should be doable by using FAM, KDirWatch and/or \
kbuildsycoca.

So, I restarted KDE and it still doesn't reappear despite the fact that this:

[ServiceButton_7]
DesktopFile=Utilities/krename.desktop
FreeSpace2=0.439791
StorageId=kde-krename.desktop

remains in the: "kickerrc" file.  This, then, raises the question of when the entry \
should be discarded.  I suggest when KDE is started if possible, otherwise, when \
Kicker is started.

This appears to be a problem -- I had to edit the file to remove it.  Or, is this \
related to the fact that KRename still uses the old location for its 'desktop' file \
$KDEDIR/share/applnk/Utilities/)?

OTOH, when you D'n'D a 'desktop' file for an 'application' to the Panel, it is \
actually coppied to the panel (actually to the directory "$HOME/share/apps/kicker/").

So, I D'n'Ded from the KMenu to add KRename to the Panel.  Then the 'desktop' file \
was coppied to the: "$HOME/share/apps/kicker" directory.  This is an inconsistency \
although many users won't notice it till they address this issue.

So, now I uninstall KRename and the copy of the 'desktop' will not be removed because \
whatever method is used to uninstall the app doesn't know it is there.  So, perhaps \
it would be better if installing with "Add to Panel -> Application" had the exact \
same effect -- it coppied the 'desktop' file to: "$HOME/share/apps/kicker/" and used \
the copy.

Now, I uninstall KRename again and I have a dead icon (can't find executable).  I \
restart Kicker and the icon is still there. Bad, but ... When I reinstall KRename, \
the link still works.  So, this seems to work better. 

This possible method leaves questions.  

(1) How do we determine if the icon should be displayed.

With the KMenu, using the "TryExec" Key prevents the display of a dead item.  Would \
it be possible to do this with the Panel?  Yes, this would require that the 'desktop' \
file had that Key but adding it to 'desktop' files that are lacking it shouldn't be \
rocket science.  If so, what would trigger the checking so that it would disappear 

(2) How do we determine when to delete the files in: "$HOME/share/apps/kicker/"?  \
This is currently an issue.

(3) And, again, how do we determine when the reference in the: "kickerrc" file (or a \
"childpanel_panelextension_*_rc" file) should be removed -- when Kicker is started; \
when KDE is started.  This would obviously be done only after the corresponding file \
in: "$HOME/share/apps/kicker/" was deleted.


[prev in list] [next in list] [prev in thread] [next in thread]