On Thu, 12 Dec 2002 09:37:13 +0100 Xavier Nodet <[EMAIL PROTECTED]> wrote:
XN> Actually, I am now able to verify PGP/MIME signatures... But this is not XN> nice at all: I pop-up a warning to display the results, Normally you should insert a PGPClickable into the viewer just as the view filter does. How to do it withotu duplicating the code is a good question however. XN> and I do not check the PGP button in the viewer bar. This button will almost certainly disappear so don't worry too much because of this. XN> I believe we should have a much better way to show those signature XN> verifications. One thing in particular, is that it should be very clear XN> which parts of the message were actually signed. I was thinking to XN> something like 'boxing' the signed part: It would be nice but I don't really know how to do it... Of course, we can have the pure virtual StartBox()/EndBox() in the viewer class -- this doesn't cost much. But how to implement them? XN> This seems to me particularly important for MIME messages: attachements XN> can be signed or not: this should be prominent. We could include the list of signed message parts in the "details" window of the PGP signature. XN> The problem is that there are two very different parts of the program XN> that deal with signature verification: MIME parsing, and text display. Yes but this is because PGP can be used in 2 so different ways :-( The only alternative that I see would be to unify MIME parsing and text display but I'm far from sure that this is a good idea. So for now I can only propose to extract the common code somewhere and reuse it from both places. XN> > One point I'm absolutely sure about is that it [the PGPEngine XN> > instance] should be created on demand only (i.e. there should be XN> > GetPGPEngine() somewhere which would create it when it's called for XN> > the first time). XN> XN> I am not against that, but why do you insist on creating on demand? It XN> is not so heavy a class, is it? It might be not or it might be, but M startup time is already quite long and it shouldn't become any longer -- especially if it is to initialize some feature which the user has all chances of not even suspecting about (not everyone uses PGP). Basicly, a big number of classes with small overhead still adds up to a lot -- so the only way to keep adding new features without annoying the user with ever longer startup times is to make sure that there is no overhead at all. XN> > The only problem I see is that I don't know when should it be XN> > deleted... XN> XN> I guess there are two cases: when options are saved and the user chose XN> not to load this module, or when the program is closed. No? Yes, you're right (except that I didn't even think about the first case) but the problem is rather how to do it, not when. Someone has to delete this pointer... Of course we can simply insert one line in MApp::Shutdown() and forget about it but it would be nice to have a more generic way of dealing with this. Regards, VZ ------------------------------------------------------- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ _______________________________________________ Mahogany-Developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mahogany-developers
