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.
This adds an option (IgnoreDecorationChanges in plist) for windows to
ignore any requests from the clients for changing decorations. Since the
default state for any window pre-request is to have all decorations visible
this basically means that applications cannot hide any of the titlebar,
sizing bar, titlebar buttons, etc and any hint that causes these elements
to be hidden will be followed by a restoration if this option is set.
This is useful for broken clients (e.g. Steam) and clients that force
subpar client side decorations. It is basically a per-window setting of the
global advanced option to ignore Gtk hints, except that it also applies to
non-Gtk applications.
This macro is used when handling directories with OPEN_MENU, e.g., to list
available image files for setting the workspace background.
When parsing a menu file, we replace any instances of #usergnusteppath#
with either GNUSTEP_USER_ROOT or ~/GNUstep if the former is not set. In
this way, authors of menu files do not have to worry about whether users
will have this variable set or not.
We also document this feature in WindowMaker/menu.in, which generates the
default English language old-style menu and currently contains the existing
documentation for the Window Maker menu system.
Previously, WMRootMenu could either be a menu file in proplist format
itself, or it could reference another menu file in the old style format.
If WMRootMenu referenced another menu file in proplist format, this file
was parsed assuming it was in the old style format and thus failed, as
observed by Andreas Metzler [1].
In this patch, we first attempt to parse a referenced menu file as if
it were in proplist format. If this fails, then we fall back on the old
style format. This has the disadvantage of spamming the terminal with
various parsing errors if the menu file is in the old style format.
[1] https://www.mail-archive.com/wmaker-dev@lists.windowmaker.org/msg07097.html
The default configuration options are given in two places in the source
code:
- src/default.c
- WindowMaker/Defaults/WindowMaker.in
The defaults are initially set in the former, but are then overwritten by
the latter.
Ideally, the default options in these two locations should coincide.
However, there are currently several issues.
- Many of the options are missing from WindowMaker/Defaults/WindowMaker.in
- Many of the options have conflicting defaults between the two locations.
- A number of options given in WindowMaker/Defaults/WindowMaker.in no longer
exist.
In this patch, we bring the defaults in the two locations in line with one
another. We have given preference to the defaults in W/D/WindowMaker, as
these are the one users have been used to.
Some of the paths in IconPath and PixmapPath have been removed. In
particular, the various system pixmap paths (/usr/include/X11/pixmaps,
/usr/share/pixmaps, and /usr/local/share/pixmaps) have been removed in
favor of PIXMAPDIR, which is specified by the user at build. Also,
/usr/share/icons has been removed from IconPath. The root of this
directory will contain very few icons, as the icons themselves are located
in subdirectories corresponding to XDG icon themes.
We add a comment to src/defaults.c to remind future developers who
add or remove options to change the default values in both locations.
We also take the opportunity to remove the unused DEF_INFO_TEXT_FONT
macro.
Previously, this was only (partially) possible by redefining the macro
GLOBAL_DEFAULTS_SUBDIR. This told Window Maker to look for the global
config files in a particular subdirectory of SYSCONFDIR.
However:
* This is undocumented.
* GLOBAL_DEFAULTS_SUBDIR is ignored when installing the config files. They
are always installed to SYSCONFDIR/WindowMaker.
To solve these issues, we add a "--with-defsdatadir" option to configure
which allows a user to specify the global defaults directory.
While I love the new maximizing functions, in the process of
developing them the code to keep icons from under the dock was lost.
I have created a patch to prevent this problem.
Simplify handleMaximize function for "not effective" case, where there
was couple of duplicate code, now there is one indentation level less
and readability increased.
Mouse pointer can be now moved together with window if keyboard was used
for arrange maximized windows on screen. This feature can be turned on
in WPrefs.app in Expert tab by selecting "Move mouse pointer with half
MAXIMIZED windows.", or setting "PointerWithHalfMaxWindows" to "Yes" on
~/GNUstep/Defaults/WindowMaker file.
Now it is possible for change a bit pattern for changing state between
half-maximized windows. Half maximized windows will become maximized if
there is issued half-maximizing shortcut in opposite direction. Issue
half-maximizing command on same direction on already maximized window,
will have no effect.
Added new option to Window Maker for enabling alternative way for
half-maximized windows movement. Option can be found on Expert section
in WPrefs app.
Previous bugfix introduced another regression. It fixed the issue with
size of the unmaximized window, but break new functionality. Revert back
code for maximizing using mouse, leaving out head detection for keyboard
actions, since it is already calculated.
Mouse actions for maximize also has to be fixed due to different
behaviour in original implementation - movement of the window which is
called in handleMaximize filter out MAX_KEYBOARD from argument passed to
the wMaximizeWindow, so that it will always assume that all the actions
have to be done on the head where mouse pointer resides. For moving
windows between heads feature, calculated head is always passed and
used, regardless of how maximizing was invoked (keyboard or mouse) and
mouse pointer position.
Using MoveHalfMaximizedWindowsBetweenScreens option user can enable
ability for moving half-maximized windows not only within current
screen/head/display, but also to other heads, if they exists. Note, that
only vertically or horizontally maximized windows can be transfered to
another display. Quarter-maximized windows are not supported, since it
is ambiguous to predict in which direction such window should be moved.
