[OT] pinentry 0.7.1 & Gtk+-2

[Marcus Brinkmann]

At Wed, 01 Sep 2004 14:53:29 +0000,
Albrecht Dreß wrote:
> Am 17.08.04 20:31 schrieb(en) Marcus Brinkmann:
> > 1. The GNU coding style should be honored, at least for our own code.
> >    It doesn't make much sense for gtksecentry.{c,h}, but I changed it
> >    for pinentry-gtk-2.c.  Please keep this in mind for the future.
> 
> Sorry.. I'll do that! Is "indent -gnu" sufficient, or do you recommend/ 
> require additional options?

Well, for the patch I already did that, at least for those parts we
want it for.  I really recommend reading the GNU standards and using
the emacs C mode in its default settings, this will get most of it
right.  I guess indent will also do a good job, but I never tried it.
Manual discretion is always required in some cases, for example when
the number and content of comments is regarded (a simple rule is to
put two spaces after each full stop, but of course there are some
periods which do not end a sentence, and then you only need one space,
etc).

Also I don't think indent will touch things like this:

int a, b;

which should be

int a;
int b;

and it probably won't deal with other issues like not initializing
static or global variables, etc.  It's a huge topic.
 
> > 2. We need a clearer copyright statement from you for
> [snip]
> >    The simplest thing for you would be to just add yourself to the top
> >    of the file, where the other authors are listed, like this:
> 
> A patch (against today's cvs) is attached. I hope it's o.k. now?

Looks fine.
 
> > 3. We have no copyright in padlock-keyhole.xpm.  I think you told me
> 
> Starting with gtk+ 2.4.0, this icon is now a "stock" one (and not only  
> referred to in the gnome hig). So you can (should) remove the xpm file  
> from the cvs, the (tiny) changes needed in the sources are again in the  
> patch below.

Excellent.
 
> > 4. I think we would want assignment for the changes to
> >    pinentry-gtk-2.c and the configure.ac and Makefile.am files
> >    (gtksecentry.{h,c} are special again).  Are you willing to do that?
> 
> Sure, if you tell me what I have to do... ;-))

Actually, after discussing this with Werner, it turns out we do not
require this, because of the nature of the pinentry package.

I just had an idea though.  If you really care about this a lot, you
may want to make a secure widget part of gtk proper.  This might
require making the code a bit more abstract to allow setting callbacks
for memory allocation.  I found out that making a widget secure
usually requires messing with intimate internals of the widget set,
and thus I think there is some sense in letting widget people deal
with it, not application writers (ie, you not only derive from
standard widgets, but you go into the implementation of existing
widgets).

In the process of adding such a beast to gtk, you would assign your
changes to whatever gtk people assign their changes, probably the FSF.

But if that doesn't sound like fun for you, don't sweat it.  We are
quite happy with having all this messy stuff in pinentry just as well.

Thanks,
Marcus