Update: See comment https://github.com/gtk-rs/gtk-rs-core/pull/600#issuecomment-1302872708 for the general status of this PR.

Original comment: All of these TryFrom are panicking when they don't really need to. This is probably going to break some other things, I'd like to check this against gtk-rs and gstreamer-rs at least. Another option is to leave the panicking From traits in and also support TryFrom.

Also makes GString deref as a GStr

Currently many macros have a G/g as prefix while others don't. We should do this consistently.

Any objections to drop the prefix on all macros?

CC @bilelmoussaoui @GuillaumeGomez

And potentially also rename glib::String to glib::StringBuilder (which Vala did, for example), but OTOH the Rust "string builder" type is also just called String.

@bilelmoussaoui @GuillaumeGomez Opinions?

Motivation:

Rust has a lot of crates with already-defined types. Those types can't be reimplemented as GObjects without a huge amount of efforts. I find the type AnyGObject to be extremely useful, especially when putting Rust types inside a gio::ListModel

SendAnyGObject

I don't know how to create an Any + Send + Sync variant. I know how to make a Rust type Send, but I don't know how to make a glib type Send.

This more or less reverts https://github.com/gtk-rs/glib/commit/390ca3a2 ("Don't implement ToValue for Value").

Closes #4.

To be honest, I'm not 100% sure if this is the best way forward. The traits and trait bounds are really convoluted and hard to keep track of. For example, I don't know how well this works for SendValue. Let me know what you think.

At the moment if clone! fails to upgrade a weak reference it logs a message and returns ().

    button_decrease.connect_clicked(clone!(@weak button_increase =>
        move |_| {
            number.set(number.get() - 1);
            button_increase.set_label(&number.get().to_string());
    }));

When this occurs this is probably a bug. Changing the default to panic would make this more obvious.

Disadvantages:

• Breaking change from old behavior that is not easy to detect
• For gtk apps it is questionable if you want the app of a user to crash because of this

@sdroege, @YaLTeR

Bug description

After upgrading to gtk/glib 0.14.0 my application and all integration tests fail at:

thread 'main' panicked at 'assertion failed: context.is_owner()', /home/user/.cargo/registry/src/github.com-1ecc6299db9ec823/glib-0.14.0/src/main_context_channel.rs:507:17

I managed to reproduce it with a simple program:

src/main.rs:

const DEFAULT_CONTEXT : Option<&glib::MainContext> = None;

fn main() {
    let (_sender, receiver) = glib::MainContext::channel(glib::PRIORITY_DEFAULT);
    let handler = move |event: i32| {
        println!("got event: {}", event);
        glib::Continue(true)
    };
    receiver.attach(DEFAULT_CONTEXT, handler);  // panics
}

Cargo.toml:

[package]
name = "glib-context-test"
version = "0.1.0"
edition = "2018"

[dependencies]
glib = "0.14.0"

Tested on: Manjaro 21.0.7 Rust 1.53.0

Backtrace

$ RUST_BACKTRACE=full cargo run
   Compiling proc-macro2 v1.0.27
   Compiling unicode-xid v0.2.2
   Compiling syn v1.0.73
   Compiling serde v1.0.126
   Compiling anyhow v1.0.41
   Compiling unicode-segmentation v1.7.1
   Compiling either v1.6.1
   Compiling smallvec v1.6.1
   Compiling version-compare v0.0.11
   Compiling pkg-config v0.3.19
   Compiling strum v0.21.0
   Compiling version_check v0.9.3
   Compiling futures-core v0.3.15
   Compiling libc v0.2.97
   Compiling futures-task v0.3.15
   Compiling autocfg v1.0.1
   Compiling bitflags v1.2.1
   Compiling futures-channel v0.3.15
   Compiling pin-utils v0.1.0
   Compiling pin-project-lite v0.2.7
   Compiling slab v0.4.3
   Compiling once_cell v1.8.0
   Compiling itertools v0.10.1
   Compiling cfg-expr v0.7.4
   Compiling heck v0.3.3
   Compiling proc-macro-error-attr v1.0.4
   Compiling proc-macro-error v1.0.4
   Compiling futures-util v0.3.15
   Compiling quote v1.0.9
   Compiling futures-executor v0.3.15
   Compiling toml v0.5.8
   Compiling thiserror-impl v1.0.25
   Compiling strum_macros v0.21.1
   Compiling thiserror v1.0.25
   Compiling proc-macro-crate v1.0.0
   Compiling system-deps v3.1.2
   Compiling glib-macros v0.14.0
   Compiling glib-sys v0.14.0
   Compiling gobject-sys v0.14.0
   Compiling glib v0.14.0
   Compiling glib-context-test v0.1.0 (/home/user/dev/project/test/rust/glib-context-test)
    Finished dev [unoptimized + debuginfo] target(s) in 1m 03s
     Running `target/debug/glib-context-test`
