[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#242328: problem sort of solved



I see a solution to my problem:

	su 
	cd /usr/share/applnk/Applications
	mv -i * /usr/share/applications/kde
	cd ..
	rmdir Applications

	It seems that "Applications" now is a dummy folder name that 
is used to show only desktop files whose categories are not known.  
They show up in the K Menu in Lost & Found.  So no desktop files
should be in /usr/share/applnk/Applications, and in fact that 
directory need not exist.
	So long as they are NOT originally from 
/usr/share/applnk/Applications, the files appearing in Lost & Found 
can be deleted or moved to other folders using menuedit,  and will 
then NOT appear any more in Lost & Found.  This is the correct 
behaviour. 
	Since the menu system does not display empty folders by 
default, the Lost & Found folder itself will not appear in K Menu 
unless there is something left in it, or something landed there due 
to some package putting a desktop file somwhere that has no category.

So, fine.  I think I'm with the program now.  

One rough spot I noticed:  A KDE desktop file that is
(1) From one of the (legacy?) folders like 
/usr/share/applnk/Development, etc., and
(2) Does not have a valid Category entry,
cannot be given a new icon.  The modified desktop file will be made in
~/.local/share/applications/kde-xxx.desktop
but K Menu and kmenuedit (on next start) will ignore it.

Maybe this is the price of transition?  The work around is to give
the offending desktop file a valid Category line.  Then its icon
can be modified as usual.



Reply to: