In C, dividing two integers automatically rounds towards zero, so ceil(a
/ b) is useless as the result is truncated before ceil ever sees it. The
correct result for positive integers is obtained by (a + b - 1) / b.
I personally cannot stand stealing Ctrl+Wheel for resizing windows, so I
turned it off. But wmaker is still preventing Ctrl+Wheel from reaching
apps, which is certainly not the behavior I desire.
We grab Mod+Button events for our own purposes, and swallow them using
XAllowEvents(AsyncPointer) to prevent the client window from seeing
them. But if events are coming in fast enough (e.g. via fast wheel
scrolling) so that multiple grabbed events are in the queue, the second
queued event would be allowed to leak through to the client by the
unconditional XAllowEvents(ReplayPointer) a few lines later.
One misuse of CARD32 was missed back when someone fixed the 64-bit
issues (background: X has 8-bit, 16-bit, and "32-bit stored in a long"
data formats; on a 64-bit system, long is 64 bits). This was causing
minimized windows to be restored as shaded, and possibly occasional
crashes, when wmaker was restarted.
Also, throw in a safety check that 10 items really were returned before
trying to access them.
The "make dist" command can be used to generate the release tarball, but
only if the Makefile.am correctly specifies EXTRA_DIST, specifies
headers in foo_SOURCES, and so on.
Initialized variables that are conditionally set. In particular, this
construct is dangerous:
void *p;
if (something) p = couldReturnNull();
if (!p) p = fallbackFunction();
C99 defines new strict aliasing rules to allow compilers to make certain
optimizations. These rules prohibit converting an XEvent to an event
struct (e.g. XShapeEvent) that is not already in the XEvent union using
pointer type punning (e.g. "(XShapeEvent *)&ev"), and vice versa. The
canonical fix seems to be to create a union between XEvent and the
extension event struct to make the aliasing explicit, so do that.
A few internationalized format strings have only one %s in the default
while two strings are being passed. Change those defaults to have two
%s's, which means we also have to update the .po files to match. May as
well throw in the extra %s in the translated version while we're at it.
I noticed a bug today in menu workspace positioning (in the next tree):
if I right-click and hold the button down at the left edge of the
screen, the menu appears (correctly) half off the edge but will *not*
slide back onto the screen. Compare the behavior to right-clicking at
the right edge of the screen: the menu appears half off the edge, but
sliding the mouse to the edge causes the menu to slide until it is fully
visible.
Also, opening a submenu in this state positions the submenu as if the
menu were fully on the screen, leaving a gap between the menu and the
submenu.
If the menu happens to also go off the bottom of the screen, moving the
mouse to the bottom edge causes the issue to be magically fixed as soon
as the sliding upwards begins.
I also note inconsistent behavior when simply right-clicking (without
holding) to bring up the menu: at the right or bottom edge the menu
appears in the correct partially off the edge position, but at the left
edge it immediately jumps to be fully on-screen, almost as if
WrapMenus = YES were set for the left edge only.
I bisected it to d316260395. As far as I
can tell the "fix" there was to position the menu at the correct
negative X position but then lie to wmaker so it thought the menu was at
X=0. Presumably the "WrapMenus" behavior was the intended result.
Since (AFAIK) the window menu is the only one with this problem, why
don't we just check if x is too negative in OpenWindowMenu()?
This patch adds the DockRaiseLowerKey shortcut, which raises/lowers
the dock depending on whether the dock is lowered/raised.
[crmafra: Reformatted Brad's patch against git repo and removed the
DockRaiseKey and DockLowerKey shortcuts ]
Brad Jorsch