FVWM "actions"

Configuration Complex functions
1

Hi all,

I’ve been messing around with FVWM for a while now and I felt I should try something a bit more interesting with my configuration.

One feature I’ve noticed missing from FVWM is the ability to bind icons/buttons/text to executable bits of FVWM code. An example will illustrate what I mean here.

When you add a menu item to a menu, you can choose to associate an icon with the item, as well as a menu label. When you create a launcher bar with FvwmButtons, you can specify which icon to use on the button. Windows can also have mini-icons associated with them, which are used in the window itself, and the taskbar.

Wouldn’t it be nice to use the same icon in all cases automatically? Right now you have to keep track of this manually. To help with this, I’m attempting to implement what I’m calling an “action” system in FVWM. I would like to use Lisp, but that’s beside the point.

An FVWM Action would have the following properties:

  • a unique identifier.

  • an FVWM function to execute.

  • (optional) window id, if the action has an associated window.

  • (optional) a mini-icon, to be used in menus and buttonbar launchers. If the action has an associated window (i.e. the window id property is defined), then the icon is used as the app’s mini-icon and the app’s icon on the taskbar as well.

  • (optional) menu text, if you want this action to appear on a menu.

  • (optional) a keybinding, for executing the action with a keystroke.

A few months ago, I did implement something primitive along these lines. The result was a collection of Lisp scripts executed at FVWM startup. It worked (more or less) but it was kind of static; you couldn’t really change anything after startup. I would like to try something a bit more dynamic.

So I’d like to ask some advice on how to go about doing this. Obviously, an “action” is an abstract concept that does not exist in FVWM, so the concept will have to be implemented externally. Should there be something separately “running”, like a module, which knows how to translate “action” commands to FVWM commands? Actions could be loaded into memory and FVWM could run queries on it, I guess, when it needed to (like when it needed to populate a menu entry).

Or should the system be stored entirely on disk, fronted by a bunch of scripts that FVWM uses via PipeRead?

I can think of pros and cons for both. The former is, I imagine, faster, for the same reason that mod_perl is faster than CGI: you save the overhead of loading and compiling the scripts (in the case of Perl and Lisp), everytime you want to use them. On the other hand, I would imagine that the latter approach is somewhat easier.

Any thoughts?

Desmond

2

The problem here is that you’re assuming these actions are somehow unifiable across different contexts; invariably though they won’t be.

I would suggest trialing this out via perllib would be a good start. You would of course, have to autogenerate your menus in order to account for this dynamicity.

Horrible!

But it will have to “exist” in FVWM if it is ever going to understand the contexts upon which it is invoked (regardless if you think otherwise). Hence what you’re really wanting to do is write a FVWM module to do this. Oddly enough, using perllib to do something like this wouldn’t be too difficult although I have no idea if it will work. The problem you have though is getting FVWM to understand how the different illogical actions fit in with the thing you’re trying to do. I question, actually, how beneficial any of this is. What I would do is attempt to set up some observers bound to various events that FvwmEvent can propagate and manipulate them that way. But it’s slow. You’d almost have to make use of ModuleSynchronous during FVWM startup, otherwise nothing will work.

No, since then nothing would work. (FVWM would conceivably block forever if your PipeRead fails – a very common occurence in this situation.)

I don’t see this as being a good idea, I’m sorry to say. At the moment, common actions are “abstracted” out into functions that can be called. This is fine. Where they differ is the various way upon which their called. And that in turn lies with a specific module (if it’s not a true part of FVWM’s core). This is where it should lie, quite frankly. The only non-conformity this brings about it syntax, but that’s just tough.

Concentrate on something else; say, getting your config working? ;)

– Thomas Adam

3

My original idea was more limited than what I described here. I had initially envisioned a simple way to link a mini-icon against a windowed application, to be used in my menus, app launcher bars, taskbar, and as the mini-icon for the window, so that I wouldn’t have to specify the icon manually in all the different places.

I then defined a dynamic “application” menu that hung off of my main menu. You could populate it with “actions”, and the menu-text and icon would be used automatically.

I’m not entirely sure what is meant by “assuming these actions are somehow unifiable across different contexts”, but I think in this (simplified) case they are; the actions all launch windowed applications, and it matters little whether you do that via the menu or the app launcher bar.

I thought that one could generalize this idea so that you wouldn’t necessarily need to have the action represent a windowed application.

Of course. I’ll take a look at perllib.

The scripts were (are) indeed ugly :slight_smile:

Okay.

Okay, cool.

Bah, what fun is a working config? :slight_smile: Anyway, my config does work…sorta :slight_smile:

4

You might want to take a look at wm-icons and/or fvwm-themes.