Free menus software for linux

Menus de ElOtroLado provides a menu with access to EOL and Cineol Forums is created near the Help Menu.

Service menus for Debian package contains Konqueror service menus for Debian users. It was developed and tested on Debian Etch.
This package contains the modified versions of the following service menus from kde-apps.org:
1. Alien Tool by Kaisermart
http://www.kde-apps.org/content/show.php/Alien+Tool?content=33523
Use alien functions in a servicemenu. (Modifications: Improved apparence, different location in context menu.)
2. Debian Service Menu by Redclay
http://www.kde-apps.org/content/show.php/Debian+Service+Menu?content=16536
Simple kde service menu for managing debian packages. (Modifications: uses Konsole instead of x-term, kdesu instead of sudo for non-root users.)
Actions included:
- Install (dpkg -i)
- Uninstall (dpkg -r)
- Info (dpkg-deb -I && dpkg-deb -c)
- Installed files
- Changelog (changelog.gz)
- Changelog Debian (changelog.Debian.gz)
3. Root Actions Servicemenu by Kubicle
http://www.kde-apps.org/content/show.php/Root+Actions+Servicemenu?content=48411
(Modifications: Edit with KWrite and Open root Konsole here options were added.)
Actions included:
- Open (with default application)
- Run from here
- Run in Konsole
- Edit with KWrite
- Edit with Kate
- Edit with KHexEdit
- Open in Konqueror
- Open (root) Konsole here
- Change owner to root
- Change owner to user
Enhancements:
- More actions for root (Open with default application, Run from here, Run in Konsole)
- Fixed dependences
- Architecture independent .deb package

XDG-Menu project is a ROX panel applet that displays an applications menu button. The menus it builds fit the XDG Menu Specification published by freedesktop.org.
Main features:
- Applications menu based on XDG standards with capabilities to launch applications by mouse click and dragging items to pinboard, panel and file manager window.
- Configurable ROX applications submenu with capabilities to launch applications by mouse click, dragging items to pinboard, panel and file manager window, and context menu capabilities for each ROX-application.
- Logout menu item.

AI::Menu is a Perl object that generates Tree::Nary objects from directed graphs or a description of the function set.

The algorithm is not very efficient (approximately O(F^6), F being the number of functions). It is also not quite as intelligent as it should be. You should cache the results instead of repeatedly calculating them.

As the algorithm is optimized or more efficient algorithms are found, they will be incorporated. The interface for generating the trees should not change too much. The resulting object might become a Tree::Nary object encased in an AI::Menu object.

SYNOPSIS

use AI::Menu;

my $factory = new AI::Menu::Factory;

my $menu = $factory->generate($hash_of_functions);
my $menu = $factory->generate($hash_of_functions, $hash_of_categories);
my $menu = $factory->generate($graph);

METHODS

All of the following methods (except generate) are available in the new function when creating the AI::Menu::Factory object.

generate

This function does some housekeeping before calling a configurable module to generate the tree.

If called with a single hash reference, the hash is assumed to be a list of functions mapping to array references containing a list of categories. It is further assumed that the sets of function names and category names are disjoint. A closure is created for the leaf_q function which returns true if its argument is a key in the hash reference. The complete graph is created from this single hash reference: if a category can reach another category through a function, then an edge is inserted between the two categories. This edge is bidirectional.

If called with two hash references, the first hash is treated as before, but the second hash reference is considered a mapping of categories to categories. This second hash is used instead of automatically generating the information from the first hash.

If called with a single object that is not a hash reference, then the argument is considered a graph object (usually of Graph::Directed). The leaf_q function will need to be defined.

leaf_q

This function returns true if the argument represents a function (leaf in the graph). It returns false if the argument represents a category. This may be set either when the AI::Menu::Factory object is created or through a method call. The method call with no argument returns the current function.

maker

This is the package used to create the menu from the graph. The following call is made:

my $menu = $self -> {maker} -> new(
width => $self->{width},
weight_f => $self -> {weight_f},
leaf_q => $leafq,
);

return $menu -> generate_tree($g, $optscore);

The $optscore value is the score for the optimum tree. Once a tree is found with this score, searching should stop.

new

Creates an AI::Menu::Factory object. Optional arguments are key/value pairs taken from this list of methods except for generate and new.

weight_f

This function is used to calculate the edge weights in the graph. It is called with four arguments: the object generating the tree, the graph object, the originating vertex, the destination vertex. The function should return undef for an infinite weight.

width

This is the desired number of children per node. The optimal number (and default) is three.

