On Sun, 2002-06-02 at 07:12, Not Zed wrote: > On Mon, 2002-06-03 at 02:19, Janus Christensen wrote: > > Hello, > > > > Evolution is a great piece of work and I use every day, but there are > > IMHO a few small UI problems with the GnuPG passphrase prompt. > > > > If I select "Cancel" on the passphrase prompt an error prompt pops up > > with this message: > > > > Cannot sign this message: no password provided > > > > Is this necessary? If I select "Cancel", it is because I do not want to > > send the message at this time, and the passphrase prompt should just > > fail silently. There is no need to tell me that the signing of the > > message has failed, since I did not wish to sign the message. > > I'll look into it, i was just playing with that code, i think it should > be fairly easy to fix. Could you create a bug on bugzilla.ximian.com > and assign it to [EMAIL PROTECTED] please?
Yea, this should be easy to do if I haven't fixed it already. If we make it so that hitting cancel on the passphrase prompt sets the USER_CANCEL exception, then it should just magically work. > > > > > When attempting to send a message without a subject, I get prompted > > with: > > > > "This message has no subject. Really send?" > > > > which is OK, except that this happens *after* I have to type the > > passphrase, which is annoying, since I then add a subject to the message > > and then reenter the passphrase. > > > > Of course, some choose having Evolution to remember the passphrase, when > > entering it the first time during a session, by setting the "Remember > > this password for the remainder of this session." checkbox in which case > > this would not pose a problem. I prefer having it not remember my > > passphrase, though. > > > > Any chance of the subject check coming before the passphrase request? > > This is a bit trickier - i think, because the checks are done in > different levels of code (i think). > > Actually its a bit odd too, because it shouldn't need to re-ask the > pass-phrase, since the subject isn't part of the signed content. > > Mention this in the bug, i'll at least check what the code does and how > easy it is to fix. I think that the dialog cancels the send and re-show's the composer, at which time the user enters a subject. The the user hits Send again. This means that the mailer code has to call e_msg_composer_build_message() or whatever to get the message to send. This means that everything has to be re-signed. I guess if we made the composer prompt for empty subjects, then it might be doable. Or... maybe the mailer code can check the contents of the subject entry field in the composer rather than checking the CamelMimeMessage->subject? Actually, I think this might be the better option. Jeff _______________________________________________ evolution maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution
