From 35f19d77874d1b50de5505b6b1cb31531e1c055a Mon Sep 17 00:00:00 2001
From: Andreas Bierfert <andreas.bierfert@lowlatency.de>
Date: Thu, 31 Jan 2013 22:35:42 +0100
Subject: [PATCH 3/3] Teach WPrefs about OPEN_PLMENU
Add option to WPrefs to read, add and edit OPEN_PLMENU menu entries
memset is the last function call in wmalloc, just before it returns the
newly allocated memory. Therefore it is not needed to call it again
after wmalloc call. Although I would prefer to switch wmalloc to a
calloc-based wcalloc function, the compatibility of WINGs for old apps
should be kept.
The function captureShortcut() is implemented in both files KeyboardShortcuts.c
and Menu.c, with just a minor difference regarding the conversion to upper case.
To unify them, define a new function which includes a new boolean paramenter to
dictate whether the upper case conversion should be done or not.
If you delete the file ~GNUStep/Defaults/WMRootMenu and run WMPrefs
and go to the Menu Edit tab, it will show a dialog about keeping the menu or
discarding it. If you discard it then WPrefs shows an error:
"Could not open default menu from
'/home/user/GNUStep/Library/WindowMaker/plmenu"
The problem is at WPrefs.app/Menu.c:1424, and it happens because it tries
to load the default menu from the user's GNUstep home, but plmenu is not
copied there during the installation.
Of course, the file doesn't need to be copied to the users home, so
WPrefs should try to read it from /usr/share/WindowMaker/plmenu (Debian)
or /usr/local/share/WindowMaker/plmenu (upstream).
* Remove assigned but not used variables (GCC 4.6)
* Bump _XOPEN_SOURCE to 600, ridding of FreeBSD warnings (this probably need
to be tweaked on a per-implementation basis as problems arise)
Prevent WPrefs (menu panel) segfaulting upon coming by an invalid command in
the root menu.
Reported and first patch version by Bento Loewenstein.
Signed-off-by: Tamas TEVESZ <ice@extreme.hu>
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*.
After the fix to avoid a memory leak in wtokenfree(), WPrefs crashes
when opening the 'Applications Menu Definition' dialogue.
The problem is that WPrefs code relied on the fact that the first token
in the array would not be free'd by wtokenfree(), a misbehaviour which
is correctly addressed with this patch.
Retrieved-from: http://www.mail-archive.com/ports@openbsd.org/msg12731.html
[crmafra: small changes in the commit log from the webpage]
for arq in `git ls-files *.c`; do
echo $arq;
indent -linux -l115 $arq;
done
The different line break at 115 columns is because
I use a widescreen monitor :-)
- fixed a bug and memleak in WMBox code.
- updated some translations
- fixed some bug in the menu code about drawing disabled entries.
- fixed Clip menu not to allow selecting of "Autoraise" if "Keep On Top"
is active.
- Added a "Browse" button to the menu editor in WPrefs where a program to run
is specified (not finished).
- Separated the font caches for normal fonts and fontsets in WINGs (they can
have the same names and collide in the cache giving unwanted results)
- Updated the years in the copyright notices
- Also tested the backward compatibility ability of the WINGs proplist code
which seems to work quite well.
Starting with this moment, Window Maker no longer needs libPropList and is
now using the better and much more robust proplist code from WINGs. Also the
WINGs based proplist code is actively maintained while the old libPropList
code is practically dead and flawed by the fact that it borrowed concepts
from the UserDefaults which conflicted with the retain/release mechanism,
making some problems that libPropList had, practically unsolvable without a
complete redesign (which can be found in the more robust WINGs code).
easier to work with it this way.
- better naming of options in the clip options menu.
- better detection of whether to use EXEC or SHEXEC in WPrefs menu editor.
be sure to replace wstrappend() with wstrconcat() anywhere in your code
because a new wstrappend() function will be implemented that will have
different semantics and if your code will use the new one instead of
the old will break.
