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.
If a window has the skip_window_list flag set wmaker currently not only skips
this window from the window list (F11) but also from the switchpanel (TAB).
This patch makes skip_window_list-windows appear in the switchpanel and be
skipped only in the window list, strictly honoring what the name of the flag
is supposed to mean.
The motivation for this is that I have lots of workspaces and almost all of
them has a xterm, so that I set the skip_window_list for the xterms not to
overcrowd the window list. But I still want to alt+TAB to xterms on the current
workspace.
In addition to that, now the "internal window" flag is not checked before
appearing in the switchpanel.
- Kill unused vars in wrlib
- Add missing initializers to defaults.c:staticOptionList
- Re-format it slightly
- Kill some dead code
- Kill stupid "if (const op var)"
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()?
When using Xinerama, make it possible only to cycle between those
windows that are on the currently active head - AFAICT this means
windows that have the majority of their area on the same head as
the pointer.
Patch complete with WPrefs integration, alas this being quite
unusable - for a lack of a better idea, I tucked the option on the
expert panel, making the item list too tall - making it scrollable
would be a nice addition.
The default for the new option (CycleActiveHeadOnly) should be NO,
that is, no change in default behaviour.
The rationale is the same as in commit c7f2a189c4
("Fix the call to XChangeProperty() in 64-bit mode"), because we are
calling XChangeProperty() with format 32, which requires the type of
'data' to be 'long'.
- Does away with the O_BINARY abomination
- as a byproduct, plugs an fd leak in wcolorpanel.c:fetchFile()
- sprinkle some fsync()s to files that have been written to (this
needs to be done everywhere)
+ fix brown paper bag thinko in configure.ac
* Remove directly include of <libintl.h> and include src/wconfig.h, that
already include libintl.h and declare _() function
* Replace some gettext() calls to _()
These changes fixes build with LINGUAS is unset, and removes I18N
support in this case.
- tested on Net, Free, Open and DragonFly
- fix up the linux version (terminate argv with a null ptr)
- add error handling to file ops in the linux version
- add a stub version for platforms not supported
In the wmaker-dev list, Iain noted that:
"I can see the benefit of this. I know of at least two
applications[1] which don't bother to set a class and instance. Early
versions of my OS X cycling patch for Window Maker caused a crash when
faced with such windows because I forgot to check that these
properties existed. Nowadays it just refuses to do the cycling.
Also Window Maker won't let you save attributes on such windows from
the Inspector.
[1] Interestingly they are competiting commercial applications: No
Machine and Exceed onDemand."
[crmafra: edit commit log]
- make it use wings functions, remove duplicated code from getstyle
- de-static necessary functions in wings
- add new wrmdirhier to wings
- rename WMMkDirHier to wmkdirhier (fits better)
- remove calling shell from getstyle (what were they thinking?)
i couldn't quite test getstyle (no idea about themes), but it still
basically works.
do back your ~/G dir up... wrmdirhier might eat it!
definitely needs testing, especially by people who have any idea
how themes work.
Some more getstyle
- missed a shell invocation
- maybe copyFile should be in wutils too...?
[crmafra: Folded second patch into the first]
By defining a struct containing the coordinates of the
windows (top, bottom, left, right, width, height) and
using a helper function to set up these coordinates, the
whole function becomes much cleaner and easier to read.
It addresses this warning
dialog.c: In function ‘LoadHistory’:
dialog.c:209: warning: passing argument 2 of ‘WMFindInArray’ from incompatible pointer type
../WINGs/WINGs/WUtil.h:455: note: expected ‘int (*)(void *, void *)’ but argument is of type ‘int (*)(const void *, const void *)’
but induces others in other places. One of them was this one
window.c: In function ‘wManageWindow’:
window.c:782: warning: passing argument 2 of ‘WMFindInArray’ from incompatible pointer type
../WINGs/WINGs/WUtil.h:455: note: expected ‘int (*)(const void *, const void *)’ but argument is of type ‘int (*)(void *, void *)’
which is fixed by constifying the arguments of matchIdentifier(). The other warnings are
fixed similarly.
WindowMaker.h already #includes wconfig.h, which checks exactly
the same thing. So remove it from WindowMaker.h.
However, it would be better if WindowMaker.h didn't include
wconfig.h at all. The only reason I see for the inclusion is
the check for KEEP_XKB_LOCK_STATUS, defined in wconfig.h.
But that can be probably cleaned up too (I guess modern X's
enable XKB stuff that by default, by I haven't checked)
But anyway.
remove the choice of atomic/non-atomic writes. firstly, the only users
of non-atomic writes were getstyle and geticonset; secondly, who in their
right minds would ever want non-atomic writes; thirdly, the file system
will screw you anyway *G*.
Taking the border width into account was making it hard to follow the
algorithm, and complicating things usually lead to mistakes.
In fact, in trying to account for this +/- 1 pixel issue the maximus
geometry for the requested window would sometimes overlap another window
by one or two pixels (depending if it was on the right or left). Therefore,
applying the maximus geometry to this other window in sequence would
maximize it completely instead of finding the correct tiled geometry.
So that always bugged me. Now I got tired of it and decided to kill the
whole consideration of the border width, and simply put some "+ 1"
inconditionally to be on the safe side.
Now it can happen that the windows will stay away one or two pixels,
but trying to be 'good enough' is better than trying to be 'perfect'
and getting it wrong for corner cases.
And the matter is worse because the size of xterms are 'quantized', so
changing the position of the other windows by a few pixels result sometimes
in a overlap of +1 pixel, or a distance of 1 or 2 pixels. Furthermore,
the bottom of xcalc behaves differently from the bottom of a xterm or
xjed (for xcalc the ad hoc correction for bottom_0 must be -8 in total).
But now my tests show that things are OK, and I can use maximus
for all the windows in the screen and no overlap will occur (except
if one of the windows is a xcalc, I don't know why).
It wasn't defined anywhere and when I defined it, the compilation
did not finish:
appicon.c: In function drawCorner:
appicon.c:206: error: WScreen has no member named focused_texture
appicon.c:208: error: WScreen has no member named unfocused_texture
appicon.c: At top level:
appicon.c:214: error: conflicting types for drawCorner
appicon.c:193: note: previous definition of drawCorner was here
make[2]: *** [appicon.o] Fehler 1
make[1]: *** [all] Fehler 2
make: *** [all-recursive] Fehler 1
So let's simply remove those #ifdefs.
This patch only calls XGrabButton for CTRL+Button4 and CTRL+Button5.
This leaves CTRL+Button1-3 to the application.
This then removes the functionality of moving a window between
workspaces with CTRL+Button1 and CTRL+Button3
This patch constrains MOD+Wheel to vertical resize, and adds
CTRL+Wheel horizontal resize. Two resize in both directions, you
have to use CTRL+MOD+Wheel.
To enable this functionality I have to grab all CTRL+Mousebutton
events in wmaker, which stops them from reaching the application.
This definitely hurts application functionality in some apps, for
example the "VT Fonts" (CTRL+Button3) menu in xterm is no longer
accessible. To stop this from happening use the "Do not bind mouse
clicks" window attribute for the apps in which you want to disable
this.
Because wmaker now controls all CTRL+Mousebutton events, I also
added CTRL+Button1 and CTRL+Button3 shortcuts that will move a
window back and forth through your workspaces without changing its
position or size.
The autocomplete feature in the "Run" dialog now adds a trailing "/"
when autocompleting directory names. This does three things:
1) shows you that you are completing a directory and not a filename,
2) saves one character of typing, and
3) makes it behave more consistent with shell (bash) autocompletion
