FVWMEVENT(1)

📦
version 1.1.5 · 5 versions
, in ubuntu stonking

💖 NAME 💖

FvwmEvent — bestie, it's the fvwm event module. the moment your window manager does something, this girl is watching 👀

✨ DESCRIPTION ✨

So like, FvwmEvent is a module that triggers actions on fvwm events. no cap. it can hook any fvwm function or program to any window manager event. 🪝

It can trigger actions when:

  • windows are added 🎀
  • windows are deleted 💀
  • windows are iconified
  • windows are shaded
  • fvwm changes which virtual page or desk is being shown 🌀
  • RandR monitors are changed, enabled, disabled, or gain focus 🖥️✨

Be creative, you'll find a use for it. periodt.

🌈 INVOCATION 🌈

okay so the tea here is that FvwmEvent is spawned by fvwm, so no command line invocation will work, sorry bestie 😭. it has to be born through fvwm.

FvwmEvent can be spawned from within the config file with or without an Alias as follows:

Module FvwmEvent Alias

You can add this to the StartFunction to ensure FvwmEvent is running and listening for events when fvwm starts. 👑 Alternatively you can add this to a menu, key binding, etc. you have options, babe.

You can kill stop a running instance of FvwmEvent with:

KillModule FvwmEvent Alias

🎀 CONFIGURATION OPTIONS 🎀

FvwmEvent gets config info from fvwm's module configuration database (see fvwm(1), section MODULE COMMANDS), and looks for certain configuration options:

  • *FvwmEvent: Cmd command — this determines the fvwm function that is to be called with the event parameters. you might want to do one of the following (details below, iykyk):
# execute distinct fvwm functions
*FvwmEvent: Cmd

# execute distinct external programs
*FvwmEvent: Cmd exec

FvwmEvent has support for any other external program. e.g: the rsynth 'say' command:

*FvwmEvent: Cmd "Exec /rsynth/say"
*FvwmEvent: destroy_window "window closed"

You can also use fvwm's builtin Echo command as FvwmEvent: Cmd to obtain debug output for fvwm events quietly. I used this setup to debug FvwmAuto:

*FvwmEvent: Cmd Echo
*FvwmEvent: focus_change "focus change"
*FvwmEvent: raise_window "raise window"

You can even call different shell commands for each event just by setting

*FvwmEvent: Cmd exec
*FvwmEvent: add_window 'killname "APPL ERROR"'
  • *FvwmEvent: PassId — specifies that the event action will have an ID parameter added to the end of the command line. most events will have the windowID of the window that the event refers to. the new_desk event will have the new desk number. Monitor events will have the RandR monitor name. heads up on the formats: the windowID is a hexadecimal string preceded by 0x, desk numbers are decimal, and monitor name's are strings. 💅
  • *FvwmEvent: window-manager-event action — binds particular actions to window manager events. the action is appended to the Cmd which is then sent to fvwm for execution. 🫶

Okay so here's the ✨vibe check✨ on every event type that's valid. This is the master list, bestie — if it's not here, it's not a thing 💅

  • add_window — fires when a brand new window gets mapped and is actually visible on screen. new window just dropped 🦋
  • config_info — fires when a module is asking for its configuration. it's giving "pls send my settings" 🥺
  • configure_window — fires when a ConfigureNotify event happens. window moved, resized, whatever — it's notifying you fr fr
  • default_icon — fires when a window's DefaultIcon changes 🎀
  • deiconify — fires when a window id gets deiconified. un-minimized, un-hiding, back on the main stage 👑
  • destroy_window — fires when a window is destroyed. rip window, gone but not forgotten 💀
  • dewindowshade — fires when a window gets unshaded 🌸
  • echo — fires when an Echo command is run
  • end_config_info — fires when there's no more module config left to send. that's a wrap on the config dump ✨
  • end_windowlist — fires when the windowlist has finished sending 📋
  • enter_window — fires when a window receives an EnterNotify event. mouse walked in, no knock 🚪
  • error — DEPRECATED. it's over, it's not coming back, do not use it 🚫
  • focus_change — fires when a window gains or loses focus. main character energy swapping around 🔥
  • icon_file — DEPRECATED ⚰️
  • icon_location — DEPRECATED ⚰️
  • icon_name — DEPRECATED ⚰️

