* 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
Once upon a time (< 2005) the CachedPixmaps directory was located
at ~/GNUstep/.AppInfo/ and that was later moved to
~/GNUstep/Library/WindowMaker. So Dan Pascu introduced this function
in 24519b6292 to make the convertion
automatically to users back then.
As it is highly unlikely that there is an old-timer wmaker user still
running a pre-2005 wmaker which suddenly decides to switch to wmaker-crm
and runs into trouble with his CachedPixmaps folder, let's simply remove it
to make defaults.o 1.8% smaller (596 bytes).
Even the option to enable "virtual desktop" in configure.ac was
commented out...and I would never intend to use it anyway.
So let's just remove the ~800 lines of #ifdef'ed code to have a
cleaner code base to read when bored.
The raising and lowering of the clip is already taken care of
by the "ClipRaiseLowerKey" shortcut.
wmaker gets a bit smaller for free:
text data bss dec hex filename
449483 17384 8208 475075 73fc3 src/.libs/wmaker.old
449307 17256 8192 474755 73e83 src/.libs/wmaker.new
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 ]
I don't want the (small) overhead of the window birth zoom special effects
because I like apps popping up instantly when I open them (specially now
with the SSD).
Another way to not get the birth animation is to unset "animations" in
WPrefs, but that makes the other animations which I care (ie they don't have
the effect of making my computer seem slower than it really is) go away.
Paul Harris reported that using the mouse wheel over a miniwindow
would deiconify it to a different workspace than the original one
where it was iconified.
This happens because after the window begins to be deiconified the
"residual" mouse wheel scrolling hits the workspace background, and
Window Maker changes workspace with wWorkspaceRelativeChange().
But if it all happens fast enough (so the deiconification animation
did not finish yet) the workspace will have changed before the
window reaches its final deiconified destination, leading to
the situation that Paul described in the link below.
So to avoid this, let's set a 'ignore_wks_change' variable
from wDeiconifyWindow() and make wWorkspaceRelativeChange() respect it.
Original report: http://lists.windowmaker.info/dev/msg00821.html
Since a single default visual ID cannot be used for multiple screens, thus
Window Maker refused to start. There is now a global function for getting the
default visual ID. The command line argument --visual-id can be a comma
separated list of visual IDs for each screen. A default value is only set for
the first screen.
This patch fixes a minor bug in Maximus: the new window size didn't take the
border into account. This bug was particularly visible with the
"do not cover dock" option turned on.
New windows will only get focused if the mouse is on the same screen.
The code doesn't handle multiple heads but since it's just one screen
the function works as usual. Checking the head and assign the focus only
if the window is on the same head might be a good idea. Making the whole
stuff optional might be even better.
This patch fixes a problem with restarting Window Maker in multi-screen
environments. The code for setting the background by calling wmsetbg
changes the environment. In multi-screen setups the DISPLAY variable
becomes :0.0 instead of :0 (for example). The restarted Window Maker
process therefore only manages one screen.
This patch fixes a small problem which only rarely occurs. If a
window is opened only for a very short time and closed right away, in
some circumstances the frame around it stays opened. It looks like
Window Maker doesn't get the destroy message. The XGrabServer call was
commented in the code so I activated it again which seems to prevent this
from happening. I think it actually make sense since the ungrab calls are
used anyway in the following code.
