We can reduce the WMNotification API surface area further by getting rid of
WMCreateNotification and WMPostNotification. WMNotification remains a
first-class object, but it is no longer possible for client code to create a
notification object directly. Notifications must now be posted through
WMPostNotificationName, which handles notification creation and destruction on
its own.
This will simplify the notification lifecycle and make the Rust rewrite
simpler. (Notifications no longer need to be reference-counted, heap-allocated
objects that might be saved somewhere after they are dispatched.)
WTextField code which reused the WMNotification struct has been modified to take
parameters of the correct type directly, instead of through a WMNotification's
void* data field.
This reduces the notification API in a way that is helpful for rewriting in
Rust. This function is only used in one place, and the object that is being
deregistered is free'd immediately after WMRemoveNotificationObserverWithName is
called, so it should be safe just to use WMRemoveNotificationObserver (since I
hope it's an error to keep a notification to a free'd object registered).
This appears to have been used by now-defunct support for network
connections (WMConnection). No live code instantiates a notification queue or
pushes/dequeues notifications from a notification queue. (The global
NotificationCenter in WINGs/notification.c is still in use, so it is not going
anywhere in this commit.)
`WMRetainNotification`, `WMGetDefaultNotificationQueue`,
`WMDequeueNotificationMatching`, `WMEnqueueNotification`, and
`WMEnqueueCoalesceNotification`, are only used in WINGs/notification.c. To
reduce the API surface area that needs to be migrated to Rust, they are being
made private.
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*).
This is a bit of a red herring, since WMTree is only used in wmmenugen, which I
don't think I've ever directly used. See notes at the top of tree.rs for more
musings on whether this should be in wutil-rs at all.
WMTreeWalk is only called once, with depthFirst set to true, so we might as well
just hard-code that behavior.
Also, this parameter appears to have been misnamed (since the search is always DFS)
and should properly be named to indicate that it controls if this is a pre- or
post-order traversal.
This is a first step towards migrating WINGs/tree.c to Rust.
Happy finding: no parent pointer are actually needed, so we don't have to use a
shared structure for node pointers!
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.
The WMHashTable rewrite branch was prematurely merged. This patch fixes some of
the things that were overlooked in that merge. WMHashEnumerator should be an
opaque type that is free'd after it is created.
We hope to axe WMHashTable entirely, but it's reasonable to get this fix in for
now so that the WMFontPanel integration test in WINGs/Tests can run on top of
the changes we've made so far. As of this commit, it's still broken, but it
behaves better than it did.
Prior to this patch, when WINGs/Tests/wtest.c tries to build a FontPanel, it
crashes. This is because the rewritten WMSortArray passes pointers to array
items to its comparator function, but the original API passed pointers to
pointers to array items to its comparator function. This has been corrected, and
now WMSortArray should behave more like it originally did.
This patch also stores `usize` addresses instead of `NonNull` pointers because
some WMArray use sites actually store non-pointer data (by casting it to
uintptr_t or similar).
* Select $DISPLAY dynamically because X11 likes :0 and Wayland likes :1 and who
knows what else might like some other value.
* Kill Xephyr after wmaker exits.
* 640x480 should be big enough for anyone. (And the window shouldn't get in the
way so much.)
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.
This type of PropList entry appears to be completely unused, so let's be rid of
it. This can be reversed in the future if we do want more complete support for
property lists, but for now it's code that we don't need.
trurl