The number of calls to WMRetainColor for a color in use should the same as the number of calls to WMReleaseColor
to free that color. In case of discrepancy, random crashes can happen and memory is not freed properly.
To debug that issue I checked the retained colors when the switchpanel is opened and then checked if those colors are properly released once the panel is closed.
This patch fixes the issue mentioned at https://github.com/window-maker/wmaker/issues/22
In case the color cannot be allocated exactly by createRGBAColor function,
the findCloseColor function is used as a failover function to find a color close to the requested color.
By definition that color is then not exact.
createRGBAColor exact flag should be 1 while findCloseColor exact flag should be 0
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 :-)
are affected. Fixes for old code too.
- Double buffering in WMList. All widgets or apps using WMList and
having user drawing porcedures in place will inherit this double
buffering automatically too.
- New functions in WINGs: WMGetColorAlpha(), WMIsAAFont()
- Misc code cleanups in WINGs and src/dialog.c
WMDrawString() and WMDrawImageString() now take WMColor instead of GC as
arguments. WMDrawImageString() receives 2 colors (text & background).
This is to allow easy extension for Xft/Xrender and hide X low level details
- Added alpha channel to WMColor. 2 new functions also:
WMCreateRGBAColor() and WMSetColorAlpha()
- Miscelaneous code cleanups in wtext.c
- Removed obsoleted acconfig.h and implemented its functionality using
AC_DEFINE and AC_DEFINE_UNQUOTED as autoconf 2.5x recommends.
This will definitely enforce the need to use autoconf 2.5x
