Re: My Little Wish List for Gnome


I like the basic idea of merging the two menus, but when I consider the
things a user might want to do, and the complexity of it, I start to think
there must be a better way. 

Sure you could have .dektop entries that hide system entries, but if the
user wants a menu that is radically different to the system menu the whole
thing becomes a mess: the whole menu is full of .dektops to delete the
system entries and other entries to put things where the user wants it.
For example: if I want emacs in a "editors" sub-menu rather than
"applications" (which is where it is in the current system menu) then I
(or gmenu) must:

  - create a .desktop entry to delete emacs from the applications menu
  - create a .desktop entry to add emacs to the editors menu 

if a user does this for many things - it's going to get ugly. And if they
start moving entire sub-folders around? If I want to delete the
applications menu all together, do I create a applications.desktop in the
parent folder that has a show=false tag? yuk.. The whole thing seems
completely unintuitive....

How about a user menu (not merged) where the .desktop entries can contain
a "defaults=" tag, pointing to the system .desktop entry. The user can
then move the user menu .desktop around and still be picking up the system
defaults, or could override them himself. An option in gmenu or on the
panel (ie the systmem menu still appears as a submenu at the bottom of the
panel) could be provided to show the user what is in the system defaults
.desktop files and give them an option to add them to their user menu? 

I'm going to code this up after my exams (which start in, ohh, about an
hour ;-) just to see what it's like.

If everyone thinks my idea is completely naff, that's fair enough, but I
still think there must be a better way than merging the menus.... thats OK
as long as users to want to make a radical departure from the way the
system menus are setup (which it is quite posible that they might).


On Tue, 12 Jan 1999 wrote:

> On Tue, 12 Jan 1999, Daniel Burrows wrote:
> > 
> >   Is there any reason to have 2 menus?  I haven't delved into the menu system
> > but I think the best way to handle this would be for Gnome to read menu
> > entries from both the global directory (<prefix>/share/apps I think) and
> > the user directory (~/.gnome/apps), then merge the two, so that you end
> > up with one menu hierarchy containing both sets of menus.  Like in Debian
> > I have most of the menufiles in /usr/lib/menu, but I can drop extra files
> > into /etc/menu (and I believe ~/.menu but I haven't bothered with that) and
> > they get merged into the menu system.
> > 
> >   Probably conflicts should be resolved by the user's setting overriding the
> > system settings (I might want my Eterms running with --trans --shade even if the
> > system menu runs them opaquely.)
> This feels like a good way to do things. Then, the system menu editor app
> would function for any user, with the implicit understanding that you're
> operating on your local menu and not the system menu.
> Perhaps the issue of not wanting system menu stuff cluttering your menu
> could be resolved by having the menu editor (or the intrepid vi user if
> you wish) create a .desktop entry with the same name and in the same place
> in the hierarchy with a command to hide the menu entry.
> So, if you are wanting to hide netscape from the applications menu, you
> create a Netscape.desktop in ~/.gnome/apps/applications that says
> [Desktop entry]
> Name=Netscape
> show=false
> or something to that effect. :)
> Then when the menu building code scans the .desktop files to build the
> menu, if it finds two entries with the same name in the same place, it
> gives precedence to the one in ~/.gnome/apps and processes the hide
> commands if appropriate.
> I'd take a hack at it if I could get X to stop crashing my system.. damn
> development kernels.. :)
> -Steve
> -- 
>         FAQ: Frequently-Asked Questions at
>          To unsubscribe: mail with 
>                        "unsubscribe" as the Subject.

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