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>
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.
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 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.
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".
With the changes to the layout, which were introduced in the
previous patch series, and the correction of the default font
size, the Legal Information panel was too small to display the
complete text.
It has been set to a sufficient size.
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
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 info panel now scales its widgets based on the
selected system font size.
Instead of relying on static pixel values for position and size of
the widgets, the legal panel now scales its widgets based on the
selected system font size.
Instead of relying on static pixel values for position and size of
the widgets, the icon chooser panel now scales its widgets based
on the selected system font size.
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));
Instead of relying on static pixel values for position and size of
the widgets, the DockAppSettingsPanel now scales its widgets based
on the selected system font size.
This kind of things participates in memory fragmentation, so it is
generally a bad practice when an on-stack allocation is enough.
Took opportunity to reduce the buffer size, there's no point in
overallocating memory (the new size being still way too much).
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
If the option "Enforce icon margin" is selected, application window
icons will be selected or scaled so that they only use 75% of the
available icon_size.
Even if the feature is not enabled, this change will scale down
large application icons to icon_size, so that icons can be used
that were rejected by the previous implementation of findBestIcon.
(Example: The Qt Creator icon never showed before, because it is
only provided in 128x128 resolution. Now it's visible.)
The current findBestIcon function usually selects an icon image
that almost completely fills up the (default) 64x64 pixels of an
icon. As Dan noted in the function, the icon images should use only
75% of the available space, which would result in room for the
miniwindow title and better overall aesthetics.
This feature option provides for enabling such an automatic "icon
shrinking" functionality.
Note: This commit only introduces the new option, not the actual
image shrinking.
When opening the "Icon and Initial Workspace" panel of the Attribute
Inspector, the Miniwindow Image and the corresponding text field were
always empty, even if an icon had been selected, applied and saved
before. The file name was not loaded from the database on startup
of the inspector window.
With this change, the icon and the text field are properly set on
startup of the inspector window.
Window Maker allows to perform practically all operations with windows
using only keyboard. One of the actions so far which required using
mouse was dragging window from one head (monitor) to another.
This patch introduces support for keyboard shortcuts. These shortcuts
move windows in circular fashion (if you have 3 and more monitors).
In case of 2 or 3 monitors arranged horizontally - window will just move
right/left.
In case of 3x3 setup - it is impossible to move window to central
monitor with keyboard.
- preserves window position and size (if display sizes are same)
- otherwise tries to fit window to smaller display
The problem - when VirtualBox starts virtual machine, window has very
small height (couple of pixels) and it requires some manual fiddling
to resize it to something usable.
See related bugs here:
https://www.virtualbox.org/ticket/14718#comment:19 - small horizontal
line in the middle of the screen is newly opened virtual machine's
window.
https://www.virtualbox.org/ticket/15863
Inspecting with xdebug and xprop reveals that VirtualBox sends wrong hints:
Request(12): ConfigureWindow window=0x0660000a values={x=27 y=559
width=720 height=65512}
Which is interpreted by X server wrongly and shown with xprop as
WM_NORMAL_HINTS(WM_SIZE_HINTS)
:
user specified location: 27, 559
user specified size: 720 by -24
program specified minimum size: 254 by 109
window gravity: Static
Some part of X11 interprets such large value as signed int and wraps
it to negative value.
The solution will be if program requests such big window - detect it,
ignore requested size and resize it to some reasonable defaults.
Disclaimer - I tested it only on Ubuntu 16.04, but should apply to
another systems as well - see bug reports.
Fixes the bug where if the icon image is accidentally set to
nothing or the image file is deleted, the appicon keeps losing
its icon (it resets to the default cube icon) when Window Maker
exits/restarts (depending on how the user cleared the icon this
may persist even after redocking the application if information
about the application window is still in the WM). One way to
easily see this bug is to open the main window's attributes and
press the Save button (no need to do anything else) as this
clears the icon file (this is a separate bug that needs to be
fixed but it is more of a minor UI bug since clearing the image
should simply reset the icon to the application provided one if
the Ignore client supplied icon is not set). Another way to
see it is to open the properties box in a docked application
that is not running and clear the image field. After either of
these two actions are performed, restart Window Maker and see
that the icons are missing.
This patch fixes the above bug by calling save_appicon when the
appicon object is created and the application provided icon is
already available (window maker actually tries to save the icon
at an earlier stage but this is done as a side effect of
"painting" the dock icon - which also saves the icon - but this
is done too early, before ownership information is available).
Note that this bug seems to be a regression introduced from
commit 9c4b19d8aa (or one of the
related commits around the same time, they seem to be a bit too
aggressive in not saving icons). This patch addresses the
concern in that commit about only saving the icon for docked
applications.
