At weak computers may be more lightweight and simple toolkits then Qt and GTK.
Thanks for your contribution! A few comments based on a quick skim of the code:
Why are you using the apparently invalid email address
"firstname.lastname@example.org" 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
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.
email "email@example.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.
Werner what is your opinion on this?
pinentry-w32 is broken. It does not handle variable string sizes and there is no
easy way to fix that. Afaik it was never intended as the "default" windows
pinentry but only as a crutch for windows ce experiments.
Would fltk be lightweight enough for your to replace pinentry-w32 in your
installer? In that case I think we should take a serious look at this patch as a
minimal pinentry version for windows.
(And delete pinentry-w32 instead)