Rust: GtkWidget vs gtk::Widget

In rust bindings I see GtkWidget via gtk_sys and gtk::Widget via gtk. Are they the same?


_sys and thus GtkWidget are the C-FFI types, gtk::Widget is a safe wrapper and more “rustified” api of it.

Thanks, so can they be used interchangeably ?

No, they can’t. You generally will want to be using the safe types, gtk::Widget.

OK, thanks for the info. What is the safe equivalent of that call then?
I need to pass GtkSocket but from rust I have a gtk::Socket. More precisely, I need to pass c_void to GtkSocket but I have gtk::Socket.

You can convert between the types using the glib::translate functionality

More specifically, the ToGlibPtr, FromGlibPtrFull and FromGlibPtrNone traits (and some others less important ones).

Technically a gtk::Widget is equivalent in memory representation to a *mut gtk_sys::Widget, just with lots of extra (safe!) API on top of it and memory management via the Drop / Clone traits.

Tbh, I would look into adding a safe wrapper around glib_sys::g_io_add_watch and potentially contribute it upstream :slight_smile:

GIOChannel is semi-deprecated API and not very nice to use, and you ideally use one of the many alternatives to it.

Hi, what would be those alternatives?

What do you want to use it for? There is a lot of similar API in gio, for example.

I am working on porting (running onboard process inside rust app):

And I am stuck in the literally last statement:

gtk_socket_add_id(GTK_SOCKET(data[1]), (Window)atoi(string1));

That is, it does compile but no onboard is displayed. I suspect that because I don’t use GtkSocket but gtk :: socket.

You could use gio::UnixInputStream / gio::UnixOutputStream for that GIOChannel usage in the code snippet.

That is correct. The “problem” with that is that I already have that GIOChannel, so it seems not correct to try to do “better” version of it, when I still don’t have the onboard run at all. At later stage, during refactoring etc, I’ll probably do use the “better” channel.
Would you terribly mind and try that example yourself and see if you can make that onboard displayed and working?

It looks like the functionality is not implemented:
/// We transfer the ownership to the foreign library.
fn to_glib_full(&self) → P {

The trait doesn’t provide a default implementation and has to be implemented case by case.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.