-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 30 October 2001 20:06, Karl-Heinz Zimmer wrote: > On Tuesday 30 October 2001 20:29, Marc Mutz wrote: > > On Tuesday 30 October 2001 09:53, Karl-Heinz Zimmer wrote: > Things will be different: KMail will have the "Plug-In Container" > embedded as _integral_ part, it will not 'load' that. I'm looking forward to your proposal here, since I really can't think of what this should be... > > But reading mua-interation.sgml, I get the feeling that you want > > to build a generic Sphinx plugin (shared lib), which contains > > both cryptographic base functionality (in the form of - roughly > > - gpgme 0.23?) _and_ GUI elements (which are respresented in > > xml form???). > > You got it. Of course our Plug-In will not be a monolitic bloc > but consist of several parts that will be taken care of by the > main Plug-In module... My main concern here is that the data/view separation I'm persueing with KMime and which is (IMO) badly needed for KMail is going to be blurred when the gpg plugin is about dialogs _and_ encrypting (e.g.). That's important, because KMime should (sorry ;-) be usable from applications without a GUI. > > Come on, that's nonsensical. > What I meant here was the creation of dialogs from XML data that the plugin outputs. Or so I understood mua-integration.sgml. I think it would be far more work to write an XML-to-dialog processor than it would be to make native dialogs with designer. For KDE, this might not really be the case, since Qt3 has this funky QWidgetFactory, which can do something like that, but for mutt? > As you surely can imagine I don't like your theory that our concept > is 'nonsensical'. We did think about that for _quite_ a while and > (at least in my not so humble opinion) it _does_ make sense. ;-) > Sorry for overreacting and strong words. I really only meant the XML-to-dialog processing... > > The Qt/KDE based dialogs can easily be created natively for > > 1. mail specific > > 2. generic > > functionality. Those should be > > ^^^^^^ > > > a. native dialogs > > b. two separate plugins (and plugins that are separated from the > > cryptographic core, ie. gpgme-as-is -now). > > Sorry, I don't agree to you. > > a) Frankly speaking: I do not accept your "should". > > I am not trying to tell you how you 'should' code your programs > and I hope you agree to grant me the same freedom, a "should" > does not help both of us. > Sorry again :-( Is "should" that stronger than German "sollte"? > (Details will be published > here in some days...) Looking forward :-) > > > This is our plan, don't you like it? :)) > > > > > > > > If this is all to be put into a single plugin, then no, I don't. > > I am sure the above mentioned details (no monolitic bloc, true KDE > dialogs...) will make things look better for you. :) Yes. :-) > Now for some more good news: Our own concept is not toooo far away > from your proposal (so I hope you will like it finally) as we will > build a very flexible solution where a Plug-In does not neccessarily > have to provide all functionality that the Gpg Plug-In does... > (again: Details to follow soon...) again: Looking forward :) Sorry again for overreacting. I just felt a little bit pressed to keep a steady pace with KMime so that we can use it, but I guess we should target KMime for KDE 3.1, due to lack of (testing) time. :-( So, you have only current KMail to take into account *sigh*. I'll buy you a drink next LinuxTag :-) Marc - -- Die sozialdemokratische Linke existiert nicht mehr. Es bleibt nur die Frage, durch wen sie ersetzt wird: Wir haben Bush, wir haben Sharon, Berlusconi... - eine ganze rechte Hegemonie, die keinen kümmert! -- Ken Loach -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE74HiE3oWD+L2/6DgRAkh2AJ9OYZPQdi9MKV0smutMqjf7tlXxUQCg+jlo 0XlDvqerCI02BqRUfXMrjgo= =9/Vl -----END PGP SIGNATURE----- _______________________________________________ kmail Developers mailing list kmail@mail.kde.org http://mail.kde.org/mailman/listinfo/kmail