| Summary: | Global Menu System | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Heinrich Wendel (RETIRED) <lanius> |
| Component: | Unclassified | Assignee: | Sergey Kuleshov (RETIRED) <svyatogor> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | enhancement | CC: | deviantgeek, hanscats, jjk3, jrmalaq, k, mccary, pauldv, seemant, ska-fan, svyatogor, tawesley, tom.gl, tom, wolfjb |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Heinrich Wendel (RETIRED)
2003-04-02 09:00:23 UTC
*** Bug 17727 has been marked as a duplicate of this bug. *** Just throwing in my vote for this being optional. More of a rhetorical question as food for thought. I haven't reviewed the freedesktop.org standards yet, so ignore if this is already accounted for in some way. Would it be reasonable to allow some customization to be done automatically? For example, lets say internet apps are installed into a submenu option called "Internet". Would it be possible to tell a configuration file to interpret Internet as WWW? >> For example, lets say internet apps are installed into a submenu option called "Internet". Would it be possible to tell a configuration file to interpret Internet as WWW?
The freedesktop standard supports .directory files in which you can tell how the directory should be named.
Besides from this, I think it should be no problem to add an application to the menu, e.g. with an dodesktop call in portage or somewhat like that, but what to do with the native applications of gnome/kde? Should the gnome/kde ebuild contain a .desktop entry for every app?
I guess this is very useful.
Here is my suggestion on who it should work.
On the system we have a central location for the menu, say /etc/menu.d/
Here all subfolders represent categories and files - menu entries
respectively. The file contains three entries, something like this:
Name=MyApp
Command=/usr/bin/myapp
Icon=icon.png
These entries are created when a pckage is merged by a special domenu command
in a ebuild. E.g. domenu Editors, GVim, gvim
In addition to the categories folder the menu.d/ would contain a folder
"rules", which has the ebuild style files describing how the menus for each
installed wm/de should be generated. It would look like this:
init_menu() {
#Do all nessecary init. here. Eg. touch the menu file.
}
start_menu() {
#Wright whatever should be in heading of the menu.
#Especially important for one file menus file fluxbox.
}
write_entry() {
#Ovious. Here we have ${Cat} ${Name} ${Com} vars defined and set.
}
end_menu() {
#whatever should be done to finish the menu.
}
Now the most important step: genrating users menu. First of all a user should
have a choice of whether to use this system or not. If the user likes it he
should add a call to syncmenu (a bash scipt) to the .bash_profile or whatever
file.
When the syncmenu starts it first of all syncronises the ~/.menu with
/etc/menu.d (It will basically sync everything except the files that have
Custom tag - means edited by user and don't touch). Then this file sources
the files in the /etc/menu.d/rules and calls the functions in the order:
init, start, write (for every entry), end.
I guess the system is quite flexible and allows to support any wm,
irrespectively of the menu style it uses.
I'll try to implement it.
I am already developing this system, so for the time being I'll accept it. When it'll be ready i'll reasign it to soemone with nessecary permisions. This could also be interesting: http://lists.debian.org/debian-devel/2003/debian-devel-200304/msg00800.html Instead of your own app files, you should use .menu files described in the free desktop standard, they are natively supported by kde and gnome and also support i18n. I agree with the previous poster. Along with that, the standard files are rather easy to parse, and lets you just merge the menus into other formats with some creative shell or python scripting. also, I think the idea of adding a .desktop /.menu file inside an applications "files/" section , instead of doing an additional "domenu" for each ebuild is a good one. Yep, Spider, I did think already about adding the .desktop entries into files/ dir, but I need to check if it is ok with regards to the current policy. However, it doesn't save us from domenu commands for the following reason: the menu entries might depend on USE flags. E.g.: We don't want Mozilla Mail menu entrie to be installed if moznoirc is in USE. I don't see the problem ;D Each app has to supplie one or more .desktop files and they can easily be inserted in /etc/menu.d (or whereever) by a domenu command :) Let me give you some more problems to discuss :) first: we need a good menu structur, take a look at the debianish one (http://www.debian.org/doc/packaging-manuals/menu-policy/ch2.html#s2.1), vfolder (http://www.freedesktop.org/standards/VFolderDesktops.txt, https://listman.redhat.com/pipermail/xdg-list/2002-July/000569.html) and the categories metioned in the freedesktop standard (http://www.freedesktop.org/standards/menu/draft/menu-spec/menu-spec.html#CATEGORY-REGISTRY) second: how to add all the applications supplied by kde and gnome to the menu, the only possibility I see atm is that the packages have to supply a .desktop entry for each application. A problem could be some DE specified entries, like KDE ControlCenter, but there is a keyword "OnlyShowIn" in the freedesktop standard that could be used for this purpose. third: we need i18n support, but this shouldn't be a big problem, as it is also supported by freedesktop.org fourth: how to script all the convertes for the different WM's and DE's, one script for each wm or one config file (this must be very flexible) which will be parsed and then generates a menu. for development status take a look at http://cvs.cojobo.net *** Bug 5510 has been marked as a duplicate of this bug. *** *** Bug 10429 has been marked as a duplicate of this bug. *** i added a `make_desktop_entry` to eutils some back because this came up when we were unifying app-games install processes ... i do not really like the file/.desktop idea because you'd have things duplicated ... but it may be the only way to go for proper NLS support ... *** Bug 4884 has been marked as a duplicate of this bug. *** *** Bug 25797 has been marked as a duplicate of this bug. *** http://forums.gentoo.org/viewtopic.php?t=66754 (just another thread that refers to this topic) Ugh this is confusing me ;-) Well, better safe than sorry, so I'll spread my peace. At any rate, it seems that if you install ONLY IceWM, and install a lot of crap, nothing shows in icewm's menus. I have nothing under Gnome, KDE, or Programs in Icewm. I don't have Gnome or KDE installed. I have a lot of stuff installed. At any rate, some sort of core menu system is needed, I'll agree, but it will probably involve patches to applications. As for users' menus, there should be some sort of overlay in $HOME for users involving IGNORing specific menu entries and ADDing your own entries. These systems shouldn't need to have strange and mystical bendiness for odd WM's; just PATCH THE WM if it doesn't use those menus, and ASK THE MAINTAINERS to include the patch in the next release. That way the system will spread. Use a separate library to read menu entries. That will make patching apps easier, and make matinence so much easier too. This is now handled by the following glep: http://www.gentoo.org/proj/en/glep/glep-0016.html *** Bug 35929 has been marked as a duplicate of this bug. *** *** Bug 35930 has been marked as a duplicate of this bug. *** |