| Summary: | domenu command, required for global menu system (#18638) | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Heinrich Wendel (RETIRED) <lanius> |
| Component: | Unclassified | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | bradenm_k, genstef, greg_g, jowilly, jrmalaq, k, mr_bones_, prieheck, radek, rgoessen, spamme, thechris.ieee, unit3, wolf31o2 |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 31333 | ||
| Attachments: |
domenu
domenu domenu domenu domenu domenu domenu domenu doicon domenuicon.diff domenuicon.diff domenuicon.diff |
||
|
Description
Heinrich Wendel (RETIRED)
2003-08-02 07:25:19 UTC
Created attachment 15360 [details]
domenu
Created attachment 15361 [details]
domenu
fixed if xdg module not available
Created attachment 15362 [details]
domenu
sorry, now it should work ;)
*** Bug 27605 has been marked as a duplicate of this bug. *** *** Bug 27779 has been marked as a duplicate of this bug. *** *** Bug 27802 has been marked as a duplicate of this bug. *** Well, emm SpanKY, it's nice of you that you mark my requests for several programs to have menu entries as duplicated, but I don't think that's valid. As long 'domenu' isn't even in Portage yet, there has to be another way to put the programs in the menu. I think my requests are up to the maintainers of the ebuilds if they decide to wait for 'domenu' (howlong that could ever take from now) or that they want to have their ebuild right, right now, and modify it when this domenu is finished. So, I don't know how long we have to wait for domenu, but in the maintime I think ebuild maintainers should have the chance to add a menu entry if it's wanted. Ebuild maintainers of Unreal Tournament, UT2003 (&demo) amongst another one did accept the request kindly. *** Bug 28051 has been marked as a duplicate of this bug. *** do to the load that Gentoo puts on developers as is, if you want a menu added to a package then you'll have to personally talk to a developer/team to get it added ... i'm not going to reassign menu requests to a developer, i'm going to mark them as dups of this Created attachment 17313 [details]
domenu
new version...
*** Bug 28688 has been marked as a duplicate of this bug. *** Created attachment 17826 [details]
domenu
hopefully the last version ...
Created attachment 18315 [details]
domenu
little fix, when will it be included?
Included for 2.0.49-r8 can you please remove domenu again from portage, some people wanted a glep for the menu system and it has not been accepted yet removed don't know if we will need it at all now, mark it as later for now, for more information on this topic see the current glep: http://www.gentoo.org/proj/en/glep/glep-0016.html Okay, so now we have a glep as requested...but the project is dead, so maybe this patch which seems to be a working solution should be applied? Created attachment 30438 [details]
domenu
this one should be included now, maybe for portage 2.0.51? i think it should be included / finished soon i hate having to deal with bug reports about creating menu entries ... i think they're cruft and i'd love to have someone else handle it :) Is this script supposed to throw this error:
Traceback (most recent call last):
File "./domenu.sh", line 43, in ?
os.system("install -d " + os.path.join(D, "usr/share/applications"))
File "/usr/lib/python2.2/posixpath.py", line 50, in join
elif path == '' or path[-1:] == '/':
TypeError: unsubscriptable object
? :)
*** Bug 56552 has been marked as a duplicate of this bug. *** *** Bug 58924 has been marked as a duplicate of this bug. *** *** Bug 58925 has been marked as a duplicate of this bug. *** *** Bug 58926 has been marked as a duplicate of this bug. *** *** Bug 49579 has been marked as a duplicate of this bug. *** *** Bug 57203 has been marked as a duplicate of this bug. *** *** Bug 66076 has been marked as a duplicate of this bug. *** Any progress on this? Is help needed? Created attachment 42578 [details]
domenu
Created attachment 42579 [details]
doicon
i can also impelement it as eclass, if you won't add it ;) Lanius, that would be better anyway... don't put this in portage, 'cause then you're tied to their release schedule for something that isn't base portage functionality. Please put it in an eclass. i'd say for now, integrate it into eutils.eclass and when portage starts splitting up portage into sep packages, we can merge it into the broken up portage packages I second, err, third this. Where is the problem with this? Why is it not yet applied? ...because you haven't written it as a patch to eutils.eclass yet? Created attachment 43733 [details]
domenuicon.diff
diff for eutils.eclass
Please review it, as I am not quite sure if I have respected all gentoo
policies.
needs local variables probably should use "$@" instead of $* shouldn't call ls, grep, echo in $() should be quiet should insinto once per function. Created attachment 43775 [details, diff]
domenuicon.diff
Is this ok?
Created attachment 43948 [details, diff]
domenuicon.diff
Here is a smaller implementation that is also quiet.
i propose to move that and make_desktop_entry to a new menu.eclass, because eutils.eclass is already full of stuff Well, these should supercede the make_desktop_entry, and if you move make_desktop_entry to a new eclass, then you would need to edit every ebuild that uses it. If you're editing every ebuild that uses it already, then why not just move to the new do* commands in those ebuilds instead? Stefan: that looks good, but it would really need to create the entire .desktop entry. Also, the domenu command would need to support non-freedesktop.org compliant window managers, such as windowmaker, *step, and *box. 1.) for creating .desktop entries we have make_desktop_entry 2.) non-freedesktop compliant windowmanagers need to be patched to support freedesktop standards, we more or less decided that a long time ago what's the difference between 'domenu' and 'make_desktop_entry' ? they both result in the same thing, an entry in the menu system of a WM/DE like wolf said, i think we should punt make_desktop_entry and move to using domenu, meaning no 'new' eclass is needed domenu only installs a already existing desktop entry in the correct location. make_desktop_entry creates a new desktop entry I think we should keep it in eutils.eclass, so no extra eclass needs to be inherited, and no ebuild needs to be changed. Can we add this now? I think we should additionally provide a make_session_desktop(command, title) to make gdm 2.6 happy, so that all window managers can easily place their session files in /usr/share/xsession. (See bug 72613, among others) finally in portage, also included a make_session_desktop *** Bug 89374 has been marked as a duplicate of this bug. *** |