KDE PIM/Meetings/KDE PIM at Akademy 2020: Difference between revisions
(Created page with "Notes from KDE PIM BoF at Akademy 2020 on the Internet == Notes == * EteSync resource GSoC project was merged yesterday \o/ * André reporting on GnuPG/Kleopatra activitie...") |
m (→Notes) |
||
| Line 35: | Line 35: | ||
* kdepim-addons structure | * kdepim-addons structure | ||
** there shouldn't be any mandator or essential things in there | ** there shouldn't be any mandator or essential things in there | ||
* KAsync | |||
** Dan is reworking it, first for use inside Akonadi, and when it holds up there, for inclusion into KF | |||
** Depends on C++17, but doable as it's header-only | |||
Revision as of 17:43, 8 September 2020
Notes from KDE PIM BoF at Akademy 2020 on the Internet
Notes
- EteSync resource GSoC project was merged yesterday \o/
- André reporting on GnuPG/Kleopatra activities
- https://dot.kde.org/2020/02/18/gpg4kde-gpg4win-approved-transmission-processing-national-classified-information - VS-NfD certification achieved last year \o/
- Ingo working on better smart card support for Kleopatra (which includes USB-based password tokens like the Yubikey/etc)
- Android work and framework split also helped Windows deployments for Gpg4Win
- State of Kontact on Windows
- largely unknown
- we know Akonadi works though, via FatCRM (built on AppVeyor using Craft)
- we know Kontact works on WSL, via Till
- André suggests the Enigmail drop in Thunderbird might be an opportunity to reach Windows-based crypto-nerd users
- gpgme(++) build on Windows is an issue, due to its autotools build system, can possibly be addressed by adding a CMake build system upstream, in collaboration with André
- Library and dependency cleanup efforts
- there has been some progress on removing kdepim-apps-libs
- kab import/export move was stuck during Gitlab transition, Dan/Luigi will continue this now
- remaining: kab grantlee integration: can this go to akonadi-contact
- libkdepim: some stuff has been moved, to other modules or KF, more to do
- KDAV moved to KF
- should we have a dedicated sprint on this? -> yes, for doing the analysis and planning, later this year, David volunteers to join
- are we ok with applications installing their own plugin interfaces, or should those be split into separate repos? e.g. kontactinterface vs kontact, or the interfaces for the other plugins in kdepim-addons
- Pro: easier dependency tree
- Con: pulls in more stuff for building
- we agreed this is ok
- kdepim-addons structure
- there shouldn't be any mandator or essential things in there
- KAsync
- Dan is reworking it, first for use inside Akonadi, and when it holds up there, for inclusion into KF
- Depends on C++17, but doable as it's header-only