After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 678229 - Introspection fixes for Vala bindings
Introspection fixes for Vala bindings
Status: RESOLVED FIXED
Product: libgnome-keyring
Classification: Core
Component: General
git master
Other Linux
: Normal normal
: ---
Assigned To: GNOME keyring maintainer(s)
GNOME keyring maintainer(s)
Depends on:
Blocks: 678440
 
 
Reported: 2012-06-16 21:43 UTC by Evan Nemerson
Modified: 2019-02-22 11:45 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
introspection: some minor fixes to avoid Vala regressions (3.84 KB, patch)
2012-06-16 21:43 UTC, Evan Nemerson
accepted-commit_now Details | Review

Description Evan Nemerson 2012-06-16 21:43:57 UTC
Created attachment 216592 [details] [review]
introspection: some minor fixes to avoid Vala regressions

Add the C include file name, change the "data" argument to "user_data" in GnomeKeyringOperation*Callback, and make GnomeKeyringOperationGetStringCallback's string argument nullable.

Once this is pushed I can either push the bindings to Vala or submit a patch to distribute them with libgnome-keyring... which would you prefer?
Comment 1 Stef Walter 2012-06-17 12:23:02 UTC
It's worth noting that the async libgnome-keyring API isn't introspected currently. It's not easily useable from most languages other than C. Can vala reliably use the async stuff?
Comment 2 Evan Nemerson 2012-06-17 18:00:14 UTC
Yes.  We have to un-skip all the functions in metadata so the API gets exposed, but something like this works:


private static int main (string[] args) {
  GLib.MainLoop loop = new GLib.MainLoop ();

  void* req = GnomeKeyring.get_default_keyring ((r, k) => {
      GLib.debug ("default keyring: %s (#%d: %s)",
                  k, r, GnomeKeyring.Result.to_message (r));
      loop.quit ();
    });
  // Cancelling works to, just uncomment
  // GnomeKeyring.cancel_request (req);

  loop.run ();

  return 0;
}


AFAIK the only reason other languages can't work is that they don't handle the void* return value.  It should be possible to get them to work by exposing GkrOperation as a boxed type and having all the async methods return that instead of void* (by using the type annotation--no need to change the C API).

It would actually be possible to make this type-safe in Vala without any changes to libgnome-keyring by creating (in the Vala bindings) a SimpleType struct with a cname of "void*", then have all the async methods return that and make cancel_request a method of that type... basically faking what I mentioned about GkrOperation without having to change libgnome-keyring.  The problem is that doing so would break backwards-compatibility with the existing bindings, so I've just left them as returning void*.

After doing something about the void* return value the only problematic part for other langauges would be the functions that take a GnomeKeyringOperationGetListCallback.  The updated Vala bindings use a generic delegate, so it looks something like this (which works quite well and is type-safe, unless you count the void* return value):


public delegate void OperationGetListCallback<T> (GnomeKeyring.Result result, GLib.List<T> list);
public static void* find_items (GnomeKeyring.ItemType type, GnomeKeyring.AttributeList attributes, owned GnomeKeyring.OperationGetListCallback<GnomeKeyring.Found> callback);


For other languages to work you would need to create a typedef for each different type (i.e., GnomeKeyringOperationGetStringListCallback for a list of strings, GnomeKeyringOperationGetFoundListCallback for a list of GnomeKeyringFound, etc.), then use the type annotation to have introspection use those instead of GnomeKeyringOperationGetListCallback.
Comment 3 Stef Walter 2012-06-22 08:06:58 UTC
Comment on attachment 216592 [details] [review]
introspection: some minor fixes to avoid Vala regressions

Okay thanks. This patch looks good to me.