[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-29 3:25:54
Message-ID: 20050529032554.17616.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-29 05:25 -------
Re: Comment #35

> However, K Menu and Panel are 2 different things.

Quite true, but we assume some Joe 'newbie' User that doesn't know such things and \
IIUC good GUI design should try to have everything as much alike as possible.

I don't know what to say about this being rare -- I have no data.  It happens for me \
because I use Linux [mostly] from Scratch.  And we still have KAppFinder which adds \
stuff to the KMenu for users semi-automatically.  I stopped using RPM for apps so I \
can't do an experiment to see what happens if you update an application that has an \
icon on a Panel.

> I just hate to see yet another "Don't ask me again in the future" checkbox

Yes, I agree, we don't want any more of those if we can help it.  My presumption is \
that like with KMenu (is supposed to work), if the link is dead that it wouldn't \
appear but the 'desktop' file would stay there.  

Then we have the question of what to do with the files that pile up in: \
"$HOME/.kde/share/apps/kicker".  Well we already have that problem and we *do* need a \
solution for it.  I suggest that if they are dead links that they be removed based on \
how old they are.  But, that has a problem since what we really need to know is how \
long they were dead.  It hasn't been solved so now they just accumulate.


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