awesome

Welcome to awesome bug tracking system.
Tasklist

FS#7 - Integrate dmenu-like menu

Attached to Project: awesome
Opened by Julien Danjou (jd) - Tuesday, 01 January 2008, 18:32 GMT
Last edited by Julien Danjou (jd) - Wednesday, 19 March 2008, 05:48 GMT
Task Type Feature Request
Category Uicb
Status Closed
Assigned To Julien Danjou (jd)
Operating System All
Severity Very Low
Priority High
Reported Version git/master
Due in Version 2.3
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

awesome should integrate a menu like dmenu
This task depends upon

Closed by  Julien Danjou (jd)
Wednesday, 19 March 2008, 05:48 GMT
Reason for closing:  Implemented
Additional comments about closing:  Implemented in post-2.2
Comment by Nelson A. de Oliveira (naoliv) - Thursday, 03 January 2008, 03:21 GMT
Can it has a menu that follow Debian's menu structure? (get files from /usr/share/menu and create a structured menu, for example)
Comment by Martin Stubenschrott (maxauthority) - Thursday, 03 January 2008, 21:39 GMT
@naoliv: I don't think it will have a menu in what you think, dmenu or such things are rather mini commandline to launch things.

In my opinion the perfect menu should work like the query module from ion3:

it has mainly 3 advantages over dmenu:
1.) It SHOWS the completions on the fly while writing characters in a kind of a popup, so you don't have to write too many
2.) It uses <tab> to select other completions, not left/right, which are much harder to reach
3.) It can also complete arguments to programs. So: gvim foo<tab> will complete any file with foo in your home directory.

But one should still try to keep it (and the completion system) generic, as a menu module can be used for many other purposes (like connecting to ssh, viewing man pages, ...)
Comment by Julien Danjou (jd) - Friday, 11 January 2008, 10:21 GMT
Martin's suggestions are good.

So far, my main concern is about implementation. I still don't know if this should be part of awesome code or written as a separate tool like dmenu.

Implementations ideas are welcome.
Comment by calmar (calmar) - Friday, 11 January 2008, 11:29 GMT
'gmrun' seems to fit some requirements Martin told about - it's just not really nice with the gtk look.

I would like to add these requirement:

1. it should be possible to limit the programs (e.g with adding them into a file) - that actually speeds up finding items (and speeds up the start of itself as well).

2. it should be able to open console programs in a console (gmrun does this, but you have to type <C-Enter> or something, that makes many extra strokes over the years ;))

http://www.calmar.ws/awesome/.9menurc (maybe with a file like this, it either opens the thing on the left, or when there is a :... it does that then)

In order to create these files, some simple bashscript could help. The advantage of scanning the whole path all around, is when you happen to have new programs there, but then you could still run the bash-scripts (or whatever) what updates/adds them to the current or so :). It's a little more effort at the begin, Might be an option to use both, file or cache+initial scanning might be the best so.

Anyway, i'm about happy with I have actually, and should better shut-up therefore...






Comment by calmar (calmar) - Friday, 11 January 2008, 11:33 GMT
I actually think (my 2 cents), it's better to have it not inside the mw. Can still be a add-on-app for awesome (and also others then therefore). Unless there are clear disadvantages with that, what had to be mentioned then..
Comment by Martin Stubenschrott (maxauthority) - Friday, 11 January 2008, 12:20 GMT
I am definitly for integration within awesome for some reasons:
1.) It just takes your color/font settings from the awesomerc
2.) It takes your key definitions from the awesomerc
3.) If it's a seperate app, it mostly looks out of place or at least not so well integrated. For example an integrated run dialog could not take the whole width of the screen, but just show instead of your focustitle widget.


@calmar: I think the opposite, that is essential that such a menu has basic query capabilities built-in.
In ion3 I could just press a key and open a man page (with completion), or press another key and open programs, or another one for ssh. I know that all those things could also be done in a dmenu-like system, but the point is, not everybody likes it to configure all those things specially, it would be nice to have most common things "Just work" but still allow custom things to do. And no, i do not want to write a bashscript to write a file with program names, just too launch a simple program.