thread 'main' panicked at 'assertion failed: context.is_owner()', /home/user/.cargo/registry/src/github.com-1ecc6299db9ec823/glib-0.14.0/src/main_context_channel.rs:507:17
stack backtrace:
   0:     0x564ba96568d0 - std::backtrace_rs::backtrace::libunwind::trace::ha5edb8ba5c6b7a6c
                               at /rustc/53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b/library/std/src/../../backtrace/src/backtrace/libunwind.rs:90:5
   1:     0x564ba96568d0 - std::backtrace_rs::backtrace::trace_unsynchronized::h0de86d320a827db2
                               at /rustc/53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2:     0x564ba96568d0 - std::sys_common::backtrace::_print_fmt::h97b9ad6f0a1380ff
                               at /rustc/53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b/library/std/src/sys_common/backtrace.rs:67:5
   3:     0x564ba96568d0 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h14be7eb08f97fe80
                               at /rustc/53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b/library/std/src/sys_common/backtrace.rs:46:22
   4:     0x564ba9670e2f - core::fmt::write::h2ca8877d3e0e52de
                               at /rustc/53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b/library/core/src/fmt/mod.rs:1094:17
   5:     0x564ba96550c5 - std::io::Write::write_fmt::h64f5987220b618f4
                               at /rustc/53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b/library/std/src/io/mod.rs:1584:15
   6:     0x564ba965875b - std::sys_common::backtrace::_print::h7f1a4097308f2e0a
                               at /rustc/53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b/library/std/src/sys_common/backtrace.rs:49:5
   7:     0x564ba965875b - std::sys_common::backtrace::print::h1f799fc2ca7f5035
                               at /rustc/53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b/library/std/src/sys_common/backtrace.rs:36:9
   8:     0x564ba965875b - std::panicking::default_hook::{{closure}}::hf38436e8a3ce1071
                               at /rustc/53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b/library/std/src/panicking.rs:208:50
   9:     0x564ba965822d - std::panicking::default_hook::he2f8f3fae11ed1dd
                               at /rustc/53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b/library/std/src/panicking.rs:225:9
  10:     0x564ba9658d6d - std::panicking::rust_panic_with_hook::h79a18548bd90c7d4
                               at /rustc/53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b/library/std/src/panicking.rs:591:17
  11:     0x564ba96588d7 - std::panicking::begin_panic_handler::{{closure}}::h212a72cc08e25126
                               at /rustc/53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b/library/std/src/panicking.rs:495:13
  12:     0x564ba9656d6c - std::sys_common::backtrace::__rust_end_short_backtrace::hbd6897dd42bc0fcd
                               at /rustc/53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b/library/std/src/sys_common/backtrace.rs:141:18
  13:     0x564ba9658869 - rust_begin_unwind
                               at /rustc/53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b/library/std/src/panicking.rs:493:5
  14:     0x564ba963dd91 - core::panicking::panic_fmt::h77ecd04e9b1dd84d
                               at /rustc/53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b/library/core/src/panicking.rs:92:14
  15:     0x564ba963dcdd - core::panicking::panic::h60569d8a39169222
                               at /rustc/53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b/library/core/src/panicking.rs:50:5
  16:     0x564ba963f73a - glib::main_context_channel::Receiver<T>::attach::h594fcf9e7dc84a34
                               at /home/user/.cargo/registry/src/github.com-1ecc6299db9ec823/glib-0.14.0/src/main_context_channel.rs:507:17
  17:     0x564ba964305d - glib_context_test::main::hc555b5f4c0db2dae
                               at /home/user/dev/project/test/rust/glib-context-test/src/main.rs:9:5
  18:     0x564ba9641dcb - core::ops::function::FnOnce::call_once::h17df49f787978c02
                               at /home/user/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:227:5
  19:     0x564ba964003e - std::sys_common::backtrace::__rust_begin_short_backtrace::hc9dee5163aee7e43
                               at /home/user/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys_common/backtrace.rs:125:18
  20:     0x564ba96400c1 - std::rt::lang_start::{{closure}}::heeab27af11fe19e8
                               at /home/user/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/rt.rs:49:18
  21:     0x564ba965916a - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::hc4354216bf39217c
                               at /rustc/53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b/library/core/src/ops/function.rs:259:13
  22:     0x564ba965916a - std::panicking::try::do_call::hb68eb312780385cf
                               at /rustc/53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b/library/std/src/panicking.rs:379:40
  23:     0x564ba965916a - std::panicking::try::h22b8e08595060b8b
                               at /rustc/53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b/library/std/src/panicking.rs:343:19
  24:     0x564ba965916a - std::panic::catch_unwind::hc64f1a6a0e71b1fc
                               at /rustc/53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b/library/std/src/panic.rs:431:14
  25:     0x564ba965916a - std::rt::lang_start_internal::h4461fc58637f04f8
                               at /rustc/53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b/library/std/src/rt.rs:34:21
  26:     0x564ba96400a0 - std::rt::lang_start::h6c3d3c3dbe636292
                               at /home/user/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/rt.rs:48:5
  27:     0x564ba964315c - main
  28:     0x7f3b4857db25 - __libc_start_main
  29:     0x564ba963e48e - _start
  30:                0x0 - <unknown>

