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

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


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

PostPosted: Fri Jul 11, 2003 10:25 pm    Post subject: Gentoo Common Menu Reply with quote

Hi,

I was wondering if there are plans to implement a common program menu in gentoo that is updated when new packages are emerged. Nothing fancy, the same basic categories as are in /usr/portage, except links to the files placed in an executable location like /usr/bin.

Debian does a pretty good job of this, as do a lot of other distros.. Is it feasible for gentoo? I'm reasonably proficient in Python, does this sound like a trivial addition?

Perhaps the best way to go about it would be an XML file describing the entries with flags like system, console, X, gtk, qt, in a format like this:
Code:

<menu>
    <app-admin>
        <superadduser type="system">/sbin/adduser</superadduser>
        .
        .
     </app-admin>
     .
     .
     <gnome-office>
         <abiword type="gtk">/usr/bin/abiword</abiword>
          .
          .
      </gnome-office>
      .
      .
      <net-www>
          <links type="console">/usr/bin/links</links>
          .
          .
      </net-www>
      .
      .
</menu>

So you get the idea. It seems like it would be simple enough to make a small program that would parse /var/db/pkg and build the menu by looking for items placed in /usr/bin, but I'm not sure if it could have the ability to discern which packages need to be in the menu (abiword), and which do not (modprobe). The menu file could be parsed easily enough by seperate scripts (or XSL?) to generate menus for the chosen WM (*box, gnome, kde...)

Any ideas, nitpicks, or support?
_________________
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
stustill
Guru
Guru


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

PostPosted: Fri Jul 11, 2003 11:52 pm    Post subject: Reply with quote

I like this idea. What would be really good, is if it was fully part of portage, but optional, perhaps with a USE flag to enable its use. That way it can easily be enabled or disabled. Any time a package is emerged, if appropriate it is added to the menu. Its position within the menu could be specified within the package's ebuild.

And the menu layout would have to be brilliantly designed, or really customizable!

Stu
Back to top
View user's profile Send private message
kesuari
n00b
n00b


Joined: 18 May 2003
Posts: 63

PostPosted: Mon Jul 14, 2003 2:07 pm    Post subject: Reply with quote

stustill wrote:
I like this idea. What would be really good, is if it was fully part of portage, but optional, perhaps with a USE flag to enable its use. That way it can easily be enabled or disabled.


<situation type="hypothetical">
I have it disabled because I'm the only one using my box and I don't use a windowmanager with menus.

I move to a shared house and the other person there has no computer. I have two, but the second one is too slow to run any reasonable operating system at a reasonable speed in this day and age, so I hook it up to my main box as a dumb X terminal.

Having showed the other person my desktop and Gnome (being the only two options I have compiled on my box, having no need for anything else), they choose Gnome. So I add "menu" to my USE flags, but I already have a fully working desktop box.
</situation>

Will the Gentoo menu be empty until an upgrade for Galeon/Gaim/whatever come out, and then it'll slowly be built? Will the entire menu be generated next time I emerge something?
Back to top
View user's profile Send private message
h3k70
n00b
n00b


Joined: 11 Jul 2003
Posts: 14
Location: Germany

PostPosted: Mon Jul 14, 2003 2:20 pm    Post subject: Reply with quote

I've been experimenting around with this idea ... it's relatively easy to do (it seems, so far). Concerning updates, you could either work with portage or put an update script in a crontab. However, I don't really see a reason for making it a part of portage.
_________________
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: Mon Jul 14, 2003 4:04 pm    Post subject: Portage or not Reply with quote

** In the GWN! Yay! **

Quote:

Having showed the other person my desktop and Gnome (being the only two options I have compiled on my box, having no need for anything else), they choose Gnome. So I add "menu" to my USE flags, but I already have a fully working desktop box.

I would think it would be more suited for a "make.conf" option rather than a USE flag.

Quote:

Will the Gentoo menu be empty until an upgrade for Galeon/Gaim/whatever come out, and then it'll slowly be built? Will the entire menu be generated next time I emerge something?

