Menus

Package wmenu creates menus for cli programs. It uses wlog for it's interface with the command line. It uses os.Stdin, os.Stdout, and os.Stderr with concurrency by default. wmenu allows you to change the color of the different parts of the menu. This package also creates it's own error structure so you can type assert if you need to. wmenu will validate all responses before calling any function. It will also figure out which function should be called so you don't have to.

Package wmenu creates menus for cli programs. It uses wlog for it's interface with the command line. It uses os.Stdin, os.Stdout, and os.Stderr with concurrency by default. wmenu allows you to change the color of the different parts of the menu. This package also creates it's own error structure so you can type assert if you need to. wmenu will validate all responses before calling any function. It will also figure out which function should be called so you don't have to.

Package wmenu creates menus for cli programs. It uses wlog for it's interface with the command line. It uses os.Stdin, os.Stdout, and os.Stderr with concurrency by default. wmenu allows you to change the color of the different parts of the menu. This package also creates it's own error structure so you can type assert if you need to. wmenu will validate all responses before calling any function. It will also figure out which function should be called so you don't have to.

Package wmenu creates menus for cli programs. It uses wlog for it's interface with the command line. It uses os.Stdin, os.Stdout, and os.Stderr with concurrency by default. wmenu allows you to change the color of the different parts of the menu. This package also creates it's own error structure so you can type assert if you need to. wmenu will validate all responses before calling any function. It will also figure out which function should be called so you don't have to.

Package wmenu creates menus for cli programs. It uses wlog for it's interface with the command line. It uses os.Stdin, os.Stdout, and os.Stderr with concurrency by default. wmenu allows you to change the color of the different parts of the menu. This package also creates it's own error structure so you can type assert if you need to. wmenu will validate all responses before calling any function. It will also figure out which function should be called so you don't have to.

Package bananas is a Go library for interfacing with the dining hall menus at the University of California Santa Cruz At UCSC there are five (5) dining halls. One for each pair of colleges in the ten college system. Each dining hall has it's own menu that can be viewed online here: https://nutrition.sa.ucsc.edu Many students have built third party menu viewers -- each with their own method of parsing the website (manual web scraping is necessary as there is no public API). And this is where bananas comes in. Bananas will serve as the engine for a new API server that is in development, so that students can build custom web views, apps etc. . Bananas will also be available for everyone, so that they too can build awesome stuff with it. To use bananas simply call MenuFor with one item from each of the following lists: Dining Halls (Choose one (1)): Meals (Choose one (1)): Time: Any struct that is time.Time will satisfy this parameter. Note that the actual time (e.g 12:00PM) is ignored and only the date is used. Here are some common uses for bananas. Note that each of these calls will make two (2) http requests. One for the menu data, and another to set the cookies. If you would like to only have one http request per call use bananas.Client

Package cfa implements communication with Crystalfontz LCDs such as CFA-631 and CFA-635, without use of CGO. In addition, this package supports keypress events and menus. The following can be found beginning on Pg 34, CFA631_Data_Sheet_Release_2014-11-17.pdf. All packets have the following structure: type is one byte, and identifies the type and function of the packet: data_length specifies the number of bytes that will follow in the data field. The valid range of data_length is 0 to 22. data is the payload of the packet. Each type of packet will have a specified data_length and format for data as well as algorithms for decoding data detailed below. CRC is a standard 16-bit CRC of all the bytes in the packet except the CRC itself. The CRC is sent LSB first. At the port, the CRC immediately follows the last used element of data []. See Sample Algorithms To Calculate The CRC (Pg. 66) for details. The following C definition may be useful for understanding the packet structure. While the documentation can be interpreted as saying the packet size is fixed, it is not; there is never padding between the last valid data byte and the crc, and the packet length is always data_length+4. Crystalfontz claims above that the CRC used is standard, but a bit of googling leads me to the conclusion that there is no such thing. There are myriad variations of 16-bit CRC with different constants, and the sites discussing it tend to disagree on which constants are used by which protocols. Very few standards actually include any test vectors. Crystalfontz' own data sheets for the 631 and 635 include a test vector in one example... but the output listed does not match the value computed by the "crystalfontz linux example", which is able to talk to the LCD. The CFA-631 and XES-635BK-TML-KU work fine, but the XES-635BK-TMF-KU can hang or otherwise lose packets. By far the most effective workaround seems to be to minimize the number of packets sent. Of course, that's not possible beyond a certain point without throwing usability out the window. We have shipped some XES-635BK-TFE-KU. The only difference from the TMF should be the display/backlight color, so those are likely to have the same issues as TMF. Key event reports (and responses to the key poll command) are written to an event channel for async read. Only key releases are considered. Reading key press events or keys being held down (only seen when polling) would not be difficult, but handling them with the menu would complicate things.

