Previously, WPrefs could only be used to edit the menu specified in
WMRootMenu.
In a recent commit, the ability to specify a menu in proplist format defined
in another file which is referenced by WMRootMenu was added. However, if a
user attempted to edit such a menu in WPrefs, an error dialog appeared.
We add the ability for WPrefs to read such a menu. After the user makes any
changes, the result is stored in WMRootMenu, and *not* the original file.
As pointed by gcc, a few constants which contain sizes for buffers are not
used anywhere in the code. This is probably due to code cleanup, where
these buffers have been removed or where size is automatically calculated
by using 'sizeof' instead to reduce risk of bugs.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
This reduce the risk to miss something in case the array they refer to gets
updated, because with the macro the proper number of element will be
evaluated by the compiler automatically.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
As pointed by Coverity, the PLArray that is created to store the return
value of the function 'processData' can be left allocated if some case
handling decide to return NULL instead.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
The function is a callback, which means having a fixed argument list.
It is then correct to not use all the arguments, so this patch adds the
appropriate stuff to avoid a false report from compiler.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
Signed-off-by: Carlos R. Mafra <crmafra@gmail.com>
The function did not use the argument 'mPtr', so removed it.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
Signed-off-by: Carlos R. Mafra <crmafra@gmail.com>
The functions that create the different configuration panels were taking
the screen structure as argument, but it turns out that none of them
actually need it.
We just remove the argument to make code simpler and easier to maintain.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
The WINGs toolkit dispatch events on widgets using callbacks, which means
having a fixed argument list for the handling function.
It is then correct to not use all the arguments, so this patch adds the
appropriate stuff to avoid a false report from compiler.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
- remove extern declaration in source file, use header instead
- add inclusion of header defining the functions of the file to
get the compiler to cross-check them
- marked static the functions that should not be visible ouside
their file
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.