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 678506 - Make GcrGnupgCollection (and GcrGnupgKey?) public
Make GcrGnupgCollection (and GcrGnupgKey?) public
Status: RESOLVED OBSOLETE
Product: gcr
Classification: Core
Component: General
3.4.x
Other Linux
: Normal normal
: ---
Assigned To: GNOME keyring maintainer(s)
GNOME keyring maintainer(s)
Depends on:
Blocks: 676828
 
 
Reported: 2012-06-20 21:14 UTC by Matthew Barnes
Modified: 2021-05-17 13:06 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Evolution OpenPGP Settings (54.79 KB, image/png)
2012-06-20 21:14 UTC, Matthew Barnes
  Details
Make GcrGnupgCollection public (11.06 KB, patch)
2012-06-20 21:15 UTC, Matthew Barnes
needs-work Details | Review

Description Matthew Barnes 2012-06-20 21:14:26 UTC
Created attachment 216876 [details]
Evolution OpenPGP Settings

I'm interested in making Evolution more tightly integrated with your crypto libraries.  This is also a learning process for me, so I'm taking baby steps.

I thought an easy place to start would be replacing our GPG Key ID text entry box in account preferences with a GcrComboSelector so available keys are all listed and users can just pick one.

(see attached screenshot)

However for this to work I guess the GcrGnupgCollection class needs to be made public so I can load it from Evolution.  I'm attaching a patch to do so.

It looks like GcrGnupgCollection elements are GcrGnupgKey's, which are also private.  Should that class be made public as well?  For my use case I only need the key ID for the selected combo box item, which I guess I could get through g_object_get().
Comment 1 Matthew Barnes 2012-06-20 21:15:39 UTC
Created attachment 216877 [details] [review]
Make GcrGnupgCollection public

Let me know if GcrGnupgKey should also be public.  I'll post a revised patch.
Comment 2 Stef Walter 2012-06-22 05:57:18 UTC
Review of attachment 216877 [details] [review]:

Thanks for working on this.

Yes I agree GcrGnupgKey should be public as well. The GcrRecord however code isn't yet really fully baked in my opinion. So lets not expose that. We could:

 * Keep the 4 _gcr_gnupg_key_get_xxxx_records() private, and split them into their own header like gcr-gnupg-key-private.h (see gcr-list-selector-private.h)
 * Remove the 'public-records' and 'secret-records' properties. They're not used as properties anywhere in gcr, just via their accessor methods.

We also need to update, at least:
 * gcr-docs.sgml (add the documentation page)
 * gcr-base.h (add the headers)
 * gcr-base.symbols (new public symbols)
 * Makefile.am (HEADER_BASE_FILES install headers)

::: gcr/gcr-gnupg-collection.h
@@ -51,1 @@
 	GObjectClass parent_class;

Lets move the actual '_GcrGnupgCollectionClass' struct to gcr-gnupg-collection.c. That way we can change it later (base class, fields), and/or make it public at a later date.

Ditto for _GcrGnupgKey.

The typedefs would remain public.
Comment 3 Philip Withnall 2015-05-02 22:50:32 UTC
(In reply to Stef Walter from comment #2)
> Review of attachment 216877 [details] [review] [review]:
> 
> Thanks for working on this.
> 
> Yes I agree GcrGnupgKey should be public as well. The GcrRecord however code
> isn't yet really fully baked in my opinion. So lets not expose that.

What’s the state of GcrRecord now? Is it ready enough to be able to just make the whole of GcrGnupgCollection (and friends) public?

This is a blocker for dropping our use of libcryptui in Almanah (bug #676828), which is one of the few remaining reverse-dependencies on libcryptui.
Comment 4 GNOME Infrastructure Team 2021-05-17 13:06:26 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gcr/-/issues/60.