thise commit added focus_policy member to E_Border as something to be used for setting a per-window focus policy. setting it on each window is a huge pain if the global policy ever changes, so it's better to use this member only as an override for the global policy which can be checked to see if it's been set
this fixes stacking after restarts since we manage and raise windows from the bottom up, meaning that we must also build our focus stack from back to front
i got a segv in an strncpy... but the bt missed telling me anything
other than it was in _e_border_eval(). gdb wouldn't help.
Thread 1 (Thread 0xb7859780 (LWP 1377)):
No symbol table info available.
No locals.
No symbol table info available.
No locals.
at /usr/include/i386-linux-gnu/bits/string3.h:121
buf = '\000' <repeats 4095 times>
s = <optimized out>
event = <optimized out>
pnd = <optimized out>
rem_change = 1
send_event = 1
since this is the only strncpy, i can only conclude that something is
fishy about the src or dest buffer, and i can only guess that the
strncpy is directly in e_border.c (though it could have come from an
inline func or macro form eina etc.)... but it's the best guess i have.
the strncpy will have problems if bd->client.icccm.class > 4096 in
size. buf will not be nul terminated then:
The strncpy() function is similar, except that at most n bytes of src
are copied. Warning: If there is no null byte among the first n bytes
of src, the string placed in dest will not be null-terminated.
as per manpage. so there was a lurking bug with a non 0 terminated
buffer. also added check for bd->client.icccm.class as it could be
null...
1) invalidate moves resulting from stupid clients trying to re-set their current position (SUP WINE. YEAH, I'M TALKIN TO YOU, BUDDY. WHY YOU GOTTA BE MESSIN WITH MY WINDOW COORDS?)
2) clamp coords when screen limit policy is set to prevent clients from being outside the screen at all
3) all things are allowed, nothing is prohibited
geometry_auto_move is an option which should only be applied to "new" clients. we were erroneously applying it during client move/resize requests, which likely was causing unintended behavior. if this becomes an issue, the correct solution is to create (groan) another option to enforce window placement policy either [at all times] or [for client geometry requests]