In the "Certify Certificate" window the advanced options are always collapsed when you open a new dialog window.
It would be better if Kleopatra remembers the user preference. That is if you have expanded the advanced options before, it will always do so until you collapse the view again.
| rKLEOPATRA Kleopatra | |||
| rKLEOPATRA8cfc2b51add9 Add some tool tips | |||
| rKLEOPATRAdbf08f5c90c0 Don't use animation to show advanced options initially | |||
| rKLEOPATRAae6d6ecef735 Store the visibility of the advanced options | |||
And please add a tooltip for "Certify for everyone to see (exportable)", all other options there have one.
Suggestion for the text:
Makes the certification exportable. If you have to certify a certificate as proxy for other people, it is necessary to enable this option.
Yes, this should be a fairly low hanging fruit and would improve UX for some users probably quite a bit. So while not very important I give it high priority because we should do it sooner.
Done. The visibility of the advanced options is now remembered. For individual certifications the advanced options are not visible by default, for bulk/group certifications they are visible by default. Therefore, the state is stored separately for both cases.
Additionally, I have added some tool tips which are hopefully understandable for most users.
Thank you for the tool tips!
Regarding the visibility: If you certify after opening or closing the advanced options, the visibility is remembered, otherwise not.
This is a bit unexpected for me. But i guess it is probably owed to the nature of the software design and therefore intentional?
Regarding the visibility: If you certify after opening or closing the advanced options, the visibility is remembered, otherwise not.
More or less consistently in all of Kleopatra we remember the current settings only if the operation was completed (whether successfully or with an error doesn't matter). If the operation/dialog was canceled then we do not remember the current settings. I'm not sure whether this approach is good. Sometimes I wished the settings were also remembered when I cancel the operation, but testing my own changes is a very different use case than actually using the software.
I think cancel should not save the settings. A case of "uuuh I clicked something wrong and now I am confused" -> "Cancel" -> "Phew everything back to normal". Is more valid then just looking around, canceling and then coming back later and expecing the same state. I would say this resolved.
ok, done for now.
(But I think we should in general not tie the changing of settings to operations. Those are independent things in my view.)
We don't change settings. We just remember what the user used the last time. That we save this information in the same file as settings doesn't make them settings. (It might be more correct to save last used keys/options in the state file where window sizes are saved since some time to better separate this information from actual settings.)
For me it is like if you open a save file dialog. You want it to remember where you saved a file the last time you saved it. But if you just browse around and cancel it, it should not store that location.
because I did not test with gpg4win yet. And I'm not familiar enough with the code base to say that it does not need to be testet with 2.4 again. Feel free to close it and move to done in the gpgcom workboard if you think its resolved for good.
And as I'm commenting anyway ok, then I'll add my 2 cents again:
a) its nothing like the save dialog that is totally unrelated
b) the save file case is debatable, too.
This is very much unrelated to any GnuPG code so I can say this is resolved for Gpg4win, too.