Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generate signals #199

Closed
EPashkin opened this issue Jan 28, 2016 · 10 comments
Closed

Generate signals #199

EPashkin opened this issue Jan 28, 2016 · 10 comments

Comments

@EPashkin
Copy link
Member

Generate pub trait xxxSignals for classes with "IsA" implementation for classes with children
or direct implimentation for classes without children (same as for "xxxExt" traits).
For both cases generate trampoline function.

Example for ComboBox and TreeSelection: https://github.com/EPashkin/rust-gnome-gtk/tree/signal_sample

@gkoz
Copy link
Member

gkoz commented Jan 28, 2016

I'm still undecided about where exactly the signals belong. If they are generated alongside other functions, perhaps xxxSignals traits are unnecessary, just put them into xxxExt?

Also we should probably fix callback_guard! to not require importing the struct.

@EPashkin
Copy link
Member Author

Currently signals trait implemented with bound IsA<ComboBox> + IsA<Object>.

@gkoz
Copy link
Member

gkoz commented Jan 28, 2016

Yeah the IsA<Object> is required to get ToGlibPtr<*mut GObject> but it's harmless as a bound because all objects implement it.

@EPashkin
Copy link
Member Author

Other that bound don't see any problem with implementing in xxxExt or in same impl for childless class.

@gkoz
Copy link
Member

gkoz commented Jan 28, 2016

Generating correct trampoline signatures might require finishing the ffi_ng branch. Eventually I'd like the trampoline signatures to match C exactly (no f: &Box<Fn(...)>, but rather cast user_data: gpointer to &Box<Fn(...)>).

@gkoz
Copy link
Member

gkoz commented Jan 28, 2016

It's worse than that: signal definitions seem to routinely omit c:type attributes:

      <glib:signal name="accel-activate" detailed="1">
...
        <parameters>
          <parameter name="acceleratable" transfer-ownership="none">
            <doc xml:space="preserve">the object on which the accelerator was activated</doc>
            <type name="GObject.Object"/>
          </parameter>
          <parameter name="keyval" transfer-ownership="none">
            <doc xml:space="preserve">the accelerator keyval</doc>
            <type name="guint" c:type="guint"/>
          </parameter>
          <parameter name="modifier" transfer-ownership="none">
            <doc xml:space="preserve">the modifier combination of the accelerator</doc>
            <type name="Gdk.ModifierType"/>
          </parameter>
        </parameters>
      </glib:signal>

@EPashkin
Copy link
Member Author

If it omit only for glib-related types then its not big problem

@gkoz
Copy link
Member

gkoz commented Jan 28, 2016

Speaking of signals, I'm yet again considering adding Borrow<T> and BorrowMut<T> wrappers, that forget their contents on destruction, and from_glib_borrow transfer mode so callback parameters could truly be borrowed without touching refcounts or copying boxed types (e.g. GdkEvent).

@EPashkin EPashkin mentioned this issue Feb 5, 2016
@EPashkin
Copy link
Member Author

EPashkin commented Feb 5, 2016

Signals with no-recurse could take FnMut instead of Fn.

@EPashkin
Copy link
Member Author

All child issues was closed, so I also close this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants