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

Records in normal mode #103

Open
EPashkin opened this issue Jul 30, 2015 · 8 comments
Open

Records in normal mode #103

EPashkin opened this issue Jul 30, 2015 · 8 comments

Comments

@EPashkin
Copy link
Member

Part of #102
Seems records will more difficult that I think.

  • Its needed wrapper (analog of Object but maybe without inheritance).
  • Also needed autogenerated file with wrapping ffi types. Not sure better do one file for all records in gtk_sys or separate some (with functions) or all.
  • when record act as in parameter then it passed by reference and translated with to_glib_none.
  • act as return then it optioned and translated with from_glib_none()
@gkoz
Copy link
Member

gkoz commented Jul 30, 2015

We seem to be going down the one struct per file path so it makes sense to do the same with records.

Wrapping them is a bit more difficult mostly because some of them are refcounted (ref/unref methods) and others (let's call them owned) are not (copy/free). Can't say if using generics is worth it. Possibly. We obviously don't want to expose any of (ref, unref, copy, free, and possibly more).

The owned records have to be taken as arguments by &mut not &. And I haven't really explored the implications for the translate API, but I expect it to work.

The kind of ownership transfer (none/full) we know.

@gkoz
Copy link
Member

gkoz commented Jul 30, 2015

The owned records have to be taken as arguments by &mut not &.

Unless the function takes a const *.

@gkoz
Copy link
Member

gkoz commented Jul 30, 2015

Theoretically, if an owned record is passed as an argument with transfer: full we could take the wrapper by value (consume). No idea how many such cases there actually are.

@gkoz
Copy link
Member

gkoz commented Oct 14, 2015

Some "Boxed" types support has been added. A completely opaque struct can be represented now. Other kinds need more thinking.

@EPashkin
Copy link
Member Author

EPashkin commented Nov 2, 2015

6 owned(boxed) records without fields: IconSource(deprecated 3.10), PaperSize, SelectionData(no constructor), TreePath, TreeRowReference(no external usage), WidgetPath(has copy, free, ref, unref).
5 with fields: Border, Requisition(width,height), TargetEntry, TextIter(all fields dummy), TreeIter(also).
1 without glib:get-type: StockItem (fields, deprecated 3.10).

Some have only copy, ref, unref: IconSet(deprecated 3.10), TextAttributes, so it don't count as boxed.
I try write generation for first 6 with PaperSize as start.

@gkoz
Copy link
Member

gkoz commented Nov 2, 2015

While the owned and refcounted records need slightly different wrappers, the difference probably doesn't matter for the conversions code.

The caller-allocates attribute, that is currently ignored, impacts the outparams records conversions.

caller-allocates="0" transfer-ownership="xyz":

    let mut ptr = ptr::null_mut();
    ffi::func(&mut ptr);
    from_glib_xyz(ptr)

caller-allocates="1" transfer-ownership="none":

    let mut rec = Rec::uninitialized();
    ffi::func(rec.to_glib_none_mut().0);
    rec

@gkoz
Copy link
Member

gkoz commented Nov 2, 2015

Now, there also are "plain old data" records like GdkRectangle and GtkAccelKey that probably don't need any conversions but are passed by pointer.

@EPashkin EPashkin mentioned this issue Nov 4, 2015
homu added a commit that referenced this issue Nov 6, 2015
@EPashkin EPashkin mentioned this issue Nov 19, 2015
@gkoz
Copy link
Member

gkoz commented Nov 28, 2015

So, there now exist Boxed and Refcounted wrappers but a big issue with Boxed records is that

sdroege pushed a commit to sdroege/gir that referenced this issue Apr 19, 2018
Generate ApplicationCommandLine.
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