Porting WINGs widgets to Rust will require using some WINGs abstractions. One of them is the base widget type, which is implemented by giving all widgets a common layout (with the first two fields always being the same basic types).
This is still a mess, but it's not all in one big line now.
Going forward, commits that need new bindgen functions and types should put them on their own lines. That will make it easier to figure out which commit introduced the use of a given symbol.
This should be simple enough not to need further review. It gets rid of a bunch of warnings about struct fields defined with Rust-only types which are not visible from C.
Reviewed-on: vitrine/wmaker#27
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.
