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.
* 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.
All memory allocations passed back from FFI functions should be allocated with
`memory::alloc_bytes`, so that C code can call `memory::free_bytes` when it's
done with them.
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 symbol's value must be known to port `wmkdirhier` and `wrmdirhier` from
`proplist.c` to Rust.
This change introduces a basic C library under wutil-rs that is linked into the
Rust code to expose preprocessor symbols and other Autotools configuration
decisions to Rust. See the rust rewrite notes at the top of
`wutil-rs/src/defines.rs` for further thoughts.
This is not tested super well, but I hope we can be rid of it soon enough. (Once
we have WMPropList migrated, WMData and other WINGs data structures should be
easier to prune.)
This constructor was only needed in one particular place. We can duplidate the
data instead of borrowing it. This ensures that WMData always owns its data
segment, which simplifies porting to Rust significantly.
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.
This is not a bug-for-bug reimplementation, and it may need some shaking down to
ensure that everything still works. Once their dependents are ported, it would
be appropriate to dispose of them.
This is necessary because we now allocate memory through a special allocator of
our own on the Rust side. Passing raw malloc'd pointers to wfree will break
things.
This is done to simplify memory management across the boundary between C and
Rust. While rewriting WINGs, we may want to be able to malloc/free with the libc
allocator on both sides of that divide.
trurl
Dan Cross