Bug description

Cannot build project with glib 0.15.0. Version 0.14.8 works.

Error message

error: failed to parse manifest at `/home/remco/.cargo/registry/src/github.com-1ecc6299db9ec823/glib-0.15.0/Cargo.toml`

Caused by:
  can't find library `glib`, rename file to `src/lib.rs` or specify lib.path

This adds a new weak reference for Objects, so that we can connect a callback for when the obejct is disposed.

WeakRefLocal is needed because g_object_weak_ref and g_object_weak_unref. This adds a rust way to use g_object_weak_ref g_object_weak_unref.

While trying to use a generic shared wrapper I got this error:

warning: unnecessary parentheses around type                                                                           
   --> /home/lollo/gtk-rs-core/glib/src/shared.rs:34:47                                                           
    |                                                      
34  |               phantom: std::marker::PhantomData<($($($generic),+)?)>,                                            
    |                                                 ^                 ^        

But then I found out that field is useless anyway, because the generic type is already used in the field above, so I've removed the phantom field.

glib::GString::from("test\0");

thread 'main' panicked at 'CString::new failed: NulError(4, [116, 101, 115, 116, 0])'

Not surprising, but can we do something about it? I was thinking about dropping null bytes in the from() function. But maybe I'm just to obsessed with having code that cannot panic :laughing:

Needs reviewing

Stuff thats missing

• [ ] unix_open_pipe (marked as unsafe for the moment)
• [ ] spawn_async_with_pipes (marked as unsafe for the moment)
• [x] spawn_async_with_fds
• [x] g_subprocess_launcher_take_fd
• [x] g_subprocess_launcher_take_stderr_fd
• [x] g_subprocess_launcher_take_stderr_fd
• [x] g_subprocess_launcher_take_stdin_fd
• [x] g_subprocess_launcher_take_stdout_fd
• [x] into_raw_unix_fd
• [x] into_raw_unix_fd_local
• [x] g_unix_fd_add_full

The documentation for glib::wrapper! contains the following sentence:

What follows is a description of each of the possible $kind: Boxed, Shared, and Object

However, what follows is actually a description of four options, since BoxedInline is also documented.

Additionally, from various other sources it would seem that ObjectSubclass is yet another acceptable $kind, yet does not appear to be documented in that page at all.

CC @pbor

This would be a NULL-terminated array of *const char, i.e. without length information stored. And would be useful for passing such things over FFI and e.g. borrowing *const *const char to C code.

Should have the usual kind of APIs (iterator things, index, append, etc) for collections implemented.

Sending it to another thread (or just setting another default context) will cause incorrect things to happen when calling SourceId::remove.

Background here: https://github.com/gtk-rs/gtk-rs-core/pull/818#discussion_r1046147923