D358: 770_fltk.patch

Patch adds fltk support to pinentry

D357: 771_fltk.patch

forget add resources

D356: 772_fltk.patch

D355: 773_fltk.patch

input field tests removed

FL/fl_utf8.H in some distros is Fl/fl_utf8.h

D354: 774_fltk.patch

Thanks for your contribution! A few comments based on a quick skim of the code:

Why are you using the apparently invalid email address
"madrat@users.noreply.github.com" in the headers?

The code is not formatted according to the GNU coding standards (indentation
using tabs instead of 2 spaces; some lines are longer than 80 characters). I'm
not sure how important this is since the rest of the code has a fair number of
violations.

There are not many comments.

When commenting out large blocks of code (as you do in main.cxx), please use #if
0 ... #endif rather than using /* ... */.

@werner: Do we want to add support for FLTK? If so, I'll take a closer look at
this. My main concern is that this is another thing that we have to maintain
and I'm not sure the gtk pinentry is really just a burden for weak computers.

Dear Neal, I thank you for answer.

This issue's the main goal is getting an answer to a question - Do you plan
support FLTK. I suppose that it may be closed with comment "not need this
toolkit" - so I do not format according to the GNU coding standards - There are
many contentious issues about the format code - 80 chars per line is more then
enough for assembler, but for C++ with templates - not sure.
Your code is your rules, so If you plan to accept FLTK support - I fix all notes.

"Using email"
email "madrat@users.noreply.github.com" is also my email, which I use in
github.com and because I use local git, it will be inserted automatically.

"the rest of the code has a fair number of violations"
For my studies and knowledge - can you post sample of violation?

"There are not many comments."
The code should comment itself, and /* some comment for block */ really need
only for description the strongly non-obvious actions - like complex math,
optimization (with answer why optimize here) or factorization algorithm O(1) :-).

Given that FLTK is a C++ library and we already have a Qt frontend, I am not
sure whether adding this is a good idea. The problem is the usual ABI break due
to compiler or library changes. We already had our problems in the past with
the two Qt versions we supported. Adding FLTK would introduce those problems again.

Why are Qt or GTK+ not sufficient for small boxes?

I tend to agree with Werner: adding another pinentry program increases our
maintenance burden, but the new pinentry doesn't add any convincing features,
AFAIK. If there are some significant benefits, please add them. Otherwise, I
think I'll change this issue to wont-fix. Sorry. Nevertheless, thank you for
your contribution! I hope you'll find another way to contribute.

I wonder if we could / should use this as a replacement for Pinentry-w32?

Pinentry-w32 should die and FLTK could be lightweight enough that werner would
include it in gnupg-w32?

No, FLTK is not lightweight. It actually adds the requirement for a C++
compiler to GnuPG. And pinentry-w32 shall of course not die!

justus: we recently talked about this. Would you like to work on this. I am in
particular interested to use it for Windows statically linked.