Ian Douglas Scott

I agree this isn't ideal if it can be avoided (which may be difficult with all the trait magic going on). But the harm seems limited if the private struct...

It seems to me this is a broader issue that really applies to any subclass struct with at least one immutable member. It's rather a pain to have to use...

> It's not possible to share data between macros. This is one of the key problems with implementing an ergonomic API for properties and signals. In https://github.com/gtk-rs/gtk-rs-core/issues/214, I suggested adding...

Vala supports two types of properties (https://wiki.gnome.org/Projects/Vala/Manual/Classes#Properties): > Properties can either be declared with code that will perform particular actions on get and set, or can simply declare which actions...

These types all have constructors, so presumably they should be usable without subclassing. Though `DBusInterfaceSkeleton` (which already has bindings) is an abstact base class, so I think subclassing support for...

> that's less nice to use of course And inconsistent with other gtk-rs APIs. I wish the never type was available and implemented function traits so `None::` could magically work...

Oh, and I didn't even mention that it would need to expose a `_get_type()` function, a `#define` calling that, and anything else needed for binding a GObject. I really need...

Yeah, `StaticType` already covers that, it would just need a `#[no_mangle] extern "C"` wrapper to be called from outside Rust, which I don't think there is currently. But that's simple...

So something like seems to work: ```rust #[no_mangle] extern "C" fn my_type_get_type() -> glib::ffi::GType { MyType::static_type().into_glib() } ``` Plus a header file with the usual boilerplate. The hard part is...

It's not clear where to call that without the library having it's own `init` function, which seems like it shouldn't be necessary for every C library providing widgets. I ran...