The AmiWM manual was kinda incomplete. It does not describe how the WM
works, does not list all the configuration commands, nor the modules.
This commit rewrites the manual into the mandoc format, fill in the
gaps, and makes its section structure more standardized.
AC_HEADER_TIME is only needed if you need to include time.h and
sys/time.h at the same time.
The truth is this codebase is an unholy mess but at least this fixes
the warnings.
EINTR is happening during suspend/resume, which was causing all of
the modules to die (and requiring a restart of amiwm to re-run all
of its modules.)
This fixes things in FreeBSD suspend/resume so, well, the modules
keep working. :)
This allows a keyboard shortcut to move a client to a different amiwm
screen. That way when you have things like Firefox restart every window
in a single screen, you can quickly move screens to where they should be.
If the clock timer fires when global scr is NULL then we end up calling
redrawmenubar() with a NULL global scr, but a valid local scr.
So just pass in the scr used when doing "stuff" into redrawmenubar(),
making the 'scr' in redrawmenubar() also local scope.
* fix whitespace
* filesystem / jokefs rule implication stuff was working fine in GNU make
but not in BSD make, so fix it there
* Remove the $(srcdir)/module thing, because it was tripping up BSD make
rules. The "./" is just making it angry.
Tested:
* FreeBSD, gmake and make
The README file in this repo is called README.md and the old
README.modules is now named MODULES.md. Changed references to those
files (including in the man page) to reflect what is in the repo today.
This is the beginning of adding some battery display support into the menu and figuring out how to add arbitrary widgets into the menu bar.
It's going to take a bunch more commits / time to clean this up to be more flexible, but at least now we have an MVP of adding a new "thing", buggy as it is.
* add a batteryinfo config option to enable whether or not to display
the current battery info string
* populate that battery info string whenever we receive a battery
update from the module
* document it all
This is very specific to a battery thing rather than a generic menu
widget thing, but I think I'll go and twiddle with this stuff a bit
more first and then work on a more generic "menu widget" thing later.
It'd be nice to have "menu bar things" like battery and the date/time
field on a linked list of "things".
There's also some bugs - notably, rendering artifacts when the
string length shrinks, and it only updating on the 'current' menu bar
(when you have multiple desktops visible at once.) Those also
should be fixed for completeness. :-)
Tie into the periodic function so we can get the APM info.
For now it's not checking that some time has elapsed, the hope
is that it'll just be driven by md_main_loop() / 5 second select
timeout.
* add a basic select() loop for the read FD to see if it's ready
* optionally block in md_read() even if we timeout - this is used for
the md_command() side of things
* md_handle_input() however doesn't block and will happily timeout
so the loop can run and the periodic function can run.
This indeed seems to work. It's a bit dirty, but it at least stops
the main loop from being fully blocking and that's super useful for
modules that wish to schedule background work.
* Yeah it'd be nice to just use libevent here, alas
* Figure out how all the reading/writing works and comment it
* Add a periodic function that'll be called every trip through
the main loop; will turn it into something more formally periodic
later.
There's still lots to do here before I can actually schedule
periodic events and the read()s are non-blocking. Give it time!
Totally not ready for prod, but at least I'm making progress
figuring out how to add extra bits to this thing.
* add a second widget to the menu bar, next to the title bar
* add a new module command to update the battery information
* add a freebsd specific Battery module, not linked into the
build right now.
* amiwm will print out whenever we get battery information from the
module.
Right now I'm trying to figure out how to get some kind of periodic
background event into the module main loop. Launcher does it
using cx_broker(), but I dunno if I can adapt that pattern here.