View previous topic :: View next topic |
Author |
Message |
stustill Guru
Joined: 25 Feb 2003 Posts: 333 Location: Aberdeen, Scotland
|
Posted: Tue Jul 15, 2003 9:42 pm Post subject: |
|
|
Adding menu entries to ebuilds is the best way to do it, although it is the most tiresome way for the devs, and the one they would not appreciate. However, when spikkle is finished his program, perhaps he could be granted access to update all the ebuilds, or ebuilds could just be updated as things are developed.
Either way though, parsing is a bad idea, if the goal is to produce user friendly menus. Adding every binary to a menu would just get ridiculous.
Menus should be entirely generated each time an emerge occurs, and should be generated for every wm installed. In my humble opinion anyway....
Stu
Stu |
|
Back to top |
|
|
syadnom Guru
Joined: 09 May 2002 Posts: 531
|
Posted: Tue Jul 15, 2003 9:58 pm Post subject: this should be relatively easy, here are some thoughts |
|
|
i like the idea of a directory based menu system. /usr/menu/menu-item
menu-item is a text file with the following wiht example
/usr/menu/kmplayer
command=kmplayer
icon=/usr/shared/kde/kmplayericonwhatever
add a flag in make.conf for menu generation"MENU=TRUE" and update entries into this dir.
from this directory system scripts can be made to generate menu files for the various desktop environments easily. And to regenerate these files from the directory menu system every time a new peice of software is added for removed.
if you could get someone to maintain a list in portage for menu'able items vs. nonmenu'able items then this whole system could be skipped and a script could compile a list of commands available from /usr/bin and compare it the this menu'able list to get a final gentoo linux desktop menu. The list would be for which packages are usable from a menu and which are not of course, as Kedit should be on the menu and modprobe shouldn't. Even make this system variable based on the group settings of the user, so the list would have a structure like:
# command:group
kwrite:users
konqueror:users
koncd:cdr
kportage:root |
|
Back to top |
|
|
spikkle n00b
Joined: 04 Jun 2003 Posts: 40 Location: Tech-Armpit (GA - USA)
|
Posted: Tue Jul 15, 2003 11:43 pm Post subject: |
|
|
stustill wrote: | Adding menu entries to ebuilds is the best way to do it, although it is the most tiresome way for the devs, and the one they would not appreciate.
|
There aren't a lot (by comparison) of packages that install multiple binaries, and the ones that do use each binary for a seperate "program" (think openoffice, quakeforge). Still, I don't think forcing the devs to make menu entries is a wise option. That would just be extra work, the categories are already there in the form of /usr/portage. My earlier post shows an example of this. The idea is to make an easily parsable, structured list of installed applications and their pertinent characteristics that is updated in place (so manually inserted changes are kept) whenever programs are installed or removed. Then a *seperate* program would be configured by the user to put the applications they want in their menu (either specifically, by characteristics, or by wildcard) in the chosen location. This seperate program would be able to spit out "any" menu format.
stustill wrote: | However, when spikkle is finished his program, perhaps he could be granted access to update all the ebuilds..
|
BWAHAHAHAHAHAHAH!!.... oh... *ahem*.... hmmm..
stustill wrote: | Either way though, parsing is a bad idea, if the goal is to produce user friendly menus. Adding every binary to a menu would just get ridiculous.
Menus should be entirely generated each time an emerge occurs, and should be generated for every wm installed. In my humble opinion anyway....
|
This would lead to a serious usability problem. The user is the one who should choose if they want to see every binary, just a chosen few, or all binaries based on the kinds of programs they run. Ideally, this can be determined by examing the USE flags and/or dependencies of an application, and it can be decided at runtime for the client-menu generator. The master menu file should be updated (not regenerated) each time an emerge occurs, and the user should be able to specify if they want their specific menu to be updated along with it. Of course, the client-menu generator would respect the rules they already had in place.
nickrout wrote: | lack of kde & gnome support is an issue in menumaker, as many people will want to use kde or gnome (especially newbies, who may not find it easy to hand code menu items). t seems to me that it is inherently more logical to use a system where each package determines what menu items are added, rather than some uber-program parsing packages and deciding "this is a binary, lets bung it in a menu"
|
See my earlier post.. Basically we (or I) just need to write a Gnome and KDE generator to go along with what is already in the MenuMaker source. The core itself would need to be rewritten to use the portage database instead of scanning for known executables. This way our menu generator can be dynamic in nature, and not require constant updates every time a new program is released or changes the name of its executable.
It seems like a lot of folks are misunderstanding that this master menu would be absolute or automatically blow away their hard work on their own menu. The master menu.xml file would simply contain the information needed to build any kind of menu the user needs for their WM, it would not be the menu itself. _________________ Spikkle,
It's like what forms at the corners of your mouth while you sleep, only softer, wetter, and with more substance. |
|
Back to top |
|
|
EzInKy Veteran
Joined: 11 Oct 2002 Posts: 1742 Location: Kentucky
|
Posted: Wed Jul 16, 2003 5:01 am Post subject: |
|
|
nickrout wrote: |
Leave it to the ebuild maintainers to define some menu entries for their package and include a USE variable to determine whether it is used.
as I have said twice, debian use this system already, and mandrake copied it. are gentooer's too proud or arrogant to adopt a system already in use and which works? |
No, Gentoo users aren't "too proud or arrogant". It just seems logical that the developers should concentrate on making ebuilds, and the users should concentrate on configuring their systems to their own liking. |
|
Back to top |
|
|
IamtheOne Apprentice
Joined: 27 Sep 2002 Posts: 158 Location: Iowa
|
Posted: Wed Jul 16, 2003 8:12 am Post subject: |
|
|
You guys have some crazy ideas... I have wanted an easily generated menu for a long time.
My ideal solution would have a common storage of menu items somewhere, and everytime you emerge an app that warrants a menu entry, they will be added to the common menu. This does require the admins, to update ebuilds, but it could be done over time and would be trivial to do...
In addition to the common menu, you need a client to edit your menu. Which would display your menu on the left and menu items you haven't added on the right. You could easily add or remove programs to the menu (even ones not added by portage into the master menu, root required). Also a use flag should be available to automatically add everything to the menu. (remember use flags can be enabled and disabled when you emerge an individual package) Users menus will be stored in ~/.menu or something that is only created once you start the menu editor.
With this solution, you could have nice custom menu in less than five minutes. Or you could ignore it all together and be stubborn and make your own menu.
I think this would be really easy to do (hardest thing is the menu editor). I would be willing to help (by helping update ebuilds, with the needed info)
Anywho, just my 2.5¢ |
|
Back to top |
|
|
zhenlin Veteran
Joined: 09 Nov 2002 Posts: 1361
|
Posted: Wed Jul 16, 2003 10:07 am Post subject: |
|
|
We like to reinvent the wheel. If we didn't, we'd all be using SRPMs, now wouldn't we?
Also, Mr. Robbins has shown a tendency to like XML based solutions... Look at www.gentoo.org for instance. |
|
Back to top |
|
|
nickrout Apprentice
Joined: 06 Oct 2002 Posts: 208 Location: New Zealand
|
Posted: Wed Jul 16, 2003 11:14 am Post subject: |
|
|
ok ok I was just trying to point to a useful workable existing and probably adaptable system |
|
Back to top |
|
|
spikkle n00b
Joined: 04 Jun 2003 Posts: 40 Location: Tech-Armpit (GA - USA)
|
Posted: Wed Jul 16, 2003 1:38 pm Post subject: debian menu |
|
|
nickrout wrote: | ok ok I was just trying to point to a useful workable existing and probably adaptable system |
It's certainly not a bad suggestion, and it may eventually become policy for new/updated ebuilds as gentoo evolves. The immediate problem, however, is that there are over 4,000 ebuilds which would need to be updated and I would rather not bother the maintainers with something that trivial when we can work out a solution that doesn't require changing the ebuilds themselves. As such, it can be a simple "drop-in" solution.
h3k70 has the right idea with his PHP script, but even though I write PHP for content management / MySQL, I can barely make heads or tails of some of the techniques he uses. (Hat's off to h3k70) I'd love to see a pure-python solution since that would not require any additional dependencies above portage. I've got my computer working again (hard drive crash) so I am going to get to work on one myself, as my first "real" python project.
In any case, constructive criticism is invited, so don't hold back if you have a good argument! _________________ Spikkle,
It's like what forms at the corners of your mouth while you sleep, only softer, wetter, and with more substance. |
|
Back to top |
|
|
lanius Retired Dev
Joined: 08 Dec 2002 Posts: 160
|
|
Back to top |
|
|
adumare n00b
Joined: 27 Apr 2003 Posts: 27
|
Posted: Fri Jul 18, 2003 7:04 pm Post subject: |
|
|
There is a menu system already in gentoo, I use it but it's knowhere near as good as the system in debian. It may not be for all window managers but it covers a few, the package is genmenu I think it's masked. |
|
Back to top |
|
|
h3k70 n00b
Joined: 11 Jul 2003 Posts: 14 Location: Germany
|
Posted: Fri Jul 18, 2003 7:21 pm Post subject: |
|
|
Comment from the genmenu script:
Quote: | handling 3 different menu formats in here is nasty but works. I dont want to try and understand the logic in here anymore |
That's a good point in favour of an XML based system. Anyway, genmenu's approach is different from ours: it searches for some predefined binaries that it knows about; we'd like to have any (within reasonable limits) Gentoo apps in the menu. _________________ Apocalypse now! |
|
Back to top |
|
|
gregcoit Tux's lil' helper
Joined: 12 Jun 2002 Posts: 101
|
Posted: Fri Jul 18, 2003 7:59 pm Post subject: More thoughts |
|
|
gnomenu has this to say:
Code: | menu generator for Blackbox, WindowMaker, and Enlightenment |
This leaves most of us out.
My thoughts are this - could we somehow implement the ideas from freedesktop.org (specifically http://www.freedesktop.org/standards/menu-spec/)? This could be helpful for several reasons. The most important being that someday kde and gnome (and maybe others) will support this spec and we will no longer have to build this into gentoo - it will be automatic.
Any ideas?
Greg _________________ "Life would be so much easier if we could see the source code" |
|
Back to top |
|
|
h3k70 n00b
Joined: 11 Jul 2003 Posts: 14 Location: Germany
|
Posted: Fri Jul 18, 2003 9:06 pm Post subject: |
|
|
The freedesktop.org spec is good. Now what we need is a script to make the creation of .desktop files as automatic as possible, because I don't think this will ever get anywhere if we wait for the ebuild-maintaining folks to make that stuff _________________ Apocalypse now! |
|
Back to top |
|
|
spikkle n00b
Joined: 04 Jun 2003 Posts: 40 Location: Tech-Armpit (GA - USA)
|
Posted: Sat Jul 19, 2003 4:49 am Post subject: Re: More thoughts |
|
|
Quote: | My thoughts are this - could we somehow implement the ideas from freedesktop.org (specifically http://www.freedesktop.org/standards/menu-spec/)? This could be helpful for several reasons. The most important being that someday kde and gnome (and maybe others) will support this spec and we will no longer have to build this into gentoo - it will be automatic.
Any ideas?
Greg |
Hmmm.. Yes. But I would have to say that the "freedesktop" menu style should probably be an export option (i.e. - done by a translator of the gentoo master menu file) rather than the gentoo master menu file itself. The reason being that the freedesktop menu is pretty huge, so the parser that would convert it to the actual running menu would be pretty detailed. In addition, all of this extra stuff would be "wasting space" in cases where the user is running a WM that doesn't (and likely never will) conform to the freedesktop standard.. like Blackbox, Windowmaker, etc.
So the freedesktop menu is as good an idea as any on paper, I think it is a lot more than is really needed for the "Gentoo Common Menu" master file. As an export though (and eventually the common export format for both KDE and Gnome, I presume) it is certainly viable, and best left to the user to decide how it should be configured. My personal goal for this project is that the "Gentoo Common Menu" be as innert as possible, leaving all manner of customization to be done on part of a user modifiable rules system to generate the appropriate menu format for their WM of choice.
I'm about halfway through the proof of concept python program to generate the master file (sorry it takes so long, I'm learning python as I go.. I'm used to C and C++). Once we have established the proper structure and included data for the common menu, we can get to work on the translators.
Cheers. _________________ Spikkle,
It's like what forms at the corners of your mouth while you sleep, only softer, wetter, and with more substance. |
|
Back to top |
|
|
lanius Retired Dev
Joined: 08 Dec 2002 Posts: 160
|
Posted: Sat Jul 19, 2003 10:23 am Post subject: |
|
|
Well i don't know if anybody of you read my link i posted, but anywhere ...
There is work being done by me (lanius@gentoo.org) and svyatogor(@gentoo.org).
We wan't to implement the desktop file specification and menu specification by freedesktop.org in python and then make a menu generation tool out of that.
You can see the work currently done at http://cvs.cojobo.net/cgi-bin/viewcvs.cgi/gentoo-menu/.
Help is always welcome |
|
Back to top |
|
|
TRauMa n00b
Joined: 26 Nov 2002 Posts: 43 Location: Germany
|
Posted: Sat Jul 19, 2003 1:35 pm Post subject: icewm |
|
|
Just to throw my favourite wm in: icewm needs no help, it can parse .desktop files when installed with gnome useflag. I already use this to import the gnome menu into my desktop/wm/whatever. |
|
Back to top |
|
|
h3k70 n00b
Joined: 11 Jul 2003 Posts: 14 Location: Germany
|
Posted: Sat Jul 19, 2003 2:52 pm Post subject: |
|
|
heino:
Yeah, noticed it. But at the time of your first post cvs.cojobo.net was unreachable from where I sit
Anyway, the stuff you've got there looks cool (I'd like to say more but I can't really read Python (or whatever you use )). Does it work? Do you already have the .desktop files? _________________ Apocalypse now! |
|
Back to top |
|
|
lanius Retired Dev
Joined: 08 Dec 2002 Posts: 160
|
Posted: Sat Jul 19, 2003 3:36 pm Post subject: |
|
|
Well the .desktop parser is working fine, it parses .desktop files, checks for syntax errors and has a nice api to access the files. The .menu parser still needs a lot of work to be done (help is always welcome).
[edit]
Yes, it's python
Regarding the .desktop entries for the apps, I would propose to create one for each app (they are only needed for gui apps) and include them in the files dir. But this should be done when we have the basic parser and converters for the different wm's working
[/edit] |
|
Back to top |
|
|
zhenlin Veteran
Joined: 09 Nov 2002 Posts: 1361
|
Posted: Sun Jul 20, 2003 3:32 am Post subject: |
|
|
I feel it is better to use a large XML master file or a folder & XML file organisation, so that existing parsers and more tools can be taken advantage of... But you're already doing that for menus. So, why not use XML for menu items as well? Why not use XSLT to create desktop files?
XSLT:
Code: |
<?xml version="1.0" ?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output encoding="utf-8" method="text" indent="no" />
<xsl:strip-space elements="*" />
<xsl:template match="desktopentry">
<xsl:text>[</xsl:text>
<xsl:if test="@prefix">
<xsl:value-of select="@prefix" />
<xsl:text> </xsl:text>
</xsl:if>
<xsl:text>Desktop Entry]
</xsl:text>
<xsl:text>Encoding: UTF-8
</xsl:text>
<xsl:apply-templates />
</xsl:template>
<xsl:template match="version">
<xsl:text>Version=</xsl:text><xsl:value-of select="." /><xsl:text>
</xsl:text>
</xsl:template>
<xsl:template match="type">
<xsl:text>Type=</xsl:text><xsl:value-of select="." /><xsl:text>
</xsl:text>
</xsl:template>
<xsl:template match="name">
<xsl:text>Name</xsl:text>
<xsl:if test="@xml:lang">
<xsl:text>[</xsl:text>
<xsl:value-of select="translate(@xml:lang, '-', '_')" />
<xsl:text>]</xsl:text>
</xsl:if>
<xsl:text>=</xsl:text>
<xsl:value-of select="." /><xsl:text>
</xsl:text>
</xsl:template>
<xsl:template match="icon">
<xsl:text>Icon</xsl:text>
<xsl:if test="@xml:lang">
<xsl:text>[</xsl:text>
<xsl:value-of select="translate(@xml:lang, '-', '_')" />
<xsl:text>]</xsl:text>
</xsl:if>
<xsl:text>=</xsl:text>
<xsl:value-of select="@loc" /><xsl:text>
</xsl:text>
</xsl:template>
<xsl:template match="comment">
<xsl:text>Comment</xsl:text>
<xsl:if test="@xml:lang">
<xsl:text>[</xsl:text>
<xsl:value-of select="translate(@xml:lang, '-', '_')" />
<xsl:text>]</xsl:text>
</xsl:if>
<xsl:text>=</xsl:text>
<xsl:value-of select="." /><xsl:text>
</xsl:text>
</xsl:template>
<xsl:template match="tryexec">
<xsl:text>TryExec=</xsl:text><xsl:value-of select="." /><xsl:text>
</xsl:text>
</xsl:template>
<xsl:template match="exec">
<xsl:text>Exec=</xsl:text><xsl:value-of select="." /><xsl:text>
</xsl:text>
</xsl:template>
<xsl:template match="accepts">
<xsl:apply-templates select="mimetype" />
</xsl:template>
<xsl:template match="mimetype">
<xsl:text>MimeType=</xsl:text><xsl:value-of select="." /><xsl:text>
</xsl:text>
</xsl:template>
<xsl:template match="xtag">
<xsl:text>X-</xsl:text>
<xsl:value-of select="@name" />
<xsl:if test="@xml:lang">
<xsl:text>[</xsl:text>
<xsl:value-of select="translate(@xml:lang, '-', '_')" />
<xsl:text>]</xsl:text>
</xsl:if>
<xsl:text>=</xsl:text>
<xsl:value-of select="." /><xsl:text>
</xsl:text>
</xsl:template>
<xsl:template match="tag">
<xsl:value-of select="@name" />
<xsl:if test="@xml:lang">
<xsl:text>[</xsl:text>
<xsl:value-of select="translate(@xml:lang, '-', '_')" />
<xsl:text>]</xsl:text>
</xsl:if>
<xsl:text>=</xsl:text>
<xsl:value-of select="." /><xsl:text>
</xsl:text>
</xsl:template>
<xsl:template match="categories">
<xsl:text>Categories=</xsl:text>
<xsl:for-each select="category">
<xsl:value-of select="." />
<xsl:if test="position()!=last()"><xsl:text>; </xsl:text></xsl:if>
</xsl:for-each><xsl:text>
</xsl:text>
</xsl:template>
<xsl:template match="desktopaction">
<xsl:text>[Desktop Action </xsl:text><xsl:value-of select="@name" /><xsl:text>]
</xsl:text>
<xsl:apply-templates />
</xsl:template>
<xsl:template match="section">
<xsl:text>[</xsl:text><xsl:value-of select="@name" /><xsl:text>]</xsl:text><xsl:text>
</xsl:text>
<xsl:apply-templates />
</xsl:template>
</xsl:stylesheet>
|
Input:
Code: |
<?xml version="1.0" ?>
<desktop>
<desktopentry prefix="KDE">
<version>1.0</version>
<type>Application</type>
<name>Foo Viewer</name>
<name xml:lang="ru">Имя</name>
<name xml:lang="de-DE">Test</name>
<icon loc="some" />
<comment>The best viewer for Foo objects available!</comment>
<tryexec>fooview</tryexec>
<exec>fooview %F</exec>
<icon loc="fooview.png" />
<accepts>
<mimetype>image/x-foo</mimetype>
</accepts>
<xtag name="KDE-Library">libfooview</xtag>
<xtag name="KDE-FactoryName">fooviewfactory</xtag>
<xtag name="KDE-ServiceType">FooService</xtag>
<tag name="MiniIcon">test.ico</tag>
<categories></categories>
</desktopentry>
<desktopaction name="Inverse">
<exec>fooview --inverse %f</exec>
<name>Foo Viewer (inverse image)</name>
</desktopaction>
<desktopaction name="Edit">
<exec>fooview --edit %f</exec>
<name>Foo Viewer (edit image)</name>
<icon loc="fooviewer-edit.png" />
</desktopaction>
</desktop>
|
Output:
Code: |
[KDE Desktop Entry]
Encoding=UTF-8
Version=1.0
Type=Application
Name=Foo Viewer
Name[ru]=??????
Name[de_DE]=Test
Icon=some
Comment=The best viewer for Foo objects available!
TryExec=fooview
Exec=fooview %F
Icon=fooview.png
MimeType=image/x-foo
X-KDE-Library=libfooview
X-KDE-FactoryName=fooviewfactory
X-KDE-ServiceType=FooService
MiniIcon=test.ico
Categories=
[Desktop Action Inverse]
Exec=fooview --inverse %f
Name=Foo Viewer (inverse image)
[Desktop Action Edit]
Exec=fooview --edit %f
Name=Foo Viewer (edit image)
Icon=fooviewer-edit.png
|
Last edited by zhenlin on Sun Jul 20, 2003 8:09 am; edited 1 time in total |
|
Back to top |
|
|
jstubbs Retired Dev
Joined: 05 Jul 2003 Posts: 126 Location: Tokyo
|
Posted: Sun Jul 20, 2003 5:32 am Post subject: |
|
|
Hello all,
I've been following this discussion for the last week and last night the possibilites grabbed me. What I'm mostly interested in is trying to build the menu without knowledge of all the possible menu items. I've thrown together a small python program to test some of the ideas that were laid out on page 1. Currently, it looks over all installed packages via /var/db/pkg/, skips over any "masked" packages and then searches for binaries in specified directories. I added the spec. dirs bit after because the program was finding xpm files in /usr/share/icons/ and all sorts of things that probably shouldn't be executable. Anyway, forgive the coding style as it is my first attempt at python. Most of the variable names are self-explanatory but I got a bit impatient to think up nice names toward the end. Anyway, here 'tis:
Code: | #!/bin/env python
import sys
import stat
import dircache
import string
import os
topdir = '/var/db/pkg/'
menudir = '/home/jason/testmenu/'
bindirs = ['/bin','/sbin','/usr/bin','/usr/sbin','/usr/X11R6/bin','/usr/games/bin','/usr/kde/3.1/bin']
maskpkgs = ['gnome','kde','dev-libs','media-libs','sys','x11']
fspkg = dircache.listdir(topdir)
for pkg in fspkg:
idx = string.find(pkg,'-')
maj = pkg[:idx] + '/'
min = pkg[idx+1:] + '/'
pkgdir = menudir + maj + min
apps = dircache.listdir(topdir + pkg)
for app in apps:
masked = 0
for mask in maskpkgs:
if string.find(pkg + '/' + app, mask) == 0:
masked = 1
if not masked:
fd = open(topdir + pkg + '/' + app + '/CONTENTS')
line = fd.readline()
while line <> '':
idx = string.find(line,' ')
type = line[:idx]
line = line[idx+1:]
idx = string.find(line,' ')
file = line[:idx]
if os.access(file,os.X_OK) and not stat.S_ISDIR(os.stat(file)[stat.ST_MODE]):
for path in bindirs:
if string.find(file, path) == 0:
if not os.access(pkgdir, os.F_OK):
os.makedirs(pkgdir)
de = open(menudir + maj + min + file[string.rfind(file,'/')+1:],'w')
de.write(app)
de.close()
line = fd.readline()
fd.close() |
As you can see, I masked gnome and kde as was talked about earlier, but also masked all the lib dirs as well as sys-* and x11-*. This is because the output for all the lib dirs was pretty much useless and the output for sys-* and x11-* was similar in nature to (but worse than) app-text or app-i18n below. Here's the created menu tree on my box:
Code: | testmenu/
|-- app
| |-- admin
| | |-- addpatches
| | |-- consolelog.sh
| | |-- dep-clean
| | |-- echangelog
| | |-- ekeyword
| | |-- etcat
| | |-- euse
| | |-- fam
| | |-- gentoo-stats
| | |-- gentool-author-coverage
| | |-- gentool-bump-revision
| | |-- gentool-package-count
| | |-- gentool-total-coverage
| | |-- kportage
| | |-- metalog
| | |-- mkebuild
| | |-- pkg-clean
| | |-- pkg-size
| | |-- qpkg
| | |-- sudo
| | `-- visudo
| |-- arch
| | |-- cabextract
| | |-- compress
| | |-- funzip
| | |-- uncompress
| | |-- unzip
| | |-- unzipsfx
| | |-- zip
| | |-- zipcloak
| | |-- zipgrep
| | |-- zipinfo
| | |-- zipnote
| | `-- zipsplit
| |-- cdr
| | |-- arson
| | |-- cdda2wav
| | |-- cdrdao
| | |-- cdrecord
| | |-- devdump
| | |-- gcdmaster
| | |-- isodump
| | |-- isoinfo
| | |-- isovfy
| | |-- mkisofs
| | |-- mp32dao.pl
| | `-- readcd
| |-- editors
| | `-- nano
| |-- emulation
| | |-- regedit-wine
| | `-- wine
| |-- games
| | |-- llsndserv
| | |-- llxdoom
| | |-- ltris
| | |-- musserver
| | |-- q2ded
| | |-- q2ded-qmax
| | |-- q3ded
| | |-- quake2
| | |-- quake2-qmax
| | |-- quake3
| | |-- sdlquake2
| | |-- sdlquake2-qmax
| | `-- tuxracer
| |-- i18n
| | |-- addwords
| | |-- canlisp
| | |-- cannacheck
| | |-- cannakill
| | |-- cannaserver
| | |-- cannastat
| | |-- catdic
| | |-- chmoddic
| | |-- cpdic
| | |-- crfreq
| | |-- crxdic
| | |-- crxgram
| | |-- cshost
| | |-- ctow
| | |-- delwords
| | |-- dicar
| | |-- dpbindic
| | |-- dpromdic
| | |-- dpxdic
| | |-- forcpp
| | |-- forsort
| | |-- kinput2
| | |-- kpdic
| | |-- lsdic
| | |-- mergeword
| | |-- mkbindic
| | |-- mkdic
| | |-- mkromdic
| | |-- mvdic
| | |-- rmdic
| | |-- splitword
| | |-- syncdic
| | |-- update-canna-dics_dir
| | `-- wtoc
| |-- office
| | |-- dump-finance-quote
| | |-- gnc-prices
| | |-- gnc-test-env
| | |-- gnucash
| | |-- gnucash-config
| | |-- gnucash-env
| | |-- gnucash-make-guids
| | |-- gnucash-run-script
| | |-- karbon
| | |-- kchart
| | |-- kformula
| | |-- kivio
| | |-- koconverter
| | |-- kontour
| | |-- koscript
| | |-- koshell
| | |-- kprconverter.pl
| | |-- kpresenter
| | |-- kspread
| | |-- kthesaurus
| | |-- kudesigner
| | |-- kugar
| | |-- kword
| | |-- oocalc
| | |-- oodraw
| | |-- ooffice
| | |-- ooimpress
| | |-- oomath
| | |-- oopadmin
| | |-- oosetup
| | |-- oowriter
| | `-- update-finance-quote
| |-- shells
| | |-- bash
| | |-- bashbug
| | |-- csh
| | |-- sash
| | |-- sh
| | `-- tcsh
| `-- text
| |-- bdftops
| |-- build-docbook-catalog
| |-- collateindex.pl
| |-- dgs-config
| |-- docbook2dvi
| |-- docbook2html
| |-- docbook2man
| |-- docbook2pdf
| |-- docbook2ps
| |-- docbook2rtf
| |-- docbook2tex
| |-- docbook2texi
| |-- docbook2txt
| |-- dpsexec
| |-- dpsnx.agent
| |-- dvipdf
| |-- eps2eps
| |-- fixmswrd.pl
| |-- font2c
| |-- gs
| |-- gsbj
| |-- gsdj
| |-- gsdj500
| |-- gslj
| |-- gslp
| |-- gsnd
| |-- ijs-config
| |-- ijs_client_example
| |-- install-catalog
| |-- jade
| |-- jw
| |-- lprsetup.sh
| |-- makepsres
| |-- nsgmls
| |-- onsgmls
| |-- openjade
| |-- osgmlnorm
| |-- ospam
| |-- ospcat
| |-- ospent
| |-- osx
| |-- pdf2dsc
| |-- pdf2ps
| |-- pdffonts
| |-- pdfimages
| |-- pdfinfo
| |-- pdfopt
| |-- pdftopbm
| |-- pdftops
| |-- pdftotext
| |-- pf2afm
| |-- pfbtopfa
| |-- pj-gs.sh
| |-- printafm
| |-- ps2ascii
| |-- ps2epsi
| |-- ps2pdf
| |-- ps2pdf12
| |-- ps2pdf13
| |-- ps2pdf14
| |-- ps2pdfwr
| |-- ps2ps
| |-- pswrap
| |-- pv.sh
| |-- scrollkeeper-config
| |-- scrollkeeper-extract
| |-- scrollkeeper-gen-seriesid
| |-- scrollkeeper-get-cl
| |-- scrollkeeper-get-content-list
| |-- scrollkeeper-get-extended-content-list
| |-- scrollkeeper-get-index-from-docpath
| |-- scrollkeeper-get-toc-from-docpath
| |-- scrollkeeper-get-toc-from-id
| |-- scrollkeeper-install
| |-- scrollkeeper-preinstall
| |-- scrollkeeper-rebuilddb
| |-- scrollkeeper-uninstall
| |-- scrollkeeper-update
| |-- sgml2xml
| |-- sgmldiff
| |-- sgmlnorm
| |-- sgmlwhich
| |-- spam
| |-- spent
| |-- sysvlp.sh
| |-- texteroids
| |-- tree
| |-- unix-lpr.sh
| |-- wftopfa
| |-- xepsf
| `-- xpdf
|-- dev
| |-- cpp
| | |-- gtkmm-config
| | `-- gtkmmconvert
| |-- db
| | |-- ApplySnapshot
| | |-- CleanLog
| | |-- GetSyncID
| | |-- InitRservTest
| | |-- MasterAddTable
| | |-- MasterInit
| | |-- MasterSync
| | |-- PrepareSnapshot
| | |-- Replicate
| | |-- RservTest
| | |-- SlaveAddTable
| | |-- SlaveInit
| | |-- clusterdb
| | |-- createdb
| | |-- createlang
| | |-- createuser
| | |-- dbf2pg
| | |-- dropdb
| | |-- droplang
| | |-- dropuser
| | |-- ecpg
| | |-- findoidjoins
| | |-- fti.pl
| | |-- initdb
| | |-- initlocation
| | |-- ipcclean
| | |-- knoda
| | |-- make_oidjoins_check
| | |-- oid2name
| | |-- pg_config
| | |-- pg_controldata
| | |-- pg_ctl
| | |-- pg_dump
| | |-- pg_dumpall
| | |-- pg_dumplo
| | |-- pg_encoding
| | |-- pg_id
| | |-- pg_logger
| | |-- pg_resetxlog
| | |-- pg_restore
| | |-- pgbench
| | |-- postgres
| | |-- postmaster
| | |-- psql
| | |-- vacuumdb
| | `-- vacuumlo
| |-- java
| | |-- ant
| | |-- antRun
| | |-- complete-ant-cmd.pl
| | |-- java-config
| | |-- runant.pl
| | `-- runant.py
| |-- lang
| | |-- a2p
| | |-- c2ph
| | |-- dprofpp
| | |-- enc2xs
| | |-- find2perl
| | |-- h2ph
| | |-- h2xs
| | |-- ldrdf
| | |-- libnetcfg
| | |-- nasm
| | |-- ndisasm
| | |-- perl
| | |-- perl5.8.0
| | |-- perlbug
| | |-- perlcc
| | |-- perldoc
| | |-- perlivp
| | |-- piconv
| | |-- pl2pm
| | |-- pod2html
| | |-- pod2latex
| | |-- pod2man
| | |-- pod2text
| | |-- pod2usage
| | |-- podchecker
| | |-- podselect
| | |-- psed
| | |-- pstruct
| | |-- pydoc
| | |-- python
| | |-- python-config
| | |-- python2
| | |-- python2.2
| | |-- rdf2bin
| | |-- rdf2com
| | |-- rdf2ihx
| | |-- rdfdump
| | |-- rdflib
| | |-- rdx
| | |-- s2p
| | |-- sperl5.8.0
| | |-- splain
| | |-- suidperl
| | |-- swig
| | |-- tclsh
| | |-- tclsh8.4
| | |-- wish
| | |-- wish8.4
| | `-- xsubpp
| |-- perl
| | |-- GET
| | |-- HEAD
| | |-- POST
| | |-- decode-base64
| | |-- decode-qp
| | |-- encode-base64
| | |-- encode-qp
| | |-- lwp-download
| | |-- lwp-mirror
| | |-- lwp-request
| | |-- lwp-rget
| | |-- pod2usage
| | |-- podchecker
| | |-- podselect
| | |-- sa-learn
| | |-- sgmlspl
| | |-- spamassassin
| | |-- spamc
| | `-- spamd
| `-- util
| |-- antlr
| |-- ccache
| |-- ccache-config
| |-- cvs
| |-- cvsbug
| |-- dialog
| |-- dlg
| |-- genmk
| |-- guile
| |-- guile-config
| |-- guile-snarf
| |-- guile-tools
| |-- indent
| |-- intltool-extract
| |-- intltool-merge
| |-- intltool-prepare
| |-- intltool-unicodify
| |-- intltool-update
| |-- intltoolize
| |-- netbeans
| |-- pkg-config
| |-- rcs2log
| |-- sor
| |-- texinfo2man
| |-- xml-i18n-toolize
| `-- yacc
|-- media
| |-- gfx
| | |-- Magick++-config
| | |-- Magick-config
| | |-- animate
| | |-- composite
| | |-- conjure
| | |-- convert
| | |-- display
| | |-- identify
| | |-- import
| | |-- mogrify
| | |-- montage
| | `-- pixie
| |-- sound
| | |-- abxtest
| | |-- aconnect
| | |-- alsactl
| | |-- alsamixer
| | |-- amixer
| | |-- aplay
| | |-- arecord
| | |-- aseqnet
| | |-- bladeenc
| | |-- cdparanoia
| | |-- esd
| | |-- esd-config
| | |-- esdcat
| | |-- esdctl
| | |-- esddsp
| | |-- esdfilt
| | |-- esdloop
| | |-- esdmon
| | |-- esdplay
| | |-- esdrec
| | |-- esdsample
| | |-- lame
| | |-- madplay
| | |-- mp3rtp
| | |-- mp3x
| | |-- mpg123
| | |-- normalize
| | |-- normalize-mp3
| | |-- normalize-ogg
| | |-- wmxmms
| | |-- xmms
| | `-- xmms-config
| `-- video
| |-- NVmakedevices.sh
| |-- avibench
| |-- avicap
| |-- avicat
| |-- avifile-config
| |-- avimake
| |-- aviplay
| |-- avirec
| |-- avirecompress
| |-- avitype
| |-- ffmpeg
| |-- ffplay
| |-- ffserver
| |-- gmplayer
| |-- kv4lsetup
| |-- mencoder
| |-- mpeg2decode
| |-- mpeg2encode
| |-- mplayer
| `-- xanim
`-- net
|-- dialup
| |-- chat
| |-- plog
| |-- poff
| |-- pon
| |-- pppd
| |-- pppdump
| `-- pppstats
|-- dns
| |-- dig
| |-- dnssec-keygen
| |-- dnssec-makekeyset
| |-- dnssec-signkey
| |-- dnssec-signzone
| |-- host
| |-- isc-config.sh
| |-- lwresd
| |-- named
| |-- named-checkconf
| |-- named-checkzone
| |-- nslookup
| |-- nsupdate
| |-- rndc
| `-- rndc-confgen
|-- ftp
| `-- ftp
|-- libs
| `-- linc-config
|-- mail
| |-- fetchmail
| |-- fetchmailconf
| |-- hotwayd
| |-- mailq
| |-- newaliases
| |-- postalias
| |-- postcat
| |-- postconf
| |-- postdrop
| |-- postfix
| |-- postkick
| |-- postlock
| |-- postlog
| |-- postmap
| |-- postqueue
| |-- postsuper
| |-- razor-client
| |-- rmail
| `-- sendmail
|-- misc
| |-- arping
| |-- clockdiff
| |-- dhcpcd
| |-- ipg
| |-- ntp-genkeys
| |-- ntp-wait
| |-- ntpd
| |-- ntpdate
| |-- ntpdc
| |-- ntpq
| |-- ntptime
| |-- ntptimeset
| |-- ntptrace
| |-- ping
| |-- ping6
| |-- rarpd
| |-- rdisc
| |-- rsync
| |-- scp
| |-- sftp
| |-- slogin
| |-- ssh
| |-- ssh-add
| |-- ssh-agent
| |-- ssh-keygen
| |-- ssh-keyscan
| |-- sshd
| |-- tftpd
| |-- tickadj
| |-- tracepath
| |-- tracepath6
| |-- traceroute6
| `-- wget
|-- nds
| |-- pmap_dump
| |-- pmap_set
| `-- portmap
|-- p2p
| |-- giFT
| |-- giFT-setup
| `-- giFTcurs
`-- print
|-- accept
|-- cancel
|-- cups-config
|-- cupsaddsmb
|-- cupsd
|-- cupstestppd
|-- disable
|-- enable
|-- lp
|-- lpadmin
|-- lpc
|-- lpinfo
|-- lpmove
|-- lpoptions
|-- lppasswd
|-- lpq
|-- lpr
|-- lprm
|-- lpstat
`-- reject
32 directories, 538 files |
As you can see, there's heaps of stuff in there that has no need to be in there at all. My original thought was that this could be fixed by masking specific packages, in the form of app-text/docbook for example, which is working already. However, looking at app-office, there are several entries created from gnucash which aren't needed.
I think this is the biggest stepping stone. Telling a console app from an X app could be accomplished using elf-utils to scan through the library dependencies looking for a link to X. Finding an icon for an app could be achieved by scanning through the CONTENTS file looking for an icon with a matching name to the binary. Making a generic menu in any format to be exported to others is piss easy (but a lot of work). It seems the most difficult thing (algorithmically) is figuring out what requires a menu item.
IamtheOne had an idea of a menu editing application but, even with a fancy gui, going through the generated menus above would still take several hours. By the way, adding in sys-* and x11-* generates >1000 more entries. I didn't want to include it as this post is already long enough.
Anybody have any ideas on how to limit the menu to useful stuff? Kind of reminds me of dealing with spam - want to get rid of as much as possible without losing anything that should be there.
Regards,
Jason |
|
Back to top |
|
|
lanius Retired Dev
Joined: 08 Dec 2002 Posts: 160
|
|
Back to top |
|
|
jstubbs Retired Dev
Joined: 05 Jul 2003 Posts: 126 Location: Tokyo
|
Posted: Sun Jul 20, 2003 8:25 am Post subject: |
|
|
I realise that the solution is not to make my own project. I'm sure you can tell from looking at what I have done that I don't have the experience. What I am trying to do is help others with their efforts. All the projects I have seen all require the ebuild maintainers to specify which application should have what icon and should go where. What I was interested in was the idea coming at the problem from the other side and attempting to build a menu without a knowledge of all the applications. I haven't read anywhere that the idea has been abandoned so I just threw together a little prototype to test the concept. In my previous post, I published the results.
You need help with the parser for menu files. I know this; you said it twice before. I can't offer too much help there. What I'm wondering, though, is where do these "menu files" come from? If it will require changes to portage, ebuilds, etc. then it will be a long time coming.
[edit]
Okay, I've looked back and see that you are planning on creating all the desktop entries for each application manually. I agree this is the best way, but who maintain's it?
[/edit]
Jason |
|
Back to top |
|
|
lanius Retired Dev
Joined: 08 Dec 2002 Posts: 160
|
Posted: Sun Jul 20, 2003 9:23 am Post subject: |
|
|
The maintainers of the ebuilds should at least include a basic file (many gui applications already do this). I think this should be done simply with the next release of the package in portage. Then we need some i18n people to translate the descriptions, etc. I also think there would be no problem to get another (new) dev to do that.
mfg, Heinrich |
|
Back to top |
|
|
h3k70 n00b
Joined: 11 Jul 2003 Posts: 14 Location: Germany
|
Posted: Sun Jul 20, 2003 2:33 pm Post subject: |
|
|
jason:
The biggest obstacle to auto-detection of programmes is whether to run them in a console. And there just isn't a way that works for everything. Things like that really have to be done manually. _________________ Apocalypse now! |
|
Back to top |
|
|
lanius Retired Dev
Joined: 08 Dec 2002 Posts: 160
|
Posted: Sun Jul 20, 2003 4:09 pm Post subject: |
|
|
And you won't end up in every app listened in the menu, e.g. why would you wan't to have apache in the menu? |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|