Contributions are very welcome! Even if just for submitting bug fixes, improving the documentation, adding tests and/or examples.
The wrapper itself now lives in the cfltk repo and the stable branch is used as a git submodule in the fltk-sys directory, it uses C89 for the headers (in the cfltk/include directory) and C++11 for the source files (in the cfltk/src directory). Bindgen is used on the header files using the bind.sh script. It's not added as dependency to this project since it depends on libclang and llvm which has some build issues on windows last time I tried it and is relatively large. C89 was chosen for the headers since bindgen works best with them. It's possible to contribute by directly modifying the .rs files in the fltk-sys directory. Or just running the bind.sh line corresponding the header unit being modified. For the C/C++ code, the supplied clang-format formatting is used. FLTK's source code lives within cfltk/fltk. The intention of the wrapper is to only expose the non-deprecated gui parts of the public api which lives in the fltk/FL directory. The reasoning is that the non-gui parts can be replaced by crates from the Rust ecosystem, and the deprecated parts aren't really needed since no Rust software depends on them.
FLTK itself is quite conservative when using features, it does so to get the high portability its known for. As such, similarly the Rust code shouldn't use nightly or unstable features. The current MSRV (Minimum Supported Rust Version) is 1.39 (bound to change when necessary). Avoid pulling other dependencies except when necessary. The dependencies themselves need the same MSRV or lower and be crossplatform, or guarded behind conditional compilation config. Doc comments would also be appreciated, the rustc warning for missing_docs is enabled by default. rustfmt is used for formatting. Pull requests automatically go to the github workflow in which the crate is built on the major desktop platforms, along with all the examples. The bindings live in the fltk and fltk-derive directories. The fltk-derive provides derive macros which are intended to be internal to the fltk project. FLTK depends on inheritance to represent relationships between widgets, and these are easier done with derive macros in Rust, thus it's used to implement all widget trait methods. They also reduce repetition in code. The fltk directory contains a prelude which has all the traits exposed by the crate, as well as the error types. Widgets are grouped by their inheritance relations, the outliers being the utils (for utility functions) and misc modules. The misc module contain widgets which are either composite (containing multiple) widgets or widgets directly inheriting from Fl_Widget.
Each example should be in a single file, with no dependencies to other than this crate. This allows each example to be standalone. If you would like to contribute more complex examples, I invite you to contribute them to the fltk-rs-demos repo.
Please open an issue or a discussion for such changes before going ahead and doing them. It allows for discussion regarding the proposed changes. This crate tries to stay as close as possible to the FLTK api, which offers familiarity to people having used FLTK, and allows easier referral to the official documentation.
Given the above info, a normal workflow to add a method to a certain button widget would entail adding the method wrapper to the corresponding header file cfl_button.h and an implementation in the cpp file cfl_button.cpp (both in fltk-rs/fltk-sys/cfltk). Running $ ./fltk-sys/bind.sh or just the corresponding to the header file $ bindgen --use-core --ctypes-prefix libc fltk-sys/cfltk/include/cfl_button.h -o fltk-sys/src/button.rs. If the method is part of the Fl_Button (which corresponds the the interface implemented by all button widgets), the method is added to the ButtonExt trait, with the implementation added to the fltk-derive/src/button.rs impl_button_trait derive macro. Otherwise it's added directly in the fltk/src/button.rs in the impl of the corresponding button widget. If the method requires special handling or could benefit from an example, add an example to the fltk/examples directory, showing a minimal application using that method.