[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:       Frerich Raabe <raabe () kde ! org>
Date:       2005-04-05 0:27:23
Message-ID: 20050405002723.25637.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 raabe kde org  2005-04-05 02:27 -------
How about this:

when Kicker detects that a file which any of the .desktop entries which it manages \
vanishes, it first tries to figure out whether it's a "user" file or a "system" file.

* User files could be all files in directories which the user running the current KDE \
                session has write access to. For instance, anything in $KDEHOME.
* System files could be all files in directories which the user running the current \
KDE session does not have write access to. This usually (but not necessarily) covers \
all of $KDEDIRS, as well as the majority of the system files. In particular, it \
probably covers all files which the package mechanism installs.

Now, when Kicker notices that a file referenced by one of it's .desktop entries \
vanished, it checks the permissions of the directory which the file resided in to \
figure out what kind of file it was.

* If it was a system file, Kicker does not remove the link from the panel immediately \
because possibly somebody other than the current user removed the file (and might \
exchange, replace or restore it soon), read: the user might not have intentionally \
initiated the process of removing the file. Instead, Kicker waits a little time, and \
eventually gives a warning message (or it flushes those dead links on shutdown, or \
                so). What it actually should do - I'm not sure. :-)
* If it was one of the user's files, Kicker has reason enough to believe that the \
user himself removed the file, so pops up a message box immediately, pointing out \
what it wants to do - and that message box has a 'Don't ask again checkbox', so that \
you can get the automagical "Kicker is always in sync" behaviour if you want.

This gives us a nice share of what Aaron is trying to achieve (I think) but it also \
honours the fact that a number of package systems are not quite ready for such a \
system. In any case, as soon as most package systems are changed (if at all? I don't \
dare to estimate), this system can be changed easily to treat all files as 'user' \
files, effectively making it removing links from the panel as soon as *any* file on \
the system vanishes.

How does that sound?


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