That depends on the implementation. Best case scenario, it would be part of portage, and since portage "knows" what it has and where, it would simply insert the appropriate menu entry when you emerged an application. So unless a recursive checking mechanism was there, the only thing you would have in your menu is gaim. However, it would not be difficult at all to provide a stand-alone "update-menus" script that could be run in user space to generate a menu.xml file. This method would collect all the program entries from your portage installed database (in /var/db/pkg) and put them into the menu. From there you could use a simple transform to generate the menu for your WM of choice, potentially only containing items you wanted, in the arrangement you desired.

Anyone have ideas for a "rule-system" to control item placement?

Here is the problem: how do we discern program types that need to go into the menu from those that do not in the update-menus case? Would it be as simple as referencing back to the .ebuild and looking at the USE flags to see if it needed X, or curses, or.... ?
_________________
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
dreamwolf
n00b
n00b


Joined: 22 May 2002
Posts: 17
Location: Mount Laurel, NJ, USA

PostPosted: Mon Jul 14, 2003 4:51 pm    Post subject: Reply with quote

kesuari wrote:
Will the Gentoo menu be empty until an upgrade for Galeon/Gaim/whatever come out, and then it'll slowly be built? Will the entire menu be generated next time I emerge something?


Why not have the menu entries always added/removed when (em|un)merging packages (/etc/globmenu.conf?) and then have a "globalmenu" package that enables/disables it?

Better yet, how about a script that crawls the portage tree (a la qpkg from gentoolkit) and creates the conf/xml file for menu use? Then, it's just a matter of converting it to kde/gnome/.*box/.* menu format for use/inclusion in the WM of choice.

dreamwolf
Back to top
View user's profile Send private message
stustill
Guru
Guru


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

PostPosted: Mon Jul 14, 2003 6:07 pm    Post subject: Reply with quote

Good point, I didn't exactly think that through did I :)

In that case, it would be quite nice to incorporate menu generation into the emerge command. Possibly have some sort of special emerge option, for example emerge gentoo-menu. This could then read your USE flags to determine which environments you want to generate a menu for. For example, if you have -kde set, then you don't generate a KDE menu. Once the menu has been created you could then have emerge -u menu to update your menu with packages you have installed since the last menu generation. Also, I think it would be nice to include menu locations in ebuilds.

I don't think you want to generate menus without the user saying to though. How irritating would it be if once a week any changes to your menu that you made manually were killed by the menus updating automatically. Either way though, I think this is worth someone investigating :) In some form or another it would be a useful tool.

In some ways I like the customisability of linux, but I do not think that I necessarily go about making things accessible for myself on my computer. I quite like having someone else thinking about the best places to include various pieces of software in menus :)

Stu

kesuari wrote:
stustill wrote:
I like this idea. What would be really good, is if it was fully part of portage, but optional, perhaps with a USE flag to enable its use. That way it can easily be enabled or disabled.


<situation type="hypothetical">
I have it disabled because I'm the only one using my box and I don't use a windowmanager with menus.

I move to a shared house and the other person there has no computer. I have two, but the second one is too slow to run any reasonable operating system at a reasonable speed in this day and age, so I hook it up to my main box as a dumb X terminal.

Having showed the other person my desktop and Gnome (being the only two options I have compiled on my box, having no need for anything else), they choose Gnome. So I add "menu" to my USE flags, but I already have a fully working desktop box.
</situation>

Will the Gentoo menu be empty until an upgrade for Galeon/Gaim/whatever come out, and then it'll slowly be built? Will the entire menu be generated next time I emerge something?
Back to top
View user's profile Send private message
wolf31o2
Retired Dev
Retired Dev


Joined: 31 Jan 2003
Posts: 628
Location: Mountain View, CA

PostPosted: Mon Jul 14, 2003 8:06 pm    Post subject: Reply with quote

