Use a different type to indicate Pango Units

[johncf]

After looking at the gir file, an automated way to generate this seems not possible. So, I would like to suggest two possible alternatives:

• Don't use gir! (How often does gir specs change?)
• Create a Pango-1.0.gir.patch file which would add special attributes to Pango-1.0.gir to handle cases like this and gtk-rs/pango#62. This will also involve adding pango-specific code-generation rules to gir.

Update: Below is an example implementation of pango units which would make working with them a lot more convinient and less error prone:

#[macro_use]
extern crate derive_more;

#[derive(Add, Sub, Mul, Div,
         AddAssign, SubAssign, MulAssign, DivAssign)]
struct Units(pub i32);

impl From<f64> for Units {
    fn from(val: f64) -> Units {
        Units((val * pango::SCALE as f64).round() as i32)
        // or use ffi::pango_units_from_double
    }
}

impl From<Units> for f64 {
    fn from(val: Units) -> f64 {
        val.0 as f64 / pango::SCALE as f64
        // or use ffi::pango_units_to_double
    }
}

[EPashkin]

Sorry, But I do not see a connection between this and gtk-rs/pango#62 (with can be solved by setting return non-optional, maybe after some Gir fix). Currently we against patching .gir files. If you mean change f64 parameters to Units in generated code: all parameter transformation can be added to Gir.toml after https://github.com/gtk-rs/gir/issues/264 (I currently don't have enough free time to start).

[johncf]

Sorry, But I do not see a connection between this and gtk-rs/pango#62 (with can be solved by setting return non-optional, maybe after some Gir fix).

Is there already an easy way to set return values non-optional even if the ffi return type is bool?

If you mean change f64 parameters to Units in generated code:
all parameter transformation can be added to Gir.toml after gtk-rs/gir#264 (I currently don't have enough free time to start).

No, I meant changing i32 parameters that represent pango units to a different type. The problem is that there is no attribute present in pango's gir file which indicate whether an i32 is a pango unit or whether it is a simple integer (for example, just a count of things). So, automatic conversion will not work. I don't think gtk-rs/gir#264 handles those cases as of now. (Handling it would involve giving some kind of list of method names, parameter positions and the new type for conversion).

[EPashkin]

Is there already an easy way to set return values non-optional even if the ffi return type is bool?

For normal function it can be done with nullable=false. In this case (output parameters) will be used same syntax.

As for type changing it will be transformation. Signals already have initial implementation that controlled by config

[johncf]

As for type changing it will be transformation. Signals already have initial implementation that controlled by config

That's great! Is this the effect of transformation you pointed out? And it seems to be implemented here? So, I'd assume something similar could be done for the required object.function.parameters and object.function.returns, right? But is it currently limited to signals, since TransformationType is defined in signals.rs?

[EPashkin]

Yes, for all question :wink: As this PR required custom types etc., it will be done after simpler cases, like removing len parameters.

[bilelmoussaoui]

It seems like there is an interest to completely drop this whole mess of Pango.Unit in Pango 2.0, maybe worth bringing the pain points upstream.

[bilelmoussaoui]

I will go ahead and close this one and let upstream fix it, it is too much of a change to do from the bindings side. Wdyt @sdroege ?

[sdroege]

Nobody seems to care enough to do the work, so yes let's close this. For GStreamer we did such things with gst::ClockTime but there was actual interest behind having this happen.