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).
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
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
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.
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.
The FreeDesktop XDG standard suggests storing history in the directory
pointed by $XDG_STATE_HOME; so if we find it is defined we prefer to use
it over the default path. If undefined, keep the old behaviour.
This may introduce a loss of history for users that had some in the legacy
place but have the variable, we consider this very unlikely to be a problem
but if user complains we can suggest them to move the legacy file over the
empty new one.
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.
As reported by clang, (!wPreferences.new_style == TS_NEW) inverts the
"wPreferences.new_style" and not the whole expression. Use the appropriate
comparison operator to avoid misunderstanding.
Instead of constructing path to user's defaults directory with hard-coded
names, just query wdefaultspathfordomain with a blank domain: this returns
the equivalent of "~/GNUstep/Defaults/", yet avoiding problems related to
duplicating strings.
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>
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>
When creating the list of possible shortcut for windows to populate the
window menu, a temporary buffer was allocated to hold that string.
As this allocation participates to memory fragmentation, this patch makes
use of storage on the stack instead which is also faster.
Took opportunity to include the shortcut number (%i) in the string to be
translated, because it is unlikely that adding that number at the end of
the string is right in all languages. Updated french translation because
it is the only one I am confident with.
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>
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>
