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
Previously, the transparent frames that were drawn prior to snapping a
window assumed that there was only one head, i.e., that the new
position and dimensions of the window would be based on the dimensions
of the entire screen.
However, this is not the case on multi-head systems, and so we now
base the transparent frame's position and dimensions on the current
head of the window.
We also refactor the code so that the new dimensions are computed in
the switch statement and finish with one final call to
drawTransparentFrame.
Previously, we assumed that it always switched from left to right or
vice versa when calling swapDrawer. However, now we may also call
swapDrawer when changing the value of "KeepDockOnPrimaryHead", which
wouldn't actually switch which side of the screen it's on.
So instead, we determine which side of the screen it should be on
based on the dock.
Previously, we either saved it as 0 or -ICON_SIZE, and then adjusted
it depending on the screen width when restoring the state.
But since the introduction of the "KeepDockOnPrimaryHead" option, the
state-restoring code has changed so that the dock will go on the left if the
x-coordinate of the position in WMState is to the left of the midpoint
of the screen and on the right otherwise. But previously (unless the
user manually set the value in WMState) this would always send the
dock to the left, even if it had been on the right, since the x-coordinate
automatically saved to WMState in this case was negative.
We simplify things by saving the actual x position of the dock to WMState.
Previously, we assumed that if the dock was on the right, then the
menu should be on the far right of the entire screen, but this is no
longer the case with "KeepDockOnPrimaryHead" set to "YES".
We use the new helper function getDockXPosition to determine where
to put the dock. If WMState gives an x-coordinate less than the
center of the screen, we put it on the left, and otherwise we put it
on the right.
We use the new "getDockXPosition" helper function to find the x
position of the main icon, whose position is used in "wDockCreate" to
get the position of the entire dock.
Previously, "KeepDockOnPrimaryHead" was only taken into account
when *moving* the dock and not when creating it.
This implements a feature request [1] to allow the possibility of
keeping the dock on the primary head on a multi-head system.
In particular, if the new KeepDockOnPrimaryHead option is set to YES,
the dock will either be on the left- or right-hand side of the primary
screen. If it is NO, then we get the current behavior, i.e., the dock
will either be on the left-hand side of the leftmost head or the
right-hand side of the rightmost head.
[1] https://github.com/window-maker/wmaker/issues/24Closes: #24
Once implemented, this will keep the dock on the primary head (when
there are multiple heads) when YES. The default value is NO, the
current behavior, i.e., treat all monitors together as one large screen.
bug description: after menu is displayed I get a segfault when trying to hover over the last menu
entry. it looks like under some circumstances menu->entries[] gets accessed past the last valid
value (off by one).
how to reproduce:
right-click desktop to show menu and keep right mouse button pressed
sweep mouse up-down the menu a few times - it crashes all the time between 1-5 sweeps
this commit fixes the unwanted behaviour, in active use since december 2021.
This matches the English manpage and also prevents
wrong-manual-section Lintian warnings in the Debian package, as "Maker"
was being interpreted as the section of these manpages.
Files in /usr/share/xsessions are used by some display managers (e.g.,
LightDM and GDM) to detect available sessions. Such a file has been
shipped in the Debian Window Maker package for years.
