reparenting the client's window creates a few issues:
• We get bogus UnmapNotify and MapNotify events that are ultimately
generated by amiwm itself.
• We do not get button events from the window, since its frame
(c->parent) that we have called XGrabButtons(3) onto, is not
its parent anymore.
To fix this, do not reparent the client window, but its frame window.
And keep the client window always inside the frame.
Previously, adding a new atom into the code required:
1. In <icc.h>, add the line `extern Atom my_new_atom;` declaring the new atom.
2. In <icc.c>, add the line `Atom my_new_atom;` defining the new atom.
3. In <icc.c>, add the line `my_new_atom = XInternAtom(dpy, "MY_NEW_ATOM", False);`
interning this new atom, and assigning the interned value to the variable.
Now, just add a line with the atom's name in the X-MACRO in <icc.h>, and
a XInternAtoms(3) and a set of macros will do the rest.
All new atoms will be referred to as an entry in the ATOMS[] array.
For example:
ATOMS[MY_NEW_ATOM]
The exception are for those REALLY OLD atoms that have already a
dedicated compile-time-known value defined at <X11/Xatom.h>. Those
do not need to be interned; and are referred to with a constant
beginning with the `XA_` prefix. For example:
XA_WM_CLASS
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.
This is a pretty straight forward change to remove the global front
variable and instead use a couple of accessor functions.
This hopefully will make it easier to keep track and debug when
the front screen changes.
Although it likely doesn't matter /that/ much, the x11 xlib manual
does say to use it rather than expecting the struct to stay the same
size.
Yeah yeah it's 2022 and we really do build things from source,
ICCCM is likely not going to change that much nowdays, etc, etc.
