recommend a menu

Forum: water cooler
Topic: recommend a menu
started by: curaga

Posted by curaga on Oct. 21 2007,14:40

I'm looking for an app that would appear in the top of the screen, show three buttons with my text, which would execute an app on click.

So far the best has been yeahlaunch, but it autohides. So can anyone recommend any good ones?

Posted by mikshaw on Oct. 22 2007,15:00

dmenu works well for all sorts of menu needs. With its minimalist design, however, it is best suited to using along with a script of some sort. It also "autohides", although in reality it just doesn't run until you call it, and then closes when you select something. Setting up a hotkey to run it works good, though. It also is keyboard driven, so that might be a factor in your decision.

One thing I've been playing with recently is using dfm with an "empty" icon for each desktop object. This allows me to have an always-on text-only menu on the desktop. The problem with this is it gets messed up when installing mydsl packages or adding other objects to the desktop.
Empty icon:

Code Sample

/* XPM */
static char *empty[] = {
"1 1 1 1",
"o c None",
"o",
};

I suppose it might be possible to run simultaneous instances of dfm, having one only taking up the top part of the screen, but I haven't tested this.

Posted by curaga on Oct. 22 2007,15:52

Okay, I'm looking for something that's mouse driven though.
And it should be "on" all the time, without the need for a hotkey or respawning from a script.

Thanks anyway Mik

Posted by ^thehatsrule^ on Oct. 22 2007,17:59

You could always use something with a dock and something like the lua mount tool, or something similar if you can't find a suitable program.

Posted by mikshaw on Oct. 23 2007,18:28

Here's murgaLua script that might work for you until you find something better. It's just a quick thing, probably could be improved.

Code Sample

-- label="command"
my_menu={
Aterm="aterm -fn proggy",
Dillo="dillo",
Wings3D="wings"
}

size=11 -- text size
bh=16 -- button height

w=fltk:Fl_Window(Fl:w(),bh)
w:callback(function() end)
butt_pack=fltk:Fl_Pack(0,0,Fl:w(),bh)
butt_pack:type(fltk.FL_HORIZONTAL)

close=fltk:Fl_Button(0,0,bh,bh,"x")
close:callback(function() os.exit() end)
close:labelsize(size)

butt={}
cnt=1
for k,v in pairs(my_menu) do
butt[cnt]=fltk:Fl_Button(0,0,100,30)
butt[cnt]:label(k)
butt[cnt]:labelsize(size)
butt[cnt]:callback(function() os.execute(v.." &") end)
cnt=cnt+1
end

fltk:Fl_End()
w:position(0,0)
w:border(0)
w:show()
Fl:run()

Posted by curaga on Oct. 24 2007,14:36

Thanks Mik. There's though one flaw with that; it appeared in the middle of the screen (vertically)..
edit: I was running on my main machine when I tested; it might appear on top when on DSL. I'll test soon.

I think I might try to learn gtk+ programming. But that might never happen, so I could also use this

Posted by mikshaw on Oct. 24 2007,16:53

Quote

it appeared in the middle of the screen

I think it depends on your window manager, since it is scripted to appear at 0,0 and that's all I can do with murgaLua. Some window managers will ignore a request for specific placement, and some will put it wherever the app wants to go. It might be doable with an overlay or GL window, but neither is supported by murgaLua.

Posted by curaga on Oct. 25 2007,14:19

I have two wishes: could that close button (x) in the left corner be left out?
And could the buttons be centered?

Posted by ^thehatsrule^ on Oct. 25 2007,16:08

Just from a quick look...
1. delete the 3 lines that start with 'close'
2. no idea if there's an easy centering call, but this might be fine..
[Line 13] butt_pack=fltk:Fl_Pack(INSERT_LEFT_MARGIN_HERE,0,Fl:w(),bh)
where you could use something like (Fl:w()/2)-(50*ARRAY_SIZE)
where ARRAY_SIZE=3 from the original... where there might be a function to easily obtain this value

Quote

it appeared in the middle of the screen (vertically)..

Try using [Line 31] w:position(1,1)
Maybe (0,0) would be as if position() was not called at all? (So the WM takes over control)

Posted by mikshaw on Oct. 25 2007,19:57

Quote

1. delete the 3 lines that start with 'close'

If you remove the close button, you might also want to remove the w:callback, since it is what prevents the application from closing when Esc is pressed. I did this simply because I assumed you wouldn't want the menu to be so easy to close.

The placement of the buttons was just the first way that came to mind. I thought that using the whole screen width was unnecessary, but used it in case you wanted to add more buttons. I've never been good with math, but it looks like thehats' suggestion should work at least as well as anything I'd come up with. I also don't recall seeing anything specific to placement of one object within another, but it could be there somewhere.

Quote

Maybe (0,0) would be as if position() was not called at all?

Maybe, but I still think it's a window manager issue. 0,0 works for me. I haven't tried it with Fluxbox or JWM yet.