If you look into the eutils eclass, there is already a function to create .desktop files for gnome/kde and put them into the proper locations. I could modify this more to add support for other window managers, but it'll take some time. As it is now, it would be up to the maintainer of each package to update the ebuilds to call this function.
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: Mon Jul 14, 2003 8:49 pm    Post subject: Reasonable defaults Reply with quote

wolf31o2 wrote:
If you look into the eutils eclass, there is already a function to create .desktop files for gnome/kde and put them into the proper locations. I could modify this more to add support for other window managers, but it'll take some time. As it is now, it would be up to the maintainer of each package to update the ebuilds to call this function.


Right now I don't see a compelling reason to have the maintainers of the packages attempt to conform to a menuing standard. I'm very much in favor of "Reasonable Defaults", and I feel it is the user's responsibility (especially in a meta-distro like Gentoo) to create their own menu. However, there is no reason not to give them a good starting point and the tools necessary for them to customize it to their liking.

Looking through portage, it almost leaps out at you the potential for menus and submenus, as such:
Code:

Applications
    admin
    arch
    benchmarks
    cdr
    ...
Development
    C++
    Database
    Haskell
    Java
    ...
Gnome * special case - conform to the gnome menu
KDE * special case - conform to the KDE menu
Multimedia
    Fonts
    Graphics
    Radio
    Sound
    TV
    Video
Networking
    Analyzer
    Apache
    Dial-Up
    DNS
    Firewall
    ...
System
    Applications
    Build Tools
    Clustering
    ...
X11
    Miscellaneous
    Terminals
    Window Manager


So each submenu would contain the list of installed items, matched for the USE flags in the ebuild for their "worthiness" of being included in a menu. This worthiness would be configurable by the user, as would the placement of each category and sub-category. In this way, the menu.xml file could be built to the specifications of each user, without requiring a "standard" structure for the menu itself, and user space tools could turn that menu into commonbox, gnome, kde, windowmaker, etc.. style using another script or even XSL transforms.

I guess what I am saying is (as pointed out by stustill) we need a "gentoo-menu-generator" program that we can emerge and then each configure to our likings. I am very willing to work on this myself, but I would like to hammer out the details in the forums so that we can make it as good a utility as any other, a not an "evening hack".
_________________
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
gregcoit
Tux's lil' helper
Tux's lil' helper


Joined: 12 Jun 2002
Posts: 101

PostPosted: Mon Jul 14, 2003 11:38 pm    Post subject: my 2 cents Reply with quote

Hi all,

I own a linux-based gaming center/internet cafe based on gentoo. It would be *really* nice to have some form of centralized storage for menu items that both kde and gnome will use (since all my customers hvae their own accounts and can use oether kde ansd gnome). I'm *always* adding applications and games, and setting up the menus for both desktops is the small hassle.

One thing that would make it expecially useful for me is the ability to add (by hand is fine) an application to the (xml?) config file. This would be useful for the few apps/games that get installed by other means rather than portage (winex games come to mind).

Greg
_________________
"Life would be so much easier if we could see the source code"
Back to top
View user's profile Send private message
NoUseForAName
Tux's lil' helper
Tux's lil' helper


Joined: 22 Feb 2003
Posts: 84
Location: Sweden

PostPosted: Tue Jul 15, 2003 12:58 am    Post subject: Reply with quote

KDE and Gnome being able to use the same menu items will be in the next releases of them both I think.

Look at http://www.freedesktop.org/standards/menu-spec/

Not entirely sure about Gnome, but at least it will be in KDE 3.2
Back to top
View user's profile Send private message
krogoth
n00b
n00b


Joined: 15 Aug 2002
Posts: 38

PostPosted: Tue Jul 15, 2003 3:31 am    Post subject: Reply with quote

I don't think a single menu configuration file is the way to go. A directory hierarchy could be used to represent the menu, with a file (I prefer .desktop) for each item - the same approach that the /etc/*.d directories use. This would make it easy for packges or administrators to modify some items without disrupting others.