Also Ion3 solved the console program "problem" in quite a good/logical way (for me at least), if you type :vim in your run prompt, it opens it in a console.
Since also the man page viewer, or ssh query need a terminal it would probably make sense to go the ion way which has a XTERMCMD environment variable which is called instead of xterm.

So my proposed interface would look like that:

key
{
modkey = {"Mod4"}
key = "r"
command = "run" // or "query" or whatever
arg = "application"
}

key
{
modkey = {"Mod4"}
key = "s"
command = "run"
arg = "ssh" // so, "application", "ssh", "man", etc. were built ins
}

key
{
modkey = {"Mod4"}
key = "c"
command = "run"
arg = "custom:Movies:my_script.sh" // The title of the query would be "Movies"
// and the items would come from that script, in a dmenu like fashion to stdout
}

available built in args could be:

applications: List all applications in your path
ssh: ssh to some location
man: shows the man page in your $XTERMCMD terminal
file: Could at some point open any files with it's associated program (needs a locate database, or beagle backend, ...)
window: Query for windows to jump to
custom: would allow to create your own "run" commands somehow.


Hope you get my idea, and love it as much as i do :)

--
Martin
Comment by Julien Danjou (jd) - Friday, 11 January 2008, 12:26 GMT
Martin, a program out of awesome does not need that:
1) it does not know how to read the config file to use colors/font
2) and also keys definition
3) dmenu already do that IIUC

The rest of your implementation can be scripted by default in awesome distribution.
Comment by Christian Gogolin (cgogolin) - Saturday, 09 February 2008, 16:01 GMT
As awesome is made for keyboard oriented users a real menu with klickable buttons seams unnecessary to me, but a program luncher with a bash like tab completition would be great.

I am coming from ion3 and I really miss the program luncher that was described in the first post of Martin Stubenschrott.

Please implement something like this in awesome!

Comment by John Cooper (choffee) - Tuesday, 26 February 2008, 17:16 GMT
A text based interface to gnome-do would be my ideal!

http://do.davebsd.com/
Comment by Zsolt Udvari (uzsolt) - Tuesday, 26 February 2008, 18:18 GMT
2. Awesome Plugins :))))
Comment by Dag Odenhall (donri) - Saturday, 01 March 2008, 10:35 GMT
Menus could be managed like widgets

menu my_menu {
items = "~/.applist"
keys {
key {
key = "Enter"
command = "spawn"
}
}
}

keys {
key {
modkey = {"Mod4"}
key = "p"
command = "widget_tell"
arg = "my_menu"
}
}

The selected item would be appended to the "arg" of the "command". No arg implies to spawn that program, with an arg it could be made scriptable. The selected item would be sent to a program to handle it. This would also make it easy to set up e.g. control+enter for running a terminal program like calmar requested:

key {
modkey = {"Ctrl"}
key = "Enter"
command = "spawn"
arg = "urxvt -e"
}

There should probably also be a way to configure what escape does in dmenu. This could be a command in itself, called e.g. escape or return.

This menu widget should probably be able to lay over other widgets (I don't know if other widgets can do this?).
Comment by calmar (calmar) - Sunday, 09 March 2008, 15:06 GMT
I would have some issues:

1. when the first match would be selected on a <ret> or shall there be the possibility to open also stuff not on the menu - then
that might come into the way.

Well, <tab><ret> (select first then open) is ok too.

2. I don't really like the std-colors it uses. Maybe an option to have custom ones? Actually they look alsmost awful. grey on black. Ok for the taglist but not for that (with my configuration for me). Including font-size config option :) I would like a bigger font.

3. <shift><tab> for cycling back would be nice too.

then it might already be better than dmenu and seems to be faster as well (what was sometimes an issue with my dmenu, despite i only feed some dozens of apps to it).

4. When that is going to be the thing in awesome (dmenu like), any hints about improving: http://www.calmar.ws/tmp/dmenu_do , like other general ideas?

Loading...