Package menu provides a data structure to represent nested menus such as those that might appear on a web page. The basic unit is a ListItem, which may be either a List or an Item. An Item consists of a label (e.g. the text that appears, or perhaps a key to a translation table when localized text is needed) and an action (e.g. a url path). A List consists of a label and a list of ListItems. An Item may optionally have a visibility mask, which may be used when certain parts of the menu need to be dynamically hidden. A example of when this might be useful is an admin submenu which is only visible to authenticated admin users. The Filtered() method is used to hide parts of a menu based on a bitmask. The provided bitmask is and-ed with the visibility mask of each Item, and the item is shown only if the result is nonzero. A visibility mask may also be applied to a List. If a List is hidden, all the Lists and Items under it are also hidden. Menus hay have arbitrary depth, although recursive menus are not supported and will crash. Menus play well with json.Marshal (see the examples).

Package wmenu creates menus for cli programs. It uses wlog for it's interface with the command line. It uses os.Stdin, os.Stdout, and os.Stderr with concurrency by default. wmenu allows you to change the color of the different parts of the menu. This package also creates it's own error structure so you can type assert if you need to. wmenu will validate all responses before calling any function. It will also figure out which function should be called so you don't have to.

Command goconfig is a utility to configure GO packages in the style of the Linux kernel whereby the developer declares configurable parameters and the user runs this much like `make menuconfig && make ...` to configure, build, test, and install. Goconfig has CLI, TUI and webserver menus. Goconfig should be functional on any GO supported OS/ARCH but is primarily developed and tested with `linux_amd64`. Similarly, the webserver is only tested with Chrome, Safari, w3m, and elinks; however, its basic HTML and CSS should be compatible with most browsers. Goconfig reads parameter declarations from these files within the top source directory of the subject package. With duplicate declarations, goconfig has this top to bottom precedence. Goconfig loads and stores configured parameters with a file named, Configurable build flags, constraints (aka. tags), and strings may be declared by simple mapped entries with the type implied from the initialized value. So, the parameter is a boolean flag or tag if initialize with true or false; and a string otherwise. You may also declare parameters with mapped fields where the type is implied from the value of the `init` field. You may declare a boolean `race` flag and these string flags: ccflags, compiler, gccgoflags, gcflags, installsuffix, ldflags. Since `race` is only supported on `amd64`, you should declare this in either of these architectural specific files: Build constraints or tags are declared with simple or `init` field boolean values. You may also initialize constraints from a command result using either `!!status` or `!!not-status` pseudo-types like these, You must preface string names with the GOPATH or relative package name; for example: You may initialize strings with command output using an `!!output` pseudo-type like this, Goconfig accepts these mapped declaration fields: As stated above, `init` is the initial value that implies the parameter type. The `help` field is text displayed by the respective menu mode. You may the include YAML '|' and '>' scalar indicators to preserve or modify formatting. The set of permitted strings values are declared with a `choices` list: The CLI, TUI, and webserer menus present pulldown selectors to limit strings to these values. However, the package should validate all configurable parameters. The `set` and `reset` fields are mapped values that get applied when the parameter is set or reset through the respective menu. Use this to define exclusive or dependent relationships between parameters. You may import declarations from one or more dependent packages like these, or make relative import of local packages, ...

