Missing menu items after upgrade

[Jeff Spaleta]

On Thu, 28 Oct 2004 17:24:43 -0600, Rodolfo J. Paiz
<rpaiz at simpaticus.com> wrote:
> I do *NOT* want to have to search my disk and scour the .desktop files
> to find out what happened behind my back or without my knowledge.
> "NoDisplay=true" should *NEVER* be the default for an application.

I can make a strong case for xdvi to not be in the menus, based on its
non-conformance to evolving UI standards, but to be callable as a
viewer to view dvi files when you right click on a dvi file via mime
associations, even in a default end-user install. Since xdvi is
essential a special purposed viewer, and has very little value beyond
viewing files. Constrasted to emacs or xemacs, which are editors and
not just viewers. There is significant value as a development tool
here beyond just a file viewer that can be called from nautilus. And
clearly the inclusion of emacs at all in the default...is not aimed to
fill a niche need for the intended audience of the default install.
emacs is included for convience for another category of user.

So i don't think its appropriate to say never be turned off in the
menus by default.  I'm much much more concerned about the problems
associated with local reconfigs that undo the default settings in a
.desktop. Approapriate hooks for local .desktop settings continues to
be a problem, and a growing one. The addition of mime information in
.desktop files make its vastly more important to have a clean way for
local reconfigurations of .desktop files to co-exist with package
defaults. I dont think even marking .desktop files as config files is
going to be a workable solution. I think you will have to end up with
a locally defined shadow set of .desktop files that override default
.desktop file settngs.
Example:
/usr/share/applications/vncviewer.desktop  would hold Os system defaults
/usr/share/applications/local-changes/vncviewer.desktop  would hold
local changes that override the Os system defaults.

In this case I might want to locally redifine the Categories line. All
i would do is
add the new Categories line in local-changes version of the file and
my local change would be used without disturbing the default file.
This way if yet more functionality is added to the .desktop
file...like mimetype informaton has been recently... my local changes
do not get in the way, unlike marking the .desktop file as a config
would.

-jef