As reported by Coverity (CID #50146), if the function getLocalizedStringValue
returns without matching the entry, the storage for the entry's locale was
leaked.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
The library maintains a cache to not reload a file that was previously
loaded. In order to still reload an image in case its file would have
changed in the meantime, the cache saves the file's modification time.
As reported by Coverity (CID #331576) the 'stat' function was not on the
execution path the first time an image is loaded, which means the cache
information is populated with junk data. This could lead to an image not
being reloaded for example.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
When the function 'pm_getuint' is reading a number, it prints an error
message if it encounters a non-digit number, yet it still enters the
processing loop which will cause an invalid number to be calculated.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
As reported by Coverity (CID #50047, #50048), if the proplist is incorrect
and has an OPEN_MENU or (SH)EXEC command without its arguments, we did
dereference a NULL pointer.
Now we simply return the NULL value, appropriate to have the caller of the
function issue a message.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
As reported by Coverity (CID #331571), we did not check the return value of
the call to XParseColor. If the function is given a colour name that it
does not know, we would return an uninitialised colour.
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>
As reported by Coverity (CID #331553), we leak the allocated string
returned by 'WMGetTextFieldText'
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
As reported by Coverity (CID #331559), the call to 'wfindfile' replaces
the value for variable 'path' but we did not free its previous content.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
The function always returns the filename where the icon have been saved,
but in the case where the save operation failed we would free the memory
for that file name, yet still return this pointer like if it were valid.
Took opportunity to remove redundant free(path) which is done a couple
lines later, because redundancy is a source of problem for code
maintenance.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
As reported in CID #331577, we re-use the variable 'tmp' without freeing
the previously allocated pointer.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
Coverity pointed that the "text" returned by WMGetTextFieldText was never
freed (CID #331578, because WMSetTextFieldText does its own copy, it does
not take the pointer as-is).
By looking at the code, there is also a potential buffer overflow because
the buffer alloc'd for "value" is sized for the exact number of digits
before increase, but the +delta can make the number use more digits so we
may write past the end of original buffer.
We write to a stack-allocated one, so it does not cost anything and does
not participates to memory fragmentation.
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>
Duplicating things makes maintenance error-prone, which is not a good idea.
In case the abort procedure would need an update, it would be easy then
to forget some place, leading to leaks, if not worse.
Beside, goto is not as bad as academics would like people to believe, when
it is used correctly (and this case is one of them).
The name for the label was given an explicit meaning to make code easy to
understand.
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>
This patch makes the three dots in the dock change their size when bigger icon size is used.
The logic here is such that the dots are scaled only when a certain icon size is reached;
for instance, the dots will remain unchanged if icon size is less than 128x128 px, and will
be twice as big if it's set to a value from 128x128 to 184x184 px. The get_dot_mult() func
calculates and returns the scale multiplier. In the draw_dot() func, XDrawLine() and
XDrawPoint() were replaced with XFillRectangle() because those funcs do not allow their
result to be scalable. This patch does not require additional icon size values (those bigger
than 96x96 px) to exist, but makes no use without them.
The classic WindowMaker allows tile icon size up to 96x96 px. This patch rises this value
to 256x256 px. It also sets the max number of visible items in the corresponding pref list
to 29 (instead of 9), so the new values show up in the list. This patch makes it possible
to use dockapps that allow changing their size to bigger than 64x64 px, see
https://gitlab.com/xander1988/dockapps for more info.
Previous patch has correct the way, how reserved area found in
_NET_WM_STRUT was calculated. Unfortunately, the calculation was not
precise, as for not reserved areas (i.e. values of 0 for one of the
cardinals is set) must be calculated anyway for given head, otherwise
usable area might be too broad.
Applications such a panels or docks have ability for reserving space so
that no windows should cover or overlap them. There is (partially)
support for it by checking the _NET_WM_STRUT property, although
calculation for the reserved space was wrong in case of several heads
enabled.
In this patch calculation for reserved area has been corrected.
the function mentioned above caused segfaults on MacOS. The attached patch
seems to solve that.
Details: The functions provides an array of string pointers (the argument
vector) pointing to a buffer allocated and referred to by a static local
variable `args`. This buffer was used on each subsequent call. For one
thing this would overwrite old values and for another this caused segfaults.
My new implementation allocates a buffer for the argument vector plus the
actual string data on each call. The caller will wfree() the buffer, but
until then has available an independent copy of the strings.
Common WindowMaker's rootmenu behavior if press right mouse button open menu and close only with same button.
It's uncomfortably, it patch allows close menu by left or right is clicked outside focus.
Changed func "static WMenu*configureMenu(WScreen *scr, WMPropList *definition)" to non-static forglobal use.
Added new OPTION_WMAKER for this Expert-option. Changed event.c: for correct work should use initialization
func configureMenu afterwMenuDestroy (this is a feature of the event implementation XEvent).
The 'pot' files are templates generated when we want to update the 'po'
files against latest source code;
the 'mo' files are compiled 'po' files to be installed
In this patch we will fix an issue during compilation on systems, which
have ImageMagick version 7, and slightly more recent version of
compiler. If we define USE_MAGICK with null value, compilation will fail
on preprocessor check on such defined variable.
It's USE_MAGICK, not USE_MAGIC. Also, we wrap the if/else statement
in an ifdef. This doesn't really affect anything since load_magick.c
won't be compiled if USE_MAGICK is undefined because of an if statement
in the Makefile. But in the off chance that it is somehow, then we will
try to load a nonexistent version 6 header file since USE_MAGICK will
be interprested as 0 and 0 < 7 is true.
Unescaped curly braces have been deprecated since Perl 5.26 and are
illegal in Perl 5.30. I copied the relevant lines from the latest kernel
source, so we'll inherit a couple other improvements as well.
The abs() function should take an int as argument, but there were
several instances in the code where it was taking an unsigned int or a
double. In these case, we took one of the following approaches:
* If the argument was a double, use fabs() instead.
* If the argument was unsigned and was certainly going to be positive
(i.e,. no subtraction), then drop abs() altogether.
* If the argument was unsigned as result of adding or subtracting signed
and unsigned ints, then we cast all the unsigned ints to signed ints.
We dropped ImageMagick 6 support in 0.95.9. However, ImageMagick 6 is
still widespread (e.g., ImageMagick 7 has not been packaged in Debian
yet), and upstream plans on maintaining it until at least 2028 [1].
In this patch, we detect the version of the MagickWand library installed
on the user's system and include the appropriate header file when
building wrlib.
Note: I've only tested this with ImageMagick 6, so I'd appreciate
confirmation that it works with ImageMagick 7.
[1] https://github.com/ImageMagick/ImageMagick6/blob/master/NEWS.txt
We use the AC_PATH_XTRA macro to find all the X library paths during
build, but we weren't actually using the variables it generated for
building wmlib. Instead, we just hardcoded the linker flag "-lX11",
which may or may not actually work.
As the literal string "wm_cv_xext_xmu" will never be equal to "xno",
we always ran the code that was supposed to run when the variable
$wm_cv_xext_xmu was not equal to "no". In particular, if libXmu
was not found, then we proceeded as if it had been found.
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 changes the behavior of the --with-{inc,lib}s-from arguments
to replace the default paths instead of adding to them. This is
required when cross-compiling in a sysroot, since the default paths
will include files from the host system which can have an
incompatible architecture.
The original ergonomic.tiff file samples/pixel property was wrong which was generating the warning message from libtiff
"TIFFReadDirectory: Warning, Sum of Photometric type-related color channels and ExtraSamples doesn't match SamplesPerPixel. Defining non-color channels as ExtraSamples.."
