[Differential] [Commented On] D2423: Set initial categories for non-cached incidences

dkurz (Denis Kurz) noreply at phabricator.kde.org
Mon Aug 15 18:19:57 BST 2016


dkurz added a comment.


  In https://phabricator.kde.org/D2423#45545, @knauss wrote:
  
  > We also did this on kolab branches already:
  >
  > https://git.kolab.org/rKPbecae4738c14ef
  
  
  The categories to be checked can always be obtained from mLoadedInstance, so there's no need to pass them along with the job. I can't figure out from the "specifications" of Akonadi whether it is a good idea to use (if at all) the plain category name as the tag's global ID. According to README.md in kde:akonadi, the global ID has some kind of meaning for some items or tags, but I can't figure out what it is. There are already tags around that have random GIDs. Having some tags with GID == name and some with GID != name does not seem an optimal solution to me. Also, having the name of a category twice per tag in the Akonadi DB might leed to problems later.
  
  The above patch applies the TagFetch changes also to the TagSelectionDialog. This is only reasonable if we assume that one clicks on the "..." button before the TagWidget has completed the creation of the missing tags. But then the missing tags would be created by both the TagWidget and the TagSelectionDialog.
  
  Maybe we should block the TagSelectionDialog (by disabling the "..." button?) until all necessary tags exist? At any rate, I think this should be addressed in another patch.
  
  > https://git.kolab.org/rKPea164d5531331
  
  This assumes that GID == category name in some cases, see above.
  
  > https://git.kolab.org/rKP5928ec8451f24
  
  I think this is more related to the category color problem than to this patch, doesn't it? I will try to address this later, but not as part of this patch.
  
  > https://git.kolab.org/rKP136b203127db2
  
  I think I also fixed this issue, although by accident because I didn't know that onTagsReceived never happens if there are no tags to fetch.
  
  Maybe the mCategoriesToCheck approach can be made to be more robust than my approach. My code does not recover from failed TagCreateJobs at all. I'll try to fix that.

REPOSITORY
  rINCIDENCEEDITOR PIM: Incidence Editor

REVISION DETAIL
  https://phabricator.kde.org/D2423

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: dkurz, #kde_pim
Cc: knauss, kde-pim, spencerb, dvasin, winterz, smartins, vkrause, mlaurent, dvratil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20160815/37a8cd1f/attachment.html>


More information about the kde-pim mailing list