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 697681 - libsecret Vala binding is missing extern constants
libsecret Vala binding is missing extern constants
Status: RESOLVED FIXED
Product: libsecret
Classification: Other
Component: General
unspecified
Other Linux
: Normal normal
: ---
Assigned To: libsecret maintainer(s)
libsecret maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2013-04-10 02:18 UTC by Eric Gregory
Modified: 2018-03-22 17:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
lib/schemas: Add secret_get_schema() accessor for SECRET_SCHEMA_*s (3.86 KB, patch)
2017-09-15 17:26 UTC, Philip Withnall
committed Details | Review

Description Eric Gregory 2013-04-10 02:18:08 UTC
The binding for libsecret is missing the following two constants:

SECRET_SCHEMA_NOTE
SECRET_SCHEMA_COMPAT_NETWORK
Comment 1 Stef Walter 2013-06-21 06:09:28 UTC
Evan, do you know how we can make these show up in the vapi? They're in secret-schemas.h here:

https://git.gnome.org/browse/libsecret/tree/libsecret/secret-schemas.h

... and look like this:

/*
 * A note or password stored manually by the user.
 */
extern const SecretSchema *  SECRET_SCHEMA_NOTE;

/*
 * This schema is here for compatibility with libgnome-keyring's network
 * password functions.
 */

extern const SecretSchema *  SECRET_SCHEMA_COMPAT_NETWORK;
Comment 2 Evan Nemerson 2013-06-21 17:41:47 UTC
It's easy enough to use a *-custom.vala to tell Vala about them, but Vala doesn't see them because they're not in the GIR and, if possible, I would rather get g-ir-scanner to pick them up so all languages can benefit.  I'm not sure how to go about that.  Colin, do you know if it is possible?  FWIW they also have gtk-doc comments in secret-schemas.c.
Comment 3 Philip Withnall 2017-09-15 09:56:57 UTC
Looks like a g-ir-scanner bug.
Comment 4 Emmanuele Bassi (:ebassi) 2017-09-15 10:24:31 UTC
To be fair, as an API, this is pretty grim.

This should be a global function, e.g.

```
SecretSchema *secret_get_schema_note (void);
SecretSchema *secret_get_schema_compat_network (void);
```

Or an enumeration and a function, e.g.:

```
typedef enum {
  SECRET_SCHEMA_TYPE_NOTE,
  SECRET_SCHEMA_TYPE_COMPAT_NETWORK
} SecretSchemaType;

SecretSchema *secret_get_schema (SecretSchemaType schema_type);
```

Exporting a complex type as an extern variable is typically a recipe for disaster, considering the lack of guarantees of `const` in C.

Anyway, I don't think we currently parse this kind of construct outside of simple types; it'll require some surgery in the parser.
Comment 5 Philip Withnall 2017-09-15 11:00:41 UTC
Yeah, if this is going to require significant changes to g-ir-scanner, it might be best to punt it back to libsecret and just add new public API there, and use that from the bindings instead.
Comment 6 Philip Withnall 2017-09-15 17:26:52 UTC
Created attachment 359868 [details] [review]
lib/schemas: Add secret_get_schema() accessor for SECRET_SCHEMA_*s

The SECRET_SCHEMA_* extern structs are not introspectable; add a new
accessor function which takes an enum and returns a struct, which is
introspectable.

Mark the old extern structs as (skip), but don’t deprecate them because
they’re still useful from C (if unconventional).

Signed-off-by: Philip Withnall <withnall@endlessm.com>
Comment 7 Daiki Ueno 2018-03-22 17:27:21 UTC
Review of attachment 359868 [details] [review]:

Looks good, except the indentation.
Comment 8 Philip Withnall 2018-03-22 17:47:55 UTC
Pushed with whitespace fixes, thanks.

Attachment 359868 [details] pushed as b738c9f - lib/schemas: Add secret_get_schema() accessor for SECRET_SCHEMA_*s