You are not logged in.
My latest tinkering with the Xembed protocol and system tray specification has lead to the creation of Blueplate.
The backstory is that I recently put aside a project to make a fully EWMH-compliant yet light fullscreen window manager. Instead I configured openbox to do just what I'd want for that [1]. But I still wanted some simple indicators in a taskbar. So I decided to make a tool to put indicators into the system tray - I hadn't known before how simple that was. These are non-interactive, but they display the information I want. I've bundled them as modules in a single program called blueplate. From blueplate on gituhub[2]:
BluePlate "With all the fixins"
Description
Blueplate is a system tray client program with a modular approach. Each module can provide one or more informational icons for a system tray. Blueplate does not itself provide the tray application but will work with trays including tint2.
Blueplate modules will remain as small and simple as possible. The modules are not designed to provide interaction (no menus, etc) but serve as indicators. Currently two modules exist: desktops and mail.
Current Modules
Desktop: Shows a desktop/workspace indicator on window managers that provide the necessary EWMH hints. Desktop indicator layout, size, and colors are defined in config.h. By default, a 2x2 grid of spaces is used with colors as defined in the config.h.
Mail: Shows a colored mail icon when there is mail in any number of maildir folders. Each folder is configured with a color used to indicate mail in that folder. The default config.h provides a template for two maildir accounts in ~/mail/ - these must be edited to match the actual paths.
Potential Upcoming Modules
Note: By using Xlib events for property changes for the desktop monitor, and using inotify events for maildir changes, the current modules avoid any tradeoff between resolution of timing and resource use. Changes in the maildir can be detected immediately without having a rapid infinite loop. A goal for future modules will be to find designs that allow for a similar efficiency, though this may not be practical for all modules.
Weather: A current conditions indicator, potentially using shaman [3]
CPU Load:
Usage
Blueplate forks a process for each module specified on the command line. There is no need to background blueplate:
$ blueplate <module> [ <module> ... ]
I'd be happy to hear ideas of other modules to add. The PKGBUILD should be posted to the AUR soon. I'll also make it easier to selectively pick and chose which modules to compile in soon; for now this can by done by editing the MODULES line in the makefile. At this point there are only two modules, so that likely isn't an issue (both are compiled by default).
I'd be much more happy if someone has ideas on how to update weather or cpu load information without having a time-based loop (see the note in the quote above). I'm not sure this is possible - but nothing has been known to be possible until someone came up with a way to do it. I like looking at the htop output and seeing that blueplate uses 0.0% of my CPU and 0.0% of memory
[1] Openbox + tint2 configs: https://github.com/TrilbyWhite/junkdraw … nbox-stuff
[2] Blueplate on github: https://github.com/TrilbyWhite/Blueplate
[3] Shaman, by our own HalosGhost: https://github.com/HalosGhost/shaman
EDIT: I just realized the modular compiles don't currently work. I guess that code was still stored just on the BDD (biological disk drive), it should be up on git soon enough, though that is currenly low priority as with only two current modules, modularity isn't that bit of a deal. (edit2: this is done, but not yet well tested).
Last edited by Trilby (2015-01-05 14:17:34)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline