This patch adds the RSaveTitledImage() function to the WRaster lib
to be able to save file on disk either as a PNG or a JPEG file.
Those two formats depends on optional external libs.
The function can take an optional title/comment which will
be save inside the file.
The WRaster lib and header versions are bumped.
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 patch fixes the compiler warning below
menu.c: In function 'restoreMenuRecurs':
menu.c:2450:47: warning: '%s' directive output may be truncated writing up to 510 bytes into a region of size between 509 and 1019 [-Wformat-truncation=]
2450 | snprintf(buffer, sizeof(buffer), "%s\\%s", path, menu->frame->title);
| ^~
The code is taking care of checking properly the string passed to the buffer,
so there is no issue, the change is just to make the compiler happy.
The patch is trying to mitigate and properly address the issue described at
https://github.com/window-maker/wmaker/issues/26
A buggy application (in that example virtualbox) is requesting a window size creation
that is way too big and basically at the limit of X11 protocol
(width and height are defined as CARD16).
See details at https://www.x.org/releases/X11R7.7/doc/xproto/x11protocol.html
During the tests, virtualbox has been seen requesting for window creation of size 843x65508.
Even xprop is reporting incorrect values.
There had been an attempt before with the commit
https://repo.or.cz/wmaker-crm.git?a=commit;h=6668715402a5d8e2ecda6702076a06bf8988721e
But the patch is broken and not implemented at the right place.
As described in the wWindowConfigure function header, the size passed by the client app
should not be trusted and should be vetted with a prior call to wWindowConstrainSize.
wWindowConstrainSize call was missing only once in the wClientConfigure function from client.c
What wWindowConstrainSize doing now is basically setting a failsafe window size fo 640x480
if both width and height are above the size of CARD16.
If only one dimension is oversized, it's setting a default 4/3 window ratio.
Oversized here has not been changed and it's defined in windowmaker as double the screen size.
Window maximize state is not persistent between windowmaker sessions.
This patch is updating the save and restore workspace state functions
to update the state in the WMSTATE file.
If windowmaker was compiled with libXRes,
add XRes info in the "Additional support" section.
Take also the chance to remove the mode +x on the source code file.
For apps which are not setting the window WM_COMMAND property like those old
apps using Motif toolkit (I am thinking of NEdit for example)
it's bringing some issues in windowmaker which is relying on it for a few interactions.
Especially,
*an app without WM_COMMAND will not be saved during the workspace state
(so session restore is not working for them)
*when added to the dock, the settings parameters are empty and need to be filled
*cannot autostart from the dock (even if the settings are manually filled and saved)
*right click on the app titlebar, and choosing Launch has no effect
Most of the time, those apps are also not setting the X11_NET_WM_PID property.
With the pid we could have a chance to find the running program.
To link a window to a pid, there is the X11 Resource extension library (libXRes).
After checking, gnome and xfce are also using the same method to handle such issues.
The patch is checking if the libXRes is present on the system (but it's not mandatory to compile).
Then, it adds a layer on top of wNETWMGetPidForWindow to not only check the window property
but if necessary to get the underlying pid from libXRes if available.
That's solving the points mentioned above.
For apps which are not setting the window WM_COMMAND property like those old
apps using Motif toolkit (I am thinking of NEdit for example)
it's bringing some issues in windowmaker which is relying on it for a few interactions.
Especially,
*an app without WM_COMMAND will not be saved during the workspace state
(so session restore is not working for them)
*when added to the dock, the settings parameters are empty and need to be filled
*cannot autostart from the dock (even if the settings are manually filled and saved)
*right click on the app titlebar, and choosing Launch has no effect
The patch below allows the workspace state to be saved for those apps without WM_COMMAND
that have been launched from the dock. We are just reusing what have been set in the
Application Path Settings of the dock app (and it does not require extra libs like libXRes).
Fix compiler warning:
load_jpeg.c: In function 'RLoadJPEG':
load_jpeg.c:100:17: warning: variable 'image' might be clobbered by 'longjmp' or 'vfork' [-Wclobbered]
As it was not working to only set the RImage *image as volatile,
I had to refactor the code by following the example from
410c028f33 (diff-e7cb632359a2be17c1008b50f9ec85691cd5d66834d5fe8f63ef65ceb06682ee)
The patch is to fix warnings like:
wsmap.c: In function "update_mini_workspace":
wsmap.c:451:55: warning: "%d" directive output may be truncated writing between 1 and 11 bytes into a region of size 10 [-Wformat-truncation=]
451 | snprintf(name, sizeof(name), "%d", general_index);
If you are trying to maximize old apps that are setting a resize increment
in term of WM_NORMAL_HINTS notion the window will not be maximized fully (by a few pixels).
It's easy to reproduce with xterm, ctrl double click on the title bar.
xprop extract sample is giving:
program specified resize increment: 6 by 13
For those maximized windows the patch is just ignoring the resize increment.
Seems the same issue happened on that project
https://github.com/paperwm/PaperWM/issues/106
This patch is fixing compiler warnings like:
load_tiff.c:42:9: warning: 'uint16' is deprecated [-Wdeprecated-declarations]
load_tiff.c:43:9: warning: 'uint32' is deprecated [-Wdeprecated-declarations]
As starting from libtiff 4.3, released in April 2021, types were moved
from uint16 to uint16_t and uint32 to uint32_t respectively.
See https://libtiff.gitlab.io/libtiff/releases/v4.3.0.html
Rely on old utsname and os-release (http://0pointer.de/blog/projects/os-release) when available
to display more underlying OS details in the Info panel.
The idea is when someone creates a bug entry we can request them to copy/paste that screen
to give more info about the context that could help us debug the issue.
For example, on my current system it's displaying:
"Running on: Ubuntu 22.10 (x86_64)"
When debug is enabled, the memory allocated details is supposed to display the free chunks
but as the text length is too long it's getting out of the display area.
This patch is increasing the window width to handle such case.
Replacing mallinfo with mallinfo2.
The fields of the mallinfo structure that is returned by the
older mallinfo() function are typed as int. However, because
some internal bookkeeping values may be of type long, the
reported values may wrap around zero and thus be inaccurate.
Just to please the compiler as it's reporting:
icon.c: In function 'get_icon_cache_path':
icon.c:425:13: warning: unused variable 'len' [-Wunused-variable]
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
