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>
The names of the macros and the local variables that they use
have been changed to make them less "user-space" like.
ScaleX -> WMScaleX
ScaleY -> WMScaleY
fw -> wmScaleWidth
fh -> wmScaleHeight
The scale factors in the macros were based on the assumption that
the default font size was 11. But the actual default font size is
12. This value is specified as DEFAULT_FONT_SIZE in
WINGS/configuration.c.
Instead of just assuming that the size of the system font has not
been changed by the user, the WMCreateAlertPanel,
WMCreateInputPanel and WMCreateGenericPanel functions now use a
fixed default font size of 12, so that changing the system font's
size in WPrefs.app does not break the fixed layouts of these panels.
("12" is specified as DEFAULT_FONT_SIZE in WINGS/configuration.c)
To prevent breaking applications depending on the static layout
behavior of the WMCreateAlertPanel and WMCreateInputPanel functions
in WINGs, the scaling functionality has been moved to the new
functions WMCreateScaledAlertPanel and WMCreateScaledInputPanel.
The system dialogs (wMessageDialog, wExitDialog, etc.) now use the
new functions, thus keeping the improved layout introduced in the
previous patches.
Instead of relying on static pixel values for position and size of
the widgets, the input panels now scale their widgets based on the
selected system font size.
Instead of relying on static pixel values for position and size of
the widgets, the alert panels now scale their widgets based on the
selected system font size.
To reduce code duplication the ScaleX and ScaleY macros have been
moved to WUtil.h. Along with the function WMGetScaleBaseFromSystemFont
these macros can be used in all panels to scale the widgets based on
the current system font size instead of giving fixed pixel sizes which
messes up the panels if a larger system font is selected in WPrefs.
Use the macros in the following way:
instead of WMResizeWidget(widget, 128, 64);
WMMoveWidget(widget, 32, 32);
use int fw, fh;
WMGetScaleBaseFromSystemFont(scr->wmscreen, &fw, &fh);
WMResizeWidget(widget, ScaleX(128), ScaleY(64));
WMMoveWidget(widget, ScaleX(32), ScaleY(32));
It looks like the original code was expecting the side effect of specifying
a length in the %d to smartly truncate the number, which it does not.
The new code has the same behaviour without extra complexity.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
As reported in Debian bug #922284 [1]:
As evident from the prefix, GNUSTEP_USER_ROOT is a GNUstep variable and
Window Maker should not set it. Furthemore, it has been deprecated for
12 years already. As of gnustep-make/2.7.0-4 the GNUstep build system
is configured in strict v2 mode which makes it impossible to compile
GNUstep software. In a terminal started from a Window Maker session:
yavor@aneto:/tmp/gorm.app-1.2.24$ make
This is gnustep-make 2.7.0. Type 'make print-gnustep-make-help' for help.
Running in gnustep-make version 2 strict mode.
rm -f InterfaceBuilder; \
ln -s GormLib InterfaceBuilder
/usr/share/GNUstep/Makefiles/config-noarch.make:121: *** GNUSTEP_USER_ROOT
is obsolete. Stop.
It is also impossible to build gnustep-make from pristine upstream
source:
yavor@aneto:/tmp$ wget -q
ftp://ftp.gnustep.org/pub/gnustep/core/gnustep-make-2.7.0.tar.gz
yavor@aneto:/tmp$ tar xzf gnustep-make-2.7.0.tar.gz
yavor@aneto:/tmp$ cd gnustep-make-2.7.0/
yavor@aneto:/tmp/gnustep-make-2.7.0$ ./configure
...
yavor@aneto:/tmp/gnustep-make-2.7.0$ make
config-noarch.make:121: *** GNUSTEP_USER_ROOT is obsolete. Stop.
Note that the majority of GNUstep users use Window Maker as their window
manager and many of them build GNUstep software from source, mostly
because of the GNUstep Objective-C runtime which depends on Clang
(Debian packages use GCC and the GCC/GNU runtime).
Our solution is to replace the GNUSTEP_USER_ROOT environment variable with our
own environment variable, WMAKER_USER_ROOT. This is documented in NEWS.
[1] https://bugs.debian.org/922284
Previously, calls to WMIsPLString, WMIsPLData, WMIsPLArray, and
WMIsPLDictionary would result in a segfault if the argument was null.
This could happen, e.g., if we are checking which type of proplist
was just parsed from a file, but the parsing failed.
These functions now return False in this case.
Previously, when WMSetWidgetBackgroundPixmap() was called prior to
WMRealizeWidget(), no background pixmap was actually set.
This is because while the CWBackPixmap bit is correctly set to 1, the
CWBackPixel bit remains set to 1. When XCreateWindow() is finally
called during realization, the background pixel takes precendence over the
background pixmap.
We fix this by setting CWBackPixel to 0 when setting CWBackPixmap to 1 and
vice versa.
Previously, this was only (partially) possible by redefining the macro
GLOBAL_DEFAULTS_SUBDIR. This told Window Maker to look for the global
config files in a particular subdirectory of SYSCONFDIR.
However:
* This is undocumented.
* GLOBAL_DEFAULTS_SUBDIR is ignored when installing the config files. They
are always installed to SYSCONFDIR/WindowMaker.
To solve these issues, we add a "--with-defsdatadir" option to configure
which allows a user to specify the global defaults directory.
The original code assumed that the (void *) type could be safely converted
to an integer for the printf use, but it is not that simple, as pointed by
gcc when compiling on 32-bits platforms, where pointers do not match
anymore the long (%li) size.
The new code now do the conversions by the rules, so the compiler knows
what is happening and printf always gets the 'int' it expects.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
When the result of the operation is expected to use double precision, this
patchs adds an explicit conversion to that type to tell the compiler that
this is what we want, and not an unexpected side effect.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
To preserve the accuracy of the operation, the C standard request that the
mathematical operation is performed using double precision, but in many
case this is not necessary so this patch fixes a few constants to avoid
that conversion.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
There are some times when we need a Switch Button (aka CheckBox) with more
than 2 states, generally to express check/uncheck/leave-as-is.
This patch extends the Button widget to support the new WBTTriState type,
similar to the existing WBTSwitch except it supports a 3rd state which is
reported to application as '-1'.
The implementation was done in order to not break the binary API. The
version have been incremented in the WINGs header to reflect the change,
but not the version in the 'configure.ac' because that have already been
done in commit c6e323e75d for the next Window Maker release.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
