These are put in their own crate so that we can link tests against libwings freely.
Once libwings is entirely rewritten in Rust, we should be able to move these tests back into the wings-rs crate.
The global `NotificationCenter` is kept behind a mutex, which was locked when notifications were dispatched.
As a result, if notification dispatch triggered dispatch of other notifications, we would fail to unlock the mutex and panic.
This change copies dispatch instructions out from inside the mutex, releases the mutex, and then actually does the dispatch.
Input handlers date back to early versions of WINGs. They provide
a way to listen for state changes on file descriptors (including
networking sockets) as part of the WINGs event loop.
This functionality is not actually used in the Window Maker source
tree. It may have been more useful in the past, when WINGs provided
a networking socket API. The status quo appears to be that this is
largely dead code. Pumping the X11 event queue is special-cased in
the input handling code, so it can stay in for now.
This is an intermediate step in the process of dropping input FD
polling entirely (except for pumping the X11 event queue).
There is code to use poll(2) instead of select(2) to wait for events
on file descriptors (which includes waiting for events from the X11
event queue). It appears not to have been used in quite some time,
or perhaps never, as it contains a typo (`poll fd` instead of `pollfd`
on its first line).
To reduce code bloat and make source code easier to navigate, it
makes sense to prefer only one of these codepaths.
After correcting this typo, waiting for X11 events appears to work, so
the poll(2)-based code seems to be good enough. Keeping the poll-based
code is vaguely preferable because poll(2) has a slightly better
interface than select(2), and poll(2) has been a standard Unix API
for 30 years.
Since this code is slated to be replaced, the decision to use the
poll(2)-based code here is probably not very important. But future
programmers may want to use this as a branching-off point for switching
to epoll(7) or some other, less-select(2)-like interface.
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.
Having wings-rs depend on WINGs/WINGs/WINGsP.h was not working very well if all
of WINGs/ had to be built before wings-rs/. Moving wings-rs/ into WINGs/
addresses this.
We will use these to port W_Font, W_Screen, etc., to Rust.
Bindings are regenerated whenever the relevant C source files change and then
patched to make sure they will build. This is a bit hacky but will serve our
purposes: the struct definitions should be migrated to Rust sooner rather than
later, so the hackishness should be transient.
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!
trurl