(okay that's three deprecated ones in a row, FVWM really said "we're cleaning house" and honestly? valid.)

  • iconify — fires when a window gets iconified. minimized, tucked away, napping 😴
  • leave_window — fires when a window receives a LeaveNotify event. mouse exited, say bye 🫶
  • lower_window — fires when a window gets lowered. pushed to the back, humbled 😭
  • map — fires when a window is Mapped 🗺️
  • mini_icon — fires when a window's mini icon changes
  • monitor_changed — fires when a monitor's resolution changes. display glow-up in progress ✨
  • monitor_disabled — fires when a monitor gets disabled (via RandR)
  • monitor_enabled — fires when a monitor gets enabled (via RandR) 🌈
  • monitor_focus — fires when a monitor gains focus
  • new_desk — fires when a new desk is switched to 🪑
  • new_page — fires when a new page is switched to 📄
  • old_add_window — DEPRECATED ⚰️
  • old_configure_window — DEPRECATED ⚰️
  • property_change — fires when a window receives a PropertNotify event
  • raise_window — fires when a window gets raised 👑
  • res_class — fires when a window's Class is set
  • res_name — fires when a window's Resource is set
  • restack — fires when windows get restacked
  • sendconfig — fires when FvwmEvent asks for its config
  • shutdown — DEPRECATED 💀
  • startup — DEPRECATED 💀
  • string — fires when the SendToModule command is used
  • unknown — DEPRECATED 💀
  • visible_icon_name — fires when a window's visible icon name changes
  • visible_name — fires when a window's visible name changes
  • window_name — fires when a window's name (WM_NAME) is set
  • windowshade — fires when a window is shaded

okay so the window-related event handlers run inside a window context. Back in the day you needed PassId for that whole situation, but bestie, that's not a thing anymore — using PassId is just not needed now. ✨

The monitor_* events do not operate in a window context (because like… there isn't one, obviously 🙈).

Your event command also gets handed these values:

  • $0: monitor_event_name (like for example: monitor_changed)
  • $1: monitor_name (the RandR name of the monitor)

So like, picture this:

DestroyFunc RandRFunc
AddToFunc   RandRFunc
+ I Exec exec xmessage "Monitor $1 had this event: $0"

DestroyModuleConfig FE-Monitor: *
*FE-Monitor: monitor_changed RandRFunc
*FE-Monitor: monitor_enabled RandRFunc

KillModule FvwmEvent FE-Monitor
Module FvwmEvent FE-Monitor

Say the monitor_changed event triggers — RandRFunc runs, the monitor name comes in as the first argument, and the monitor event comes in as the second argument. So basically you can do further matching if you need to. slay 💅

NOTE: using PassID with a config that has monitor_ lines in it won't work, because there is no ID to pass back. If you still need PassID, separate your monitor events out into their own FvwmEvent configuration. no cap.

The echo event gets generated whenever Fvwm receives an Echo command.

Note: the enter_window event is generated when the pointer enters a window. With the -passid option, that window's id gets passed to fvwm. An enter_window event is also generated when the pointer leaves a window and moves into the root window — in that case, the id passed is 0. 🦋
Note: when the shutdown event arrives, FvwmEvent may get killed before it can even trigger the associated action. 😭
  • *FvwmEvent: Delay 5 — says an event-action only gets executed if it happens at least 5 seconds after the previous event. Events that show up during the delay period? Ignored. The default delay is 0, which disables the Event.
  • *FvwmEvent: StartDelay delay — says an event-action only gets executed if it happens at least delay seconds after the startup event. Events that occur during the delay period are ignored. This one's a lifesaver when fvwm starts and restarts using an audio player. Default delay is 0.

🌈 HISTORY 🌈

This module evolved out of FvwmAudio, which is itself heavily based on a similar Fvwm module called FvwmSound by Mark Boyns. FvwmAudio just took Mark's original program and extended it to make it generic enough to work with literally any audio player. Then, because everyone kept asking to do specific things on specific events, FvwmEvent took it one more step — and now it calls any fvwm function. And if you use fvwm's Exec function, you can call any external program with any parameter. glow up fr fr ✨

👑 AUTHORS 👑

  • 1994 FvwmSound Mark Boyns (boyns@sdsu.edu)
  • 1994 FvwmAudio Mark Scott (mscott@mcd.mot.com)
  • 1996 FvwmAudio Albrecht Kadlec
  • 1998 FvwmEvent Albrecht Kadlec (albrecht@auto.tuwien.ac.at)

and that's the whole page bestie 🫶 this one's from 2026-07-31, and it's the FVWMEVENT(1) manual — go forth and hook up your events, you absolute icon 🎀💖

📦 where this page comes from