driver(3MENU)

πŸ’– driver(3MENU) πŸ’–

ok so bestie, welcome to driver(3MENU) β€” it's a manual page from the library calls section, and it's literally the manual page for menu_driver, the command-processing loop of the menu system. yes the whole page is about ONE function. she's an icon, she's a legend, and she is the moment. let's get into it ✨


🌸 NAME 🌸

menu_driver β€” the command-processing loop of the menu system


✨ SYNOPSIS ✨

#include <menu.h>

int menu_driver(MENU *menu, int c);

πŸ¦‹ DESCRIPTION πŸ¦‹

so here's the tea: once you've posted your menu (aka displayed it, she's out there living her best life), you're supposed to funnel all your input events into her through menu_driver. that's the whole vibe. this routine handles three major input cases, and they are:

  • the input is a menu navigation request. these request codes are constants defined in menu.h, and bestie, they are distinct from the key- and character codes you get back from wgetch(3NCURSES). don't mix them up, i'm begging πŸ™
  • the input is a printable character. printable characters (which have to be positive and less than 256, no exceptions) get checked according to your program's locale settings 🌍
  • the input is the KEY_MOUSE special key that's associated with a mouse event 🐭

now, the menu driver requests, in all their glory:

  • REQ_LEFT_ITEM β€” move left to an item.
  • REQ_RIGHT_ITEM β€” move right to an item.
  • REQ_UP_ITEM β€” move up to an item.
  • REQ_DOWN_ITEM β€” move down to an item.
  • REQ_SCR_ULINE β€” scroll up a line.
  • REQ_SCR_DLINE β€” scroll down a line.
  • REQ_SCR_DPAGE β€” scroll down a page.
  • REQ_SCR_UPAGE β€” scroll up a page.
  • REQ_FIRST_ITEM β€” move to the first item.
  • REQ_LAST_ITEM β€” move to the last item.
  • REQ_NEXT_ITEM β€” move to the next item.
  • REQ_PREV_ITEM β€” move to the previous item.
  • REQ_TOGGLE_ITEM β€” select/deselect an item. the duality of woman πŸ’…
  • REQ_CLEAR_PATTERN β€” clear the menu pattern buffer.
  • REQ_BACK_PATTERN β€” delete the previous character from the pattern buffer.
  • REQ_NEXT_MATCH β€” move to the next item matching the pattern match.
  • REQ_PREV_MATCH β€” move to the previous item matching the pattern match.

so if that second argument is a printable character, the code appends it to the pattern buffer and tries to move to the next item that matches the new pattern. and if there's no such match? menu_driver returns E_NO_MATCH and deletes that appended character from the buffer. she said "never mind, forget i said anything" 😭

and if the second argument is one of those pre-defined requests up there, then boom, the corresponding action happens. periodt.

🐭 Mouse Handling 🐭

if the second argument is the KEY_MOUSE special key, the associated mouse event gets translated into one of those pre-defined requests from above. currently, only clicks in the user window (so like, inside the menu display area or the decoration window) are handled. don't get any ideas about clicking elsewhere πŸ‘€

if you click above the display region of the menu:

  • a REQ_SCR_ULINE is generated for a single click,
  • a REQ_SCR_UPAGE is generated for a double-click and
  • a REQ_FIRST_ITEM is generated for a triple-click.

if you click below the display region of the menu:

  • a REQ_SCR_DLINE is generated for a single click,
  • a REQ_SCR_DPAGE is generated for a double-click and
  • a REQ_LAST_ITEM is generated for a triple-click.

if you click at an item inside the display area of the menu:

  • the menu cursor is positioned to that item. πŸ“
  • if you double-click an item, a REQ_TOGGLE_ITEM is generated and E_UNKNOWN_COMMAND is returned. and honestly? this return value makes sense, because a double click usually means an item-specific action should be returned. like, that is exactly the purpose of this return value β€” to signal that an application specific command should be executed. she's not being difficult, she's being communicative 🫢
  • if a translation into a request was done, menu_driver returns the result of this request.

and if you clicked outside the user window, or the mouse event just could not be translated into a menu request? you get an E_REQUEST_DENIED back. sorry bestie πŸ’€

πŸ’œ Application-defined Commands πŸ’œ

if the second argument is neither printable, nor one of those pre-defined menu requests, nor KEY_MOUSE, then the driver assumes it's an application-specific command and returns E_UNKNOWN_COMMAND. application-defined commands should be defined relative to MAX_COMMAND, which is the maximum value of those pre-defined requests. know your range, queen πŸ‘‘


πŸ”₯ RETURN VALUE πŸ”₯

menu_driver returns one of the following error codes, and every single one of them is here, no skips:

  • E_OK β€” the routine succeeded. we love to see it πŸŽ‰
  • E_SYSTEM_ERROR β€” system error occurred (see errno(3)).
  • E_BAD_ARGUMENT β€” routine detected an incorrect or out-of-range argument.
  • E_BAD_STATE β€” routine was called from an initialization or termination function.
  • E_NOT_POSTED β€” the menu has not been posted.
  • E_UNKNOWN_COMMAND β€” the menu driver code saw an unknown request code.
  • E_NO_MATCH β€” character failed to match.
  • E_REQUEST_DENIED β€” the menu driver could not process the request.

🌈 PORTABILITY 🌈

these routines emulate the System V menu library. they were not supported on Version 7 or BSD versions. and the support for mouse events? that's ncurses specific, so don't go expecting it everywhere πŸ–±οΈβœ¨


πŸ‘‘ AUTHORS πŸ‘‘

Juergen Pfeifer. manual pages and adaptation for new curses by Eric S. Raymond. absolute legends, both of them πŸ’–


🌸 SEE ALSO 🌸

ncurses(3NCURSES), getch(3NCURSES), menu(3MENU)


ok that's the whole page, you're fully caught up, go forth and drive some menus 🧚 and one last thing before you close the tab β€” this was ncurses 6.6, dated 2025-10-04, and the page itself is driver(3MENU). slay, bye bestie πŸ’…πŸŽ€

πŸ“¦ where this page comes from