This function requires tracking an explict client data pointer, which it would be preferable not to have in the Rust rewrite.
Removing this function entails tracking timer handlers explicitly, but this is not an undue burden.
This starts to establish the structure for an in-place rewrite of WINGs. An
actual redesign of WINGs may follow, but for now there are no plans to alter the
structure of WINGs substantially.
We should eventually get rid of this entirely, in favor of something along the
lines of a sorted Vec that is fully typed (so the payload isn't just a void*).
These functions were added to glibc 2.38, so we don't even need to check for
libbsd. There isn't a strong need to worry about supporting older systems
because use of these functions should go away as we rewrite string.c in
Rust. And, apparently, they are not held in high regard historically. That's at
least 2 reasons to be rid of them.
This fixes a lot of memory bugs which arose as a result of doing something
different from the system malloc/free when allocators were rewritten in Rust.
These changes originate from a different approach to writing the allocator in
Rust:
https://git.sdf.org/vitrine/wmaker/pulls/1/files#diff-04a0fd2319b9969373b75377716e45c836d22869
There are other function calls (to XFree) that need to be fixed, but that can be
done in another commit. This one is already getting large.
This tweaks the hashtable API, and it is incomplete because the WUtil proplist
impl depends heavily on a feature of the old API that is being discontinued.
Moving the proplist code into Rust is our next objective.
While this large change has some unit tests, it has not been integration tested
thoroughly. Removing the global case insensitivity flag may be an issue in
particular.
A few of PropList API functions have been modified (mostly to get rid of
varargs). The definition of one such function has been left in C for cleanup
later.
This is another utility that should not be used in any new (Rust) code. (We
should prefer Vec or something similar.) This should be removed once dependents
are ported to Rust.
Now ./configure checks for cargo and rustc, and `make` will rebuild wmaker-rs if
any of its source code has changed.
There are still some steps to take for better integration (like ensuring that
deps are vendored correctly). See
https://viruta.org/librsvgs-build-infrastructure-autotools-and-rust.html for
suggestions on what else to do.
Just a cosmetic change as the variable is currently not in use.
According to the Motif Toolkit API and MwmUtil.h, the last long
variable from the Motif WM Hints struct is currenlty used
for the status.
This patch adds a new Central feature under the window menu
"Other maximization" entry.
Shortcut can be configured via WPrefs "Center active window" action.
When called the active window is centered on the screen head.
If the window height or width are bigger than the head size,
the window is resized to fit.
There are some transitions defined as below:
*from fullscreen to center
*from any corner to center
*from top half to center top half
*from bottom half to center bottom half
*from left half to center left half
*from right half to center right half
Undoing the action is done via the window menu "Unmaximize" entry
or the shortcut.
Add mouse pointer position detection to trigger the corner actions.
Screen corners can be assigned an external command to be
executed when the mouse pointer is entering those areas.
In WPrefs, "Hot Corner Shortcut Preferences" can be used
for configuration or by manually adding a "HotCorners" key
and value to "YES" in the ~/GNUstep/Defaults/WindowMaker file.
Actions are specified by the "HotCornerActions" and are defined
as a four entries list ("top left action", "top right action",
"bottom left action", "bottom right action").
A screen corner area is a cube shape defined by the "HotCornerEdge"
which is a number of pixels from 2 (by default) to 10.
To lower the risk of triggering that feature accidentally a
"HotCornerDelay" key can be used which is the time before the action
is triggered while the pointer is in one of the screen corner.
Default value is 250 ms.
Hot Corners feature is disabled by default.
As discussed on the ML, the test to check for CARD16 limit is probably innacurate.
Check instead for maxH and maxW which are set by default to twice the size
of the screen or to the max values passed by the window normal hints property.
According to ICCM specs at [1]
*Not changing the size, location, border width, or stacking order of the window at all.
A client will receive a synthetic ConfigureNotify event that describes the (unchanged)
geometry of the window. The (x,y) coordinates will be in the root coordinate system,
adjusted for the border width the client requested, irrespective of any reparenting
that has taken place. The border_width will be the border width the client requested.
The client will not receive a real ConfigureNotify event because no change has actually
taken place.
*Moving or restacking the window without resizing it or changing its border width.
A client will receive a synthetic ConfigureNotify event following the change that
describes the new geometry of the window. The event's (x,y) coordinates will be in
the root coordinate system adjusted for the border width the client requested.
The border_width will be the border width the client requested. The client may not
receive a real ConfigureNotify event that describes this change because the window
manager may have reparented the top-level window. If the client does receive a
real event, the synthetic event will follow the real one.
*Resizing the window or changing its border width
(regardless of whether the window was also moved or restacked).
A client that has selected for StructureNotify events will receive a real
ConfigureNotify event.
Note that the coordinates in this event are relative to the parent,
which may not be the root if the window has been reparented. The coordinates will
reflect the actual border width of the window (which the window manager may have
changed). The TranslateCoordinates request can be used to convert the coordinates
if required.
In Window Maker, the first case is not implemented: doing a synthetic ConfigureNotify
to notify no changes were done. That's creating some issues with app like Citrix icaclient
when sometime windows are blank and need to be moved to be refreshed.
[1]https://x.org/releases/X11R7.6/doc/xorg-docs/specs/ICCCM/icccm.html#configuring_the_window
Align the old maximization descriptions to the new visual indicator
names. The internal shortcut names had also been updated, meaning a
reconfiguration of the shortcuts in WPrefs is required.
Since 48d4820dee the dock is positioned
dynamically based on the screen midpoint.
The side issue using such method is if in case the screen was temporarily
resized the dock as a chance to be displayed on the other side making
the drawer saved configuration from WMState esp the direction wrong when
wm is started again.
For example, the dock and drawer are displayed on the right of the screen.
Then the screen resolution is downsized temporaily to half or less of
the previous size. The position stored in WMState will be updated and the
direction of the drawer is still opening on the left.
But on next wm start, when reading the conf.
The position of the dock and drawer are corresponding to the
middle or less of the unresized screen. The dock and drawer will be sticked
on the left. But the drawer direction was not updated and still opening
on the left (which is out of the screen).
Several variable declarations were recently added immediately after
labels, but this causes compile errors in GCC versions prior to 11,
e.g.,
wsmap.c: In function ‘handle_event’:
wsmap.c:534:4: error: a label can only be part of a statement and a declaration is not a statement
534 | WMScreen *wmscr = wsmap->scr->wmscreen;
| ^~~~~~~~
We move these declarations to the top of the corresponding switch
statements so that Window Maker can compile on these older versions of
GCC.
When that option is on, swapping drawer does not always mean
swapping drawer direction. For example if drawer is on the left
side of the second head and moving to the left side of the first head,
the direction should be the same.
Commit 6e2075f3df from 2020 added
a feature to maximize window when double clicking on the titlebar.
But unmaximizing is not supported so when double clicking again
on the window titlebar the window geometry was not reverted back.
trurl
Dan Cross
David MaciejakandCarlos R. Mafra
Doug TorranceandCarlos R. Mafra