Posted by ^thehatsrule^ on Oct. 25 2007,23:59

Quote

Maybe, but I still think it's a window manager issue. 0,0 works for me. I haven't tried it with Fluxbox or JWM yet.

Heh, well this is my first glance at lua/flua/etc... but just trying an actual test run with the changes with the latest release on Fluxbox (some RC on v1.0) seems to allow the WM to take over with 0,0 whereas other values are actually used (I had my WM settings on tiling, so it did that). Could be a versioning behaviour discrepancy?

Posted by mikshaw on Oct. 26 2007,00:34

I tested it on dwm, swm, jwm, fluxbox 0.1.14, and fluxbox 1.0.0 (final). All of these window managers placed the app in the correct place except for fluxbox 0.1.14 (the one in DSL). I could see forced tiling being a factor, but I never thought to check that.

I made some changes to the script. It now does not cover the whole width of the screen. The width is determined by the number of buttons. The configuration is marked at the top of the file. If you use more or less than three buttons, both the size of the my_menu table and the table_size variable must be equal. I thought it was easier to have the user change table_size rather than traverse the table just to find its length (table.maxn doesn't work on non-numerical tables).

The app now appears in the top-middle of the screen if your window manager supports it. As I said it works as desired with jwm and swm. With fluxbox you will need to either use a newer version or place it manually.

The "X" button has been removed, but the w:callback is still there, so you will need to force it to close with killall or xkill or something similar.

I would like to be able to stop it from creating a toolbar button in fluxbox/jwm, but I don't know if this is possible.

Code Sample

---- CONFIGURATION
-- menu: label="command"
my_menu={
Aterm="aterm -fn proggy",
Dillo="dillo",
DSLpanel="cpanel.lua"
}

size=11 -- text size
bh=16 -- button height
bw=100 -- button width
table_size=3 -- number of table items
---- END CONFIGURATION

barw=table_size*bw
w=fltk:Fl_Window(Fl:w()/2-barw/2,0,barw,bh,"MLmenu")
w:callback(function() end)
butt_pack=fltk:Fl_Pack(0,0,barw,bh)
butt_pack:type(fltk.FL_HORIZONTAL)

butt={}
cnt=1
for k,v in pairs(my_menu) do
butt[cnt]=fltk:Fl_Button(0,0,bw,bh)
butt[cnt]:label(k)
butt[cnt]:labelsize(size)
butt[cnt]:callback(function() os.execute(v.." &") end)
butt[cnt]:box(fltk.FL_BORDER_BOX)
cnt=cnt+1
end

fltk:Fl_End()
w:border(0)
w:show()
Fl:run()

Posted by ^thehatsrule^ on Oct. 26 2007,02:04

Using the default settings for fluxbox under DSL 4.0 there is no window/frame decoration, although I still had to issue position() to set it in the correct location (with width being the same copied from Fl_Window ... it seems that one is ignored then?)

Posted by curaga on Oct. 26 2007,13:15

Nice. I actually want it not to be user-closable.

I will be using it under failsafewm, which doesn't have any decoration at all..

edit:
Hey, can the buttons' text have spaces? If I quote the name?

Posted by mikshaw on Oct. 26 2007,13:21

As far as I know, DSL 4.0 uses Fluxbox 0.1.14, which I already mentioned doesn't properly position the app. Are you saying position() works now? It didn't work for me when I tried it last night (DSL 4.0RC5/Fluxbox), any better than putting the coordinates in Fl_Window did. I wonder if putting them in both places is necessary for some wms that need to be given a second nudge =o)

Posted by curaga on Oct. 26 2007,13:32

I haven't still tested, but I won't be using fluxbox, I'll be using failsafewm.

Sorry to repeat, but is it possible to have spaces in the buttons' text?
Like "Web browser"="/usr/bin/dillo"

Posted by mikshaw on Oct. 26 2007,13:41

Replace this:

Code Sample

butt[cnt]:label(k)

with this:

Code Sample

a,b=string.gsub(k,"_"," ")
butt[cnt]:label(a)

Now use underscores for spaces in the table and they will be converted to spaces.

I couldn't find a way to use the spaces directly in the table keys.

Posted by ^thehatsrule^ on Oct. 26 2007,14:59

Try

Code Sample

["A t e r m"]="aterm"

Quote

Yea, I was just confirming the position problems but that I didn't run into any window decoration problems. �Using position() works for any other values than 0,0 and it does seem that the settings in Fl_Window are ignored. �Of course, I haven't thoroughly tested all cases...

Posted by mikshaw on Oct. 26 2007,18:53

Quote (^thehatsrule^ @ Oct. 26 2007,10:59)

Try

Code Sample

["A t e r m"]="aterm"

Hey, that works. I dunno what it means, but it works =o)
But I think I prefer my method, though. It's easier to use a single underscore for each space, in my opinion, than to use square brackets and quotes *and* spaces.

