Hei, First of all: yes, there are new features, and lots of new strings. Read on, though.
Kleopatra is still being actively developed as part of the upcoming gpg4win v2.0 (www.gpg4win.org). Because of the (overly long, IMHO) feature and string freeze, some of the scheduled features and lots of usability improvements (all of which involve string changes, naturally) had to be done in enterprise4 branch. There are two facts to consider here: 1. Kleopatra/trunk is effectively unmaintained, and unusable. In a perfect world, we would have the resources to backport non-feature, non-string fixes, and to argue the case of every string change that we need to do. Sadly, we plain don't have the resources. Because of branch-off point was rather arbitrary, the Kleopatra that is in trunk is effectively unusable. I define unusable as "the customer rejected that state even for piloting" :) 2. Kleopatra/e4 is actively maintained, and externally QA'ed by at least three different stakeholders with high interest in stability and usability (Intevation, g10 code, customer). It isn't ready yet, though, and there /will/ be new strings and changes to existing strings up to beginning of July. But, it's usable (ie. it's being accepted for piloting by the customer). Given these two facts, and the rather long time before KDE 4.1.0 final, I would like to request merging back _all_ of Kleopatra from e4 to trunk, probably towards end of June. For KDE-Windows, there's a third thing to consider: 3. Kleopatra/e4 doesn't need gpgme-qt anymore. Kleo/e4 has been ported to use gpgme multithreaded, which gets rid of the kludge of having gpgme(-qt) link against Qt for event loop integration. This was a major pain for the kde-windows packagers, and this step was taken after consultation with a few of them on LinuxTag 2008. Truth be told, we're still fighting with problems related to this, e.g. keylistings hang on Unix (probably a gpg/sm/gpgme bug) quite often, but we're in the process of solving them together with g10 code. This also affects KMail. This is the main reason I don't ask for merging now and continuing development in trunk. For the translators, I should mention that in addition to new strings from kleopatra.po, there is a big update to Kleopatra's handbook in the pipeline, including screenshots. To summarize: If you agree to the merge, users will get a much more smooth, stable, and feature-complete Kleopatra, and a handbook that isn't hopelessly out of date. They might, however, depend on the latest gpgme and gnupg. If there are relevant bugfixes in there, that holds even for Unix. On OS X and esp. on Windows, the very latest version will be required in any case, but that's not surprising, as they're supported for the first time. The alternative is to disable Kleopatra in KDE 4.1, since I won't accept bug reports against an unusable prerelease version. But even though Kleopatra as an application isn't the most high-profile application in KDEPIM :), trunk libkleo would still force kde-windows to continue to deal with gpgme-qt. So, as a third alternative, we could merge gpgme++ (which is BIC, but not part of KDE, in fact, there's talk to host it inside gpgme svn), qgpgme and libkleo to get rid of gpgme-qt, and not merge Kleopatra (which means disabling it in trunk). This includes the dependency chain from the first alternative. Opinions? Thanks, Marc
pgpbtcglDekCe.pgp
Description: PGP signature
_______________________________________________ Kde-windows mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-windows
