articles
Thanks!
Last weekend was the second Rust+GNOME hackfest. Just like the first time, it aimed to bring more Rust into GNOME libraries and more GNOME libraries into Rust. This time, it took place in Berlin at the [Kinvolk office].
A lot of things as you imagine! Allowing developers to work together in a same place fastened up things a lot! Let's make a little tour of what people were working on:
A few others were here as well and talking with them allowed me to add even more items into the gtk-rs roadmap.
On two things mainly. The first one was to generate the Debug trait implementation for the sys crates of gtk-rs so that it's easier for people who wants to add their own bindings over gtk-rs's libraries to debug what's going on.
As you may guess, a few issues went into this implementation. The main one was c_void.
As it seems logical, c_void cannot be displayed since it isn't supposed to be used without a pointer to it. However, we use this type "as is" in a few sys-types. For example:
Run#[repr(C)]
pub struct GDate {
_truncated_record_marker: c_void,
// ...
}
Normally, we'd just go through every field of the struct and generate the Debug implementation like this:
Runimpl ::std::fmt::Debug for GDate {
fn fmt(&self, f: &mut ::std::fmt::Formatter) -> ::std::fmt::Result {
f.debug_struct(&format!("GDate @ {:?}", self as *const _))
.field("_truncated_record_marker", &self._truncated_record_marker)
// ...
.finish()
}
}
But unfortunately, the c_void type doesn't implement Debug (which is logical since c_void is litteraly nothing). So this implementation will just fail. So how to do it then? It's not a pointer so I can't display its address but I'd still like to have the field displayed... The solution we agreed on was simply to display "c_void" in such cases:
Runimpl ::std::fmt::Debug for GDate {
fn fmt(&self, f: &mut ::std::fmt::Formatter) -> ::std::fmt::Result {
f.debug_struct(&format!("GDate @ {:?}", self as *const _))
.field("_truncated_record_marker", "c_void")
// ...
.finish()
}
}
The same goes for the newtypes as follows:
Run#[repr(C)]
pub struct GdkPixbufFormat(c_void);
You can't derive Debug because of c_void (logical) so we have to implement it by hand once again:
Runimpl ::std::fmt::Debug for GdkPixbufFormat {
fn fmt(&self, f: &mut ::std::fmt::Formatter) -> ::std::fmt::Result {
write!(f, "GdkPixbufFormat @ {:?}", self as *const _)
}
}
If the wrapped type isn't c_void, then you just have to #[derive(Debug)] as follows:
Run#[derive(Debug)]
pub struct GMutex([u32; 2]);
Yes but it was more because of [gir][gir]'s internals and limits than anything else. For example, not all fields from all types are generated. In such case, you obviously can't generate the Debug implementation for them. If you want to go into the details, I recommend you to take a look at the pull request. You can also take a look to the generated code from this pull request here.
A lot of discussions! We were able to talk about gtk-rs's future and what could be added, either in the crates directly or "outside" (understand the tutorials or documentation). More and more people are asking for gtk-rs tutorials directly and for more examples. The second one is already on its way but the first one was quite a surprise: I thought that people would read C tutorials and then port their code to Rust. However, it's now clear that it's not really the case and that a lot of gtk-rs's users never used GNOME libraries before that.
The other discussions were mostly about the next gtk-rs release. It'll be a "medium" one: there are breaking changes in the API but it brings a lot of great features. However, I'll detail all this once it'll be done, no need for spoilers. :p
It was the second time I went to Berlin and just like last time, I really enjoyed the trip (thanks so much Zeeshan for the restaurants!).
And finally (last but not least):
... for sponsoring my travel and accomodation during the hackfest!