I also think I'll add a little code to automatically get the proper number of table entries instead of having the user change both, contrary to what I said before. It's only a few extra lines, and it won't make any noticeable difference in performance even on a very slow machine unless you have hundreds of keys (which wouldn't fit on the screen anyway).

With either of the above issues, I would consider keeping the code smaller if it weren't for the fact that the script is so small that the ease of use and configuration greatly outweighs the added code.

Posted by mikshaw on Oct. 26 2007,21:41

Added font and color config
Automated the table item count
Added suport for spaces in labels
Removed the Fl_Pack (not needed in a linear array of same-size buttons)
Changed the way the window is positioned (w:resize())

Code Sample

---- CONFIGURATION
-- menu: label="command" (use underscores for label spaces)
my_menu={
Aterm="aterm -fn proggy",
Dillo="dillo",
DSL_panel="cpanel.lua",
Top="aterm -e top"
}

size=11 -- text size
bh=16 -- button height
bw=100 -- button width
Fl:set_font(0,"snap")
Fl:background(0,0,0) -- r,g,b (0-255)
Fl:foreground(255,255,255)
---- END CONFIGURATION

w=fltk:Fl_Window(0,0,Fl:w(),bh,"MLmenu")
w:callback(function() end)
butt={}
cnt=0
for k,v in pairs(my_menu) do
butt[cnt]=fltk:Fl_Button(cnt*bw,0,bw,bh)
a,b=string.gsub(k,"_"," ")
butt[cnt]:label(a)
butt[cnt]:labelsize(size)
butt[cnt]:callback(function() os.execute(v.." &") end)
butt[cnt]:box(fltk.FL_BORDER_BOX)
cnt=cnt+1
end

barw=cnt*bw
w:resize(Fl:w()/2-barw/2,0,barw,bh)
w:border(0)
w:show()
Fl:run()

Posted by ^thehatsrule^ on Oct. 26 2007,23:29

Looking good... I for one never liked the default greys.

From what I've seen, the easiest would be to implement 2 different tables...

That being said, if this was to be updated a lot, I'd implement the reading of the buttons from a external text file instead.

Posted by mikshaw on Oct. 27 2007,01:25

Quote

the easiest would be to implement 2 different tables

That had crossed my mind, and I've used that method in the past. However, it presents a greater challenge for the end user in that you need to keep track of the order of two tables instead of just one. I think it's much easier to use the label=command syntax in a single table rather than having to make sure that item 12 in table one is the appropriate label for the command specified by item 12 in table two. With the latest version of this script I no longer have to be concerned about how many items are in the table, since it uses the k and cnt variables to keep track of it while the labels and commands are being read.

One thing I don't understand is the fact that the order of the tables is not necessarily the same when the items are displayed, but I think this is a limitation of Lua. This might be one benefit of using two numerical tables.

Quote

I'd implement the reading of the buttons from a external text file instead

Also something I've considered =o)
I don't know if that's something I'll do, though. Personally I like to keep things as simple as possible, and in the case of small files simplicity means not splitting things up unnecessarily. With tiny scripts I tend to prefer keeping everything in a single file. I still haven't decided whether a split of the menu content and the script is unnecessary.

Then again, I'm not really making this for me anyway. For a minimalistic menu I still much prefer dmenu, so I can't see myself using this script for anything other than learning and future reference.

Posted by ^thehatsrule^ on Oct. 27 2007,02:53

Your starting script looked simple enough, so I jumped on the chance to (finally) learn a few things :P

Quote

With the latest version of this script I no longer have to be concerned about how many items are in the table, since it uses the k and cnt variables to keep track of it while the labels and commands are being read.

Actually, I was using the for loop to keep the count... but couldn't find a function to do it then (and still not now I suppose).

Posted by curaga on Oct. 27 2007,06:46

Thanks again, you all went through a lot for me

So now it's white text on black?

Posted by curaga on Oct. 27 2007,11:30

I actually learned gtk+! Yay!

So now I have a gtk1 one, and this. I think I'll include both, and let the user decide

Posted by mikshaw on Oct. 27 2007,14:41

Quote

I actually learned gtk+! Yay!

In two days....impressive. Maybe that's why Gtk and Qt are so popular.

Quote

So now it's white text on black?

That's just my own preference, to fit with my dark window manager. The foreground and background colors are easily changed in the configuration section. Each is set using the standard R G and B colors, each with a value of 0-255, such as those you find in rgb.txt (/etc/X11/rgb.txt in DSL). The FLTK color chooser will show these values when set to "byte"
bash> murgaLua -e 'print(fltk.fl_color_chooser("color",0,0,0))'

Posted by curaga on Oct. 27 2007,16:23

Oh, I have no trouble with those colors, I like them.

Just checked if I was right, as I hadn't tested that back then.