For people who don't like their distribution choosing what goes in their menu, a USE flag could disable automatic menu modifications; if it's enabled, each package would install as many items as it needs. The menu generation program would be in its own ebuild, and when run it would insert all the items in the shared menu into the menus for each window manager and desktop environment installed (perhaps a seperate menugenerators.d directory could hold scripts, installed by the WM ebuilds, to do this).

An important question is whether the system should control the menus completely, or if the items should be merged with the existing menus. Simply merging the items would make it more difficult to handle removal, but it would involve less work and maintenance.
Back to top
View user's profile Send private message
h3k70
n00b
n00b


Joined: 11 Jul 2003
Posts: 14
Location: Germany

PostPosted: Tue Jul 15, 2003 7:11 am    Post subject: Reply with quote

I don't mean to interrupt your theoretical studies, but I think this doesn't have to be a very elaborate script/app and neither do we have to bother all ebuild maintainers with changing their files. I've written a very rough (meaning, all the features have yet to be added) test of the principle as far as getting the data into XML format goes. Do any of you know XSLT and would write stylesheets to convert the XML for the window managers?
Code:

#!/usr/bin/php -f
<?php
/* This requires:
- the PHP CLI (if you don't have it, USE="-X" emerge php) and
- qpkg (from gentoolkit). */
function get_binaries( $pkg )
{
   return `qpkg -nc -l $pkg | egrep ^[^\ ]\*\$ | xargs ls -ld 2> \
      /dev/null | egrep ^-......r.x.\*/bin/`;
}
function get_path_from_ls_l_output( $str )
{
   return array_pop( explode( ' ', $str ) );
}
$doc = domxml_new_doc( '1.0' );
$doc_root = $doc -> add_root( 'menu' );
$all_pkgs = explode( "\n", trim( `qpkg -I -nc -v` ) );
unset( $all_pkgs[ 0 ] );
unset( $all_pkgs[ 1 ] );
$cats = array(); // Miaow!!
foreach( $all_pkgs as $pkg )
{
   $binaries = explode( "\n", trim( get_binaries( $pkg ) ) );
   //$binaries = get_binaries( $pkg );
   if( !( $sbinaries = sizeof( $binaries ) ) )
      continue;
   $binaries = array_map( 'get_path_from_ls_l_output', $binaries );
   if( !isset( $cats[ $cat = array_pop( array_reverse( explode( '/', $pkg
      ) ) ) ]   ) )
      $cats[ $cat ] = $doc_root -> new_child( 'submenu', $cat );
   switch( $sbinaries )
   {
   case 1:
      $cats[ $cat ] -> new_child( 'programme', $binaries[ 0 ] );
      break;
   default:
      $app = $cats[ $cat ] -> new_child( 'submenu', array_pop(
         explode( '/', $pkg ) ) );
      for( $i = 0; $i < $sbinaries; $i++ )
         $app -> new_child( 'programme', $binaries[ $i ] );
   }
}
echo $doc -> dump_mem( true ), "\n";
?>

_________________
Apocalypse now!
Back to top
View user's profile Send private message
nickrout
Apprentice
Apprentice


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

PostPosted: Tue Jul 15, 2003 7:40 am    Post subject: Reply with quote

I wonder why gentoo needs to reinvent the wheel that debian has invented and that mandrake already uses.
Back to top
View user's profile Send private message
h3k70
n00b
n00b


Joined: 11 Jul 2003
Posts: 14
Location: Germany

PostPosted: Tue Jul 15, 2003 7:45 am    Post subject: Reply with quote

Because inventing the wheel is usually faster and easier and more fun than adapting an existing wheel to fit your own carriage ;)
_________________
Apocalypse now!
Back to top
View user's profile Send private message
dorward
n00b
n00b


Joined: 19 Sep 2002
Posts: 16

PostPosted: Tue Jul 15, 2003 9:28 am    Post subject: Reply with quote

Two main benefits could come out of this:

