Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Gentoo Common Menu
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3, 4, 5, 6  Next  
Reply to topic    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
stustill
Guru
Guru


Joined: 25 Feb 2003
Posts: 333
Location: Aberdeen, Scotland

PostPosted: Tue Jul 15, 2003 9:42 pm    Post subject: Reply with quote

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
View user's profile Send private message
syadnom
Guru
Guru


Joined: 09 May 2002
Posts: 531

PostPosted: Tue Jul 15, 2003 9:58 pm    Post subject: this should be relatively easy, here are some thoughts Reply with quote

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
View user's profile Send private message
spikkle
n00b
n00b


Joined: 04 Jun 2003
Posts: 40
Location: Tech-Armpit (GA - USA)

PostPosted: Tue Jul 15, 2003 11:43 pm    Post subject: Reply with quote

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
View user's profile Send private message
EzInKy
Veteran
Veteran


Joined: 11 Oct 2002
Posts: 1742
Location: Kentucky

PostPosted: Wed Jul 16, 2003 5:01 am    Post subject: Reply with quote

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
View user's profile Send private message
IamtheOne
Apprentice
Apprentice


Joined: 27 Sep 2002
Posts: 158
Location: Iowa

PostPosted: Wed Jul 16, 2003 8:12 am    Post subject: Reply with quote

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.:roll:

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
View user's profile Send private message
zhenlin
Veteran
Veteran


Joined: 09 Nov 2002
Posts: 1361

PostPosted: Wed Jul 16, 2003 10:07 am    Post subject: Reply with quote

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
View user's profile Send private message
nickrout
Apprentice
Apprentice


Joined: 06 Oct 2002
Posts: 208
Location: New Zealand

PostPosted: Wed Jul 16, 2003 11:14 am    Post subject: Reply with quote

ok ok I was just trying to point to a useful workable existing and probably adaptable system :-)
Back to top
View user's profile Send private message
spikkle
n00b
n00b


Joined: 04 Jun 2003
Posts: 40
Location: Tech-Armpit (GA - USA)

PostPosted: Wed Jul 16, 2003 1:38 pm    Post subject: debian menu Reply with quote

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! :twisted:
_________________
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
View user's profile Send private message
lanius
Retired Dev
Retired Dev


Joined: 08 Dec 2002
Posts: 160

PostPosted: Wed Jul 16, 2003 4:54 pm    Post subject: Reply with quote

https://bugs.gentoo.org/show_bug.cgi?id=18638
Back to top
View user's profile Send private message
adumare
n00b
n00b


Joined: 27 Apr 2003
Posts: 27

PostPosted: Fri Jul 18, 2003 7:04 pm    Post subject: Reply with quote

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
View user's profile Send private message
h3k70
n00b
n00b


Joined: 11 Jul 2003
Posts: 14
Location: Germany

PostPosted: Fri Jul 18, 2003 7:21 pm    Post subject: Reply with quote

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
View user's profile Send private message
gregcoit
Tux's lil' helper
Tux's lil' helper


Joined: 12 Jun 2002
Posts: 101

PostPosted: Fri Jul 18, 2003 7:59 pm    Post subject: More thoughts Reply with quote

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
View user's profile Send private message
h3k70
n00b
n00b


Joined: 11 Jul 2003
Posts: 14
Location: Germany

PostPosted: Fri Jul 18, 2003 9:06 pm    Post subject: Reply with quote

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
View user's profile Send private message
spikkle
n00b
n00b


Joined: 04 Jun 2003
Posts: 40
Location: Tech-Armpit (GA - USA)

PostPosted: Sat Jul 19, 2003 4:49 am    Post subject: Re: More thoughts Reply with quote

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
View user's profile Send private message
lanius
Retired Dev
Retired Dev


Joined: 08 Dec 2002
Posts: 160

PostPosted: Sat Jul 19, 2003 10:23 am    Post subject: Reply with quote

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
View user's profile Send private message
TRauMa
n00b
n00b


Joined: 26 Nov 2002
Posts: 43
Location: Germany

PostPosted: Sat Jul 19, 2003 1:35 pm    Post subject: icewm Reply with quote

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
View user's profile Send private message
h3k70
n00b
n00b


Joined: 11 Jul 2003
Posts: 14
Location: Germany

PostPosted: Sat Jul 19, 2003 2:52 pm    Post subject: Reply with quote

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
View user's profile Send private message
lanius
Retired Dev
Retired Dev


Joined: 08 Dec 2002
Posts: 160

PostPosted: Sat Jul 19, 2003 3:36 pm    Post subject: Reply with quote

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
View user's profile Send private message
zhenlin
Veteran
Veteran


Joined: 09 Nov 2002
Posts: 1361

PostPosted: Sun Jul 20, 2003 3:32 am    Post subject: Reply with quote

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
View user's profile Send private message
jstubbs
Retired Dev
Retired Dev


Joined: 05 Jul 2003
Posts: 126
Location: Tokyo

PostPosted: Sun Jul 20, 2003 5:32 am    Post subject: Reply with quote

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. :roll:

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. :lol:

Regards,
Jason
Back to top
View user's profile Send private message
lanius
Retired Dev
Retired Dev


Joined: 08 Dec 2002
Posts: 160

PostPosted: Sun Jul 20, 2003 8:06 am    Post subject: Reply with quote

The solution is to not make your own project but help in our efforts. As i said we need help with the parser for menu files (http://www.freedesktop.org/standards/menu-spec/).
Back to top
View user's profile Send private message
jstubbs
Retired Dev
Retired Dev


Joined: 05 Jul 2003
Posts: 126
Location: Tokyo

PostPosted: Sun Jul 20, 2003 8:25 am    Post subject: Reply with quote

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
View user's profile Send private message
lanius
Retired Dev
Retired Dev


Joined: 08 Dec 2002
Posts: 160

PostPosted: Sun Jul 20, 2003 9:23 am    Post subject: Reply with quote

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
View user's profile Send private message
h3k70
n00b
n00b


Joined: 11 Jul 2003
Posts: 14
Location: Germany

PostPosted: Sun Jul 20, 2003 2:33 pm    Post subject: Reply with quote

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
View user's profile Send private message
lanius
Retired Dev
Retired Dev


Joined: 08 Dec 2002
Posts: 160

PostPosted: Sun Jul 20, 2003 4:09 pm    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Portage & Programming All times are GMT
Goto page Previous  1, 2, 3, 4, 5, 6  Next
Page 2 of 6

 
Jump to:  
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