Package: libkdeui5 Version: 4:4.14.2-4 Severity: important Tags: patch While testing the new kontact, we found a bug in kdeui, that makes randomly crash kmail,kaddressbook while starting. We created an patch [0] to solve this problem. It would be great if that patch can be part of the stable relase of debian. For us it would make our life easier to to ship kdelibs on our own.
If there is anything I can do making this patch entering debian, please give me feedback. Regads, sandro [0] https://github.com/kolab-groupware/kdelibs/commit/42bd1a3e7af9d896c5c3f697a23bd7ed0b2314b8 The git commit message: The model was not working properly and didn't include all items under some circumstances. This patch fixes the following scenarios in particular: * The change in sourceDataChanged is required to fix the shortcut condition. The idea is that if the parent is already part of the model (it must be if acceptRow returns true), we can directly invoke dataChanged on the parent, resulting in the changed index getting reevaluated. However, because the recursive filterAcceptsRow version was used the shortcut was also used when only the current index matches the filter and the parent index is in fact not yet in the model. In this case we failed to call dataChanged on the right index and thus the complete branch was never added to the model. * The change in refreshAscendantMapping is required to include indexes that were included by descendants. The intended way how this was supposed to work is that we traverse the tree upwards and find the last index that is not yet part of the model. We would then call dataChanged on that index causing it and its descendants to get reevaluated. However, acceptRow does not reflect wether an index is already in the model or not. Consider the following model: - A - B - C - D If C is include in the model by default but D not and A & B only gets included due to C, we have the following model: - A - B - C - D If we then call refreshAscendantsMapping on D it will not consider B as already being part of the model. This results in the toplevel index A being considered lastAscendant, and a call to dataChanged on A results in a reevaluation of A only, which is already in the model. Thus D never gets added to the model. Unfortunately there is no way to probe QSortFilterProxyModel for indexes that are already part of the model. Even the const mapFromSource internally creates a mapping when called, and thus instead of revealing indexes that are not yet part of the model, it silently creates a mapping (without issuing the relevant signals!). As the only possible workaround we have to issues dataChanged for all ancestors which is ignored for indexes that are not yet mapped, and results in a rowsInserted signal for the correct indexes. It also results in superfluous dataChanged signals, since we don't know when to stop, but at least we have a properly behaving model this way. -- Sandro Knauß Software Developer Kolab Systems AG Zürich, Switzerland e: kna...@kolabsys.com t: +41 43 501 66 91 w: http://kolabsys.com pgp: CE81539E Sandro Knauß
signature.asc
Description: This is a digitally signed message part.