(1) System wide updates, for all users, without user intervention
(2) Administrators do not need to go binary filename hunting when new software is installed.

Points I would suggest:

(1) Allow an administrator created file / set of files to add to and remove items from the menu.

This would allow some software to be kept off the menus (e.g. all text editors bar one wouldn't appear, to keep things simple for users), or placed in a different menu location.

(2) Watch out for special applications, such as window managers. They might appear in the menu, but probably not as a "run me" item. They would go in a "Change to window manager" item. (e.g. [restart] in common box).

(3) Console applications should run using the users default TERM, not anything specific by the package maintainer.

(4) The format for storing the menu data should contain all the information used by any window manager. (E.g. some have a description field, some don't, but the shared menus format should have both).

(5) Sometimes different data may be desired for some menu systems, for example to specify a different icon for a window manager (e.g. KDE has system icons which change depending on the theme).

(6) The script to rebuild the menus can be run manually or at the end of an emerge (if USE flags are set). It should also be capable of being run by any user, targeting a specific window manager, and a specific file. This allows users to generate the latest menu then copy/paste chunks of it in to the manually maintained version.
Back to top
View user's profile Send private message
h3k70
n00b
n00b


Joined: 11 Jul 2003
Posts: 14
Location: Germany

PostPosted: Tue Jul 15, 2003 9:53 am    Post subject: Reply with quote

(1) can as well be done by root using an editor :p
(2) results in a simple blacklist of things not to include in the menu plus a special script for the WMs' menu.
I haven't found a solution for (3) yet - how to automagically find out whether a certain application (moreover, a certain binary) needs a console or not :( Anyone?
(4) is easy :)
For (5), you'd have to go icon hunting for each app available in Gentoo. I'd rather drop this one for now.
As for (6), I'd let root run a script making an XML file, then give the users the opportunity to convert that to their favourite WM's format with xsltproc. When exactly the XML file gets updated should be root's decision, not ours ;)
_________________
Apocalypse now!
Back to top
View user's profile Send private message
dorward
n00b
n00b


Joined: 19 Sep 2002
Posts: 16

PostPosted: Tue Jul 15, 2003 9:59 am    Post subject: Reply with quote

The trouble with just doing it with an editor, is that when a package is upgraded and the menu regenerated - the edits have to be made all over again.

Automagic detection of console apps is hard, perhaps package maintainers should indicate what they are?

Icon hunting - a default icon could be distributed with each package.
Back to top
View user's profile Send private message
h3k70
n00b
n00b


Joined: 11 Jul 2003
Posts: 14
Location: Germany

PostPosted: Tue Jul 15, 2003 10:12 am    Post subject: Reply with quote

Actually admins with custom entries could just write up a short .ebuild file (just defining DESCRIPTION and possibly dependencies) and a CONTENTS file (with only the interesting binaries) and put that stuff in /var/db/pkg resp. tell a script to make it so. Would make an automated menu-building script's life a lot easier.

Console apps - well, not even SuSE got it 100% right in the past (dunno about the current version). And _they_ were probably making their menu manually. For a start, how about assuming that the users won't be too disappointed if no window appears when they click on things?

Icon hunting - agreed. If the maintainers wish to provide icons, they can of course do so, e. g. putting the icon in /usr/doc/foo or /usr/share/foo and setting the path in the .ebuild, like APP_ICON="/usr/share/foo/app-icon.xpm".
_________________
Apocalypse now!
Back to top
View user's profile Send private message
nickrout
Apprentice
Apprentice


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

PostPosted: Tue Jul 15, 2003 10:51 am    Post subject: Reply with quote

debian and mandrake use a suite called "menu" (strangely enough!). Each package that offers a menu entry puts a file into /usr/lib/menu. Here is the /usr/lib/menu/mplayer-gui file:

Quote:

?package(mplayer-gui): command="/usr/bin/gmplayer -quiet -nofs" needs="X11" section="Multimedia/Video" icon="gmplayer.png" mimetypes="video/mpeg,video/msvideo,video/quicktime,video/x-avi,video/x-ms-asf,video/x-ms-wmv,vi
deo/x-msvideo,application/x-ogg,audio/x-mp3,audio/x-mpeg,video/x-fli,audio/x-wav
" accept_url="true" multiple_files="true" title="MPlayer" longtitl
e="Movie player for linux"


Each window manager has a script in /etc/menu-methods/

A package can optionally run update-menus after installation which inserts all its menu items in the various window manager menu files. (this could be controlled bu a use flag).

Theres more to it than this, but it seems well thought out. It is worth downloading the mandrake rpm menu package and looking at the man pages (mc is good for this).

I know it works as I have run debian and mandrake. the menu system is the one thing i really miss in gentoo. The difficulty is inserting the /usr/lib/menu/package file into every relevant ebuild. The good thing is that it is already done by many package managers, and the files already produced by others may only need minimal or zero tweaking. There also appears to be per user overrides.
Back to top
View user's profile Send private message
slestak
Tux's lil' helper
Tux's lil' helper


Joined: 13 Jun 2003
Posts: 115

PostPosted: Tue Jul 15, 2003 5:21 pm    Post subject: Reply with quote

What do you guys think about some sort of etc-update script, that prompts after ebuild, for inclusion or exclusion to a gentoo-menu.conf ?
Back to top
View user's profile Send private message
h3k70
n00b
n00b


Joined: 11 Jul 2003
Posts: 14
Location: Germany

PostPosted: Tue Jul 15, 2003 5:38 pm    Post subject: Reply with quote

Afaict, emerge has so far not been an interactive app. And that's a Good Thing, because it means you can go to bed and be reasonably sure that it manages the download and make of two dozen ebuilds without your intervention. Having to type y or n regularly would really spoil the rare sleep experience.
_________________
Apocalypse now!
Back to top
View user's profile Send private message
EzInKy
Veteran
Veteran


Joined: 11 Oct 2002
Posts: 1734
Location: Kentucky

PostPosted: Tue Jul 15, 2003 6:12 pm    Post subject: Reply with quote

h3k70 wrote:
Afaict, emerge has so far not been an interactive app. And that's a Good Thing, because it means you can go to bed and be reasonably sure that it manages the download and make of two dozen ebuilds without your intervention. Having to type y or n regularly would really spoil the rare sleep experience.


Very good point and mostly true except for the occasions when you find that a variable such as VIDEO_CARDS has been added to an ebuild ;-).

