According to the EWMH specs, windows can indicate that they are
non-resizable by setting minheight = maxheight and minwidth = maxwidth
in the ICCCM WM_NORMAL_HINTS property. That should be for example
the case for WPrefs app which is not resizable.
Window Maker currently is overwriting that flag in src/window.c for
apps that are exposing GNUstepHints instead.
This patch is making sure the apps created with WINGs is removing
the WMResizableWindowMask to hide the resizebar.
The compiler is reporting the warning below
wtext.c:171: warning: macro "NOTIFY" is not used [-Wunused-macros]
That macro is only used once within that C file, code which is commented
out already.
XKeycodeToKeysym was deprecated some time ago and we replaced
those function calls to XkbKeycodeToKeysym.
Usage of XkbKeycodeToKeysym is not the best as it appears
the XKEYBOARD can be disabled via xorg.conf (at least on Linux).
So just replacing XKeycodeToKeysym() with XkbKeycodeToKeysym()
could cause run-time errors on top of the compilation warning
we may have.
Better fix is to address the problem without introducing a
dependency on XKEYBOARD. W_KeycodeToKeysym is the equivalent
code for XKeycodeToKeysym/XkbKeycodeToKeysym using
XGetKeyboardMapping instead.
As a new function is added to the library WINGs library version
is bumped.
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
It is resource-consuming to query the server for an Atom, yet the protocol
ensures the values will stay unique, so we'd better ask them once and
retain the values for further use.
Because we have allocated enough space, it is a waste of time to check the
size after copy and cat; beside the use of plain strxxx functions may allow
compiler to make a better job.
The original code was over-complicated, it can be reduced to a one-line
call to a function that does the same thing, with the bonus that it will
behave better in the case where domain == NULL.
The original code refused to create anything not in $WMAKER_USER_ROOT, now
we go one step further and limit creation inside its 'Library' or
'Defaults' sub-directories.
Directory /etc/WindowMaker is for global defaults configuration, it is not
a "data" folder which is $PREFIX/share/WindowMaker.
The name change make it more consistent with other names.
Replace calls to wusergnusteppath() which just append "/Library" by calls
to wuserdatapath().
Take opportunity to replace hardcoded "/WindowMaker" directories with
the existing PACKAGE_TARNAME macro (which comes from autotools).
The choice of 'TARNAME' is because it meant to be used in filename, thus
less likely to have problematic characters than PACKAGE_NAME (meant for
display purpose) and PACKAGE which is there for historical reason.
The man page says environment variables are used, and if they don't exist
it falls back to defaults, yet this was not true in WINGS.
This changes implements the checks for the default paths used when the env
variables are not defined; these default paths have been fixed (+lib) to
match the GNUstep layout ('fhs'), expect for the very last path which keeps
the legacy layout.
For the user Apps folder, rely on wusergnusteppath() (~/GNUstep) to build
the path.
The previous code was only partially functional as the hard-coded paths
did not exist in any of GNUstep standard file system layout and the
GNUSTEP_*_ROOT environment variables were not provided by GNUstep for a
while. This means it would never work no matter how environment variables
were set when using layouts: 'debian', 'fhs', 'next', 'Apple', 'mac',
'fhs-system', or 'standalone'.
Previously, we released the color well's color even if it was the same
as the new color. This eventually resulted in a segfault when calling
WMPaintColorSwatch because we tried calling XFillRectangle with no
display.
We fix this by only releasing/updating the color well's if it differs
from the new color.
It seems there have been changes in the way Pango's header files are
installed in recent versions, probably to allow having multiple versions
together on a system.
Because one public header from WINGs has to include Pango's header, we must
include the search path provided by Pango into our WINGs search path that
are returned by pkg-config (the .pc file).
They are then also added to WindowMaker and WPrefs which use the header but
can't rely on the path from the .pc file which has not been installed yet.
Reported-by: Carlos R. Mafra <crmafra@gmail.com>
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
Make use of the standard macro for PKG_CONFIG; the default behaviour is now
to use Pango if present, instead of requiring explicit user request, yet
still not making it mandatory.
The detection code was moved to a macro to keep the configure.ac script
(relatively) small, and consistent with what is done for most other libs.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
The goal is to use standard macros, which make code easier to maintain
(smaller, more consistent). We still keep the legacy "xfg-config" method
because we don't want to drop support for old hardware/software.
A side effect is the change in the name of the variables for the makefile,
but this goes in favour of consistency.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
The header "wraster.h" needs different behaviour depending on whether the
support for X Shared Memory extension was enabled or not; but the related
macro USE_XSHM is defined by WindowMaker's configure. After this header
have been installed, the macro is no more useable.
This patch makes the "wraster.h" a generated file, so it will be different
depending on USE_XSHM, but will not make use of the macro itself.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
As pointed by Coverity (#50074), despite the expected behaviour that
'wmalloc' should never return NULL, it may still happen if an abort handler
set by user (with wsetabort) does not call exit() as expected. In such
case we make sure the NULL pointer dereference does not happen inside
WINGs code because we assume it is a known user choice.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
As reported by Coverity (CID #50129), in case of error during the write
operation, the failure path does include close of the file handle. In
addition to the resource leak, this may be a problem if the application
were to make a second try on the same file.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
Because of a minor bug, when pure blue was chosen in RGB in the ColorPanel,
the conversion to HSV would mistreat it as white and resets its hue,
leading to possible user annoyance.
The code limits the integer number to 0..359 so we need 4 bytes to store
that, but that require too complex flow processing for compilers to deduce
it.
It does not cost to increase the temporary buffer to the minimum size
requested by GCC, so let's do this, because spurious warnings can
potentially divert us from more important ones.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
The header "WINGsP.h" needs different behaviour depending on whether the
support for Pango was enabled or not. But the related macro USE_PANGO is
defined by WindowMaker's configure, and after this header have been
installed the macro is no more valid.
This patch makes the "WINGsP.h" a generated file, so it will be different
depending on USE_PANGO, but will not make use of the macro itself.
As a side effect of being now generated, the include paths in the makefile
have been updated to include build-dir too, because for users doing an
out-of-tree build the generated file (that is used during compilation) is
placed in the build-dir.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
I noticed one instance of this while looking at the code the other day,
and after a quick grep, realized it happened a *lot*! One of the many
frustrating things about the English language is that we use apostrophes
to make pretty much everything possessive *except* the pronoun "it".
In that case, we use "its". "It's" is reserved for the contraction
meaning "it is" or "it has".
This patch removes the FALLTHRU warnings in wtext.c. Only includes the comments for GCC7.
wtext.c: In function ‘handleActionEvents’:
wtext.c:2508:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
if (event->xbutton.button == Button2) {
^
wtext.c:2547:2: note: here
case ButtonRelease:
^~~~
wtext.c: In function ‘handleTextKeyPress’:
wtext.c:2307:11: warning: this statement may fall through [-Wimplicit-fallthrough=]
*buffer = '\n';
~~~~~~~~^~~~~~
wtext.c:2308:2: note: here
default:
^~~~~~~
Signed-off-by: Rodolfo García Peñas (kix) <kix@kix.es>
This patch removes the format-truncation error. The warning is because c has size of 3, but using "%d" is not possible to store the value.
wruler.c: In function ‘paintRuler.part.0’:
wruler.c:184:28: warning: ‘%d’ directive output may be truncated writing between 1 and 10 bytes into a region of size 3 [-Wformat-truncation=]
snprintf(c, sizeof(c), "%d", ++j);
^~
wruler.c:184:27: note: directive argument in the range [1, 2147483647]
snprintf(c, sizeof(c), "%d", ++j);
^~~~
wruler.c:184:4: note: ‘snprintf’ output between 2 and 11 bytes into a destination of size 3
snprintf(c, sizeof(c), "%d", ++j);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The value "j" is the result of "m < w". w is the result of rPtr->view->size.width - rPtr->margins.left;, and both variables are unsigned int. So the value for w is an unsigned int and m is related to i. m cannot be greater of unsigned int.
i = j = m = 0;
w = rPtr->view->size.width - rPtr->margins.left;
while (m < w) {
XDrawLine(rPtr->view->screen->display, rPtr->drawBuffer,
rPtr->fgGC, rPtr->margins.left + m, 23, rPtr->margins.left + m, marks[i % 8] + 23);
if (i != 0 && i % 8 == 0) {
snprintf(c, sizeof(c), "%hu", ++j);
WMDrawString(rPtr->view->screen, rPtr->drawBuffer, rPtr->fg,
rPtr->font, rPtr->margins.left + 2 + m, 26, c, 2);
}
m = (++i) * 10;
}
The printf modifier should be unsigned int.
Signed-off-by: Rodolfo García Peñas (kix) <kix@kix.es>
This patch removes this warning:
widgets.c: In function `renderPixmap':
widgets.c:385:8: warning: this statement may fall through [-Wimplicit-fallthrough=]
if (mask)
^
widgets.c:388:4: note: here
case '.':
^~~~
Signed-off-by: Rodolfo García Peñas (kix) <kix@kix.es>
This patch removes these warnings in the hsbInit function.
wcolorpanel.c: In function ‘hsbInit’:
wcolorpanel.c:3456:16: warning: ‘%u’ directive writing between 1 and 5 bytes into a region of size 4 [-Wformat-overflow=]
sprintf(tmp, "%d", value[0]);
^~
wcolorpanel.c:3456:15: note: directive argument in the range [0, 65535]
sprintf(tmp, "%d", value[0]);
^~~~
wcolorpanel.c:3456:2: note: ‘sprintf’ output between 2 and 6 bytes into a destination of size 4
sprintf(tmp, "%d", value[0]);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
The problem is that the hue variable in the RHSVColor struct. This variable is not an integer, is a shor variable, so using the printf using the "%d" modifier spects an integer. Using a "%hu" prints a unsigned short value.
typedef struct RHSVColor {
unsigned short hue; /* 0-359 */
unsigned char saturation; /* 0-255 */
unsigned char value; /* 0-255 */
} RHSVColor;
This patch removes this warning. The default case should not be used.
wcolorpanel.c: In function ‘rgbIntToChar’:
wcolorpanel.c:2392:2: warning: ‘format’ may be used uninitialized in this function [-Wmaybe-uninitialized]
sprintf(tmp, format, value[1]);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Rodolfo García Peñas (kix) <kix@kix.es>
This patch removes this warning. The patch adds a switch case that never should happend.
wcolorpanel.c: In function ‘rgbInit’:
wcolorpanel.c:3403:2: warning: ‘format’ may be used uninitialized in this function [-Wmaybe-uninitialized]
sprintf(tmp, format, panel->color.rgb.green);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Rodolfo García Peñas (kix) <kix@kix.es>
This patch removes this warning:
selection.c:265:64: warning: cast between incompatible function types from ‘int (*)(void *)’ to ‘void (*)(void *)’ [-Wcast-function-type]
wdata = WMCreateDataWithBytesNoCopy((void *) data, len * bpi, (WMFreeDataProc *) XFree);
Signed-off-by: Rodolfo García Peñas (kix) <kix@kix.es>