Command goconfig is a utility to configure GO packages in the style of the Linux kernel whereby the developer declares configurable parameters and the user runs this much like `make menuconfig && make ...` to configure, build, test, and install. Goconfig has CLI, TUI and webserver menus. Goconfig should be functional on any GO supported OS/ARCH but is primarily developed and tested with `linux_amd64`. Similarly, the webserver is only tested with Chrome, Safari, w3m, and elinks; however, its basic HTML and CSS should be compatible with most browsers. Goconfig reads parameter declarations from these files within the top source directory of the subject package. With duplicate declarations, goconfig has this top to bottom precedence. Goconfig loads and stores configured parameters with a file named, Configurable build flags, constraints (aka. tags), and strings may be declared by simple mapped entries with the type implied from the initialized value. So, the parameter is a boolean flag or tag if initialize with true or false; and a string otherwise. You may also declare parameters with mapped fields where the type is implied from the value of the `init` field. You may declare a boolean `race` flag and these string flags: ccflags, compiler, gccgoflags, gcflags, installsuffix, ldflags. Since `race` is only supported on `amd64`, you should declare this in either of these architectural specific files: Build constraints or tags are declared with simple or `init` field boolean values. You may also initialize constraints from a command result using either `!!status` or `!!not-status` pseudo-types like these, You must preface string names with the GOPATH or relative package name; for example: You may initialize strings with command output using an `!!output` pseudo-type like this, Goconfig accepts these mapped declaration fields: As stated above, `init` is the initial value that implies the parameter type. The `help` field is text displayed by the respective menu mode. You may the include YAML '|' and '>' scalar indicators to preserve or modify formatting. The set of permitted strings values are declared with a `choices` list: The CLI, TUI, and webserer menus present pulldown selectors to limit strings to these values. However, the package should validate all configurable parameters. The `set` and `reset` fields are mapped values that get applied when the parameter is set or reset through the respective menu. Use this to define exclusive or dependent relationships between parameters. You may import declarations from one or more dependent packages like these, or make relative import of local packages, ...

Bubbleo is a collection of [BubbleTea] components for building robust terminal user interfaces. Initially we are supporting hierarchical menus, via a navigation stack and supporting components such as breadcrumbs, menus, and a composit component called shell which puts them all together. [BubbleTea]: https://github.com/charmbracelet/bubbletea

Package wmenu creates menus for cli programs. It uses wlog for it's interface with the command line. It uses os.Stdin, os.Stdout, and os.Stderr with concurrency by default. wmenu allows you to change the color of the different parts of the menu. This package also creates its own error structure, so you can type assert if you need to. wmenu will validate all responses before calling any function. It will also figure out which function should be called, so you don't have to.

Rofi is a versatile application launcher and window switcher for X11. The "rofigo" package allows you to easily create and display interactive menus in your command-line applications using Rofi. With "rofigo," you can define custom menus with items, labels, icons, and actions, providing a user-friendly way to navigate and interact with your application. This package consists of the following key components: MenuItem: Represents an item within a menu. Each MenuItem has a label, an associated action, and an optional icon. Menu items can be customized to perform specific actions when selected. Menu: Represents a collection of menu items along with an optional prompt. Menus are used to group related items together and provide a user-friendly interface for selecting actions. RofiRunner: A utility for running Rofi-based menus with custom options. You can create an instance of RofiRunner and execute Rofi menus with specific settings, such as prompts and menu items. Here's a simple example of how to use "rofigo" to create a menu and run it with Rofi: This code creates a menu with two options and executes it using Rofi. The "rofigo" package relies on external tools like Rofi, so make sure you have Rofi installed on your system to use this package.