Tasty Menu project is a KMenu replacement aiming to provide the maximum usability, or at least to be a testbed for usability concepts and ideas for a future kmenu replacement.
The left part of the menu is very similar to the Novell idea (http://www.novell.com/products/desktop/preview.html): you have a search box that is always selected when the menu is opened (the search result are displayed in the leftmost listview), followed by a combobox that decides what the following listview: favourite applications (default), most used applications, recently used applications and recent documents.
The right part contains the whole kmenu and takes the aspect from KBFX (http://www.kbfx.org), the middle column contains the top level categorization (plus in the current kmenu arrangment there are also the control center, home folder and find files, but i think there should be present only categories). in the left-most listview there is the content of the category currently selected in the middle column. I think in this way even if it has the same number of items it _appears_ less huge than with a popup menu/submenu structure.
every items have two row, for the name and for the description, in order to make a more it more informative. On each selected item appears an action icon on the right, at the moment they are "add bookmark" on application icons and "remove bookmark" on favourite apps list.
The bottom buttons are the usual switch user, lock session and logout. In a first time I didnt want to put them, I tought that these function should be delegate to another applet like http://kde-apps.org/content/show.php?content=26150 , but it seems that the multiple menus concept its a thing that doesnt work very well in practice, it needs more real-world testing.
The left-most btton contains the user name and icon, and clicking on it it opens the kcm used to edit the users profile. I know it seems silly, but Its only an experiment, probably it will be merged with the switch user button.
Enhancements:
- "Add to desktop" option in menuitems
- Drag and drop from menu to desktop
- Option to set different icons sizes in the three columns
- the button text label should always be of a visible color
- most used/recently used applications list updates in realtime
- clear most used/recently used applications list
- (warning1: deleting one list deletes also the other)
- (warning2: if you use opensuse you must have kickoff reverted to classic kmenu in order to use the recently used/most used lists)
- updated russian and german translations

Menu Builder is a software that can find problems with using JavaScripts for rollovers in navigation menus and resolve them.

Menus need to be fast loading, retrievable from cache, and workable with page inserts. From the publishing point of view they need to be able to be distributed to pages efficiently.

There is no limit to how many or how large the images can be displayed on the same page. But as with any great number of images there is always the download time to consider. If it is too slow then there is a risk of the surfer getting impatient and moving on. Many of us tend to forget that we are getting our images from our own cache.

Images presented on the web are usually 72-96 dpi (dots per inch) and unless presenting a photographers professional portfolio, images larger than 100k in file size make for longer downloads and less visitors.

A link can be set for visitors to navigate by mouse clicking the image. The link can be set to a target frame for navigating within framesets. The hyperlink will only function from the registered site. If a link is not required simply leave the setting completely blank.

Menu Buddy plugin currently comprises a couple of Python scripts for creating GNOME panel menus from a directory hierarchy of music files.
These menus can be used to play or enqueue songs in XMMS, as well as pause or skip XMMS.
These scripts are not terribly powerful yet, but there is potential for a signficantly more flexible system of menu-creation that allows automatic construction of many different kinds of menus based on directory hierarchies.
menu_buddy is a small script for scanning a hierarchy of music files and creating a set of Gnome menus that can direct xmms to play those files. Instead of going through the command line or whatever, menu_buddy lets you play/enqueue files in xmms straight from your menu. I find this pretty convenient.
The command line for menu_buddy is as follows:
menu_buddy < source dir > < dest dir >
where:
< source dir >: The top of a hierarchy of directories containing the files
< dest dir >: The top of a directory to write the menu files into
menu_buddy works with the assumption that you have your music stored under one main music directory, using some meaningful hierarchy, and that theres only music stored down there. menu_buddy doesnt do any sort of file-type checking and assumes that everything under is fair game for playing in xmms.
What menu_buddy does it this: it constructs a menu hierarchy that directly matches the hierarchy under such that any directory or tree thereof can be played or enqueued in xmms. Likewise, at the top of the menu structure, it creates menu option which allow you to pause, start, or skip forward/backward in xmms. The interaction with xmms is purely in terms of command line options that you can pass to xmms...there is no special linking or whatever.
So, for example, lets assume you have all of your music in under the directory "/music", with top-level folders for different genres (i.e. /music/rock, /music/polka, etc.). Inside each genre, you have your files sorted first by artist, then by album (i.e. /music/rock/faith_no_more/the_real_thing, /music/polka/the_polka_kings/greatest_hits). The organization you have is really unimportant, but bear with me here.
Further, lets assume that your system lets you create new gnome menus by putting menu files in ~/.gnome/apps (this is how things work on my system, but honestly Ive done next to zero research into this topic...it may vary (wildly) on your system, so I suggest you figure it out for yourself). Then, the following command will create a new menu hierarchy in your "favorites" menu called "Muzik" which allows you play/enqueue your music:
menu_buddy /music ~/.gnome/apps/Muzik
Thats it. It may take a few seconds to churn through your music files, depending on other system load and how much music you have. You need to be able, of course, to write to the output directory you specify, but since it will typically be in your home directory this should not be a problem.
Enhancements:
- added GPL stuff to source files