it's not a process.
as such.
and the "process", such as it is, occurs all the time anyway on your system.
Awesome uses a layer of coding (rc.lua parts of) to decide how to order the windows when presented to the window manager.
we insert a couple of hooks into that at key stages to coerce the naming of any application that DONT match the required title protocol (
Nyoxi post) so that they DO fit.
Currently I do this via xdotool.
It just silently ignores anything that
is properly named.
So is there overhead?
meh. the process would be I suppose /mnt/us/extensions/fronter/
echo.sh
you can view the very simple details in /extensions/fronter/arch/command.patch
one way to stop the functionality would be: (This is what I do)
umount /etc/xdg/awesome
killall -9 awesome
The fact that the rc.lua is parsed AT LOAD TIME by awesome is what ties my hands.
There is in the STANDARD awesome a key combination to reload the config.
That appears to have been stripped out by amazon far as I can tell.
So yeah.
rc.lua patched to have a link to /mnt/us/extensions/fronter/
echo.sh
patched copy of amazon code exists in a bind mount /etc/xdg/awesome <-- This is why it get's lost. on reboot. Intentional to stop anything really bad happening in an unrecoverable way
simple as that.
currently the performance is frankly terrible. It could easily be improved by logically sorting which things to throw at xdotool rather than using xdotool to determine that.