Anyway, I'm all for a voluntary menu system, it'd certainly beat my kportage/terminal combo system I use 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: Tue Jul 15, 2003 9:04 pm    Post subject: Automatic system Reply with quote

The system could still be automatic. If the master menu file was automatically kept up to date, then the so called "client" menu-builders could be run at the user's discretion, to perform some sort of intelligent transform on the master file and build the menu for the WM the user requests.

I have been digging around for something like this, and I suggest everyone check out http://menumaker.sourceforge.net/. It is a pure python solution (nice) but currently has what I would call three limitations:

1) It relies on recognizing the binaries in your system by name
(this is fine for slackware or LFS, but it is a silly way to do it in gentoo
when we have the portage package database available)

2) It requires a unique definition for each program, so it cannot
automagically recognize brand new programs not in its list of definitions

3) The way the menus are made is hard coded, so customizing has to be
done afterwards, and there is no internal "rule system" so that a user
gets his own style of menu, every time.

However, it seems an excellent starting point, since only the core would have to be re-written (to be much simpler, I might add) to scan the portage database, and the transforms for basically everything except gnome and kde are already there.

Looks like a winner to me! And this way we don't have to re-invent the wheel, only the rim and a couple hubcaps!
_________________
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
nickrout
Apprentice
Apprentice


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

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

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).

It 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" Not every binary in a package is suitable to run from a menu. how does the program decide what command line options should be added to the binary?

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?
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 1, 2, 3, 4, 5, 6  Next
Page 1 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