Processed: Re: Bug#775114: [libkdeui5] KRecursiveFilterProxyModel: The model was not working properly

2015-01-19 Thread Debian Bug Tracking System
Processing control commands:

 severity -1 grave
Bug #775114 [libkdeui5] [libkdeui5] KRecursiveFilterProxyModel: The model was 
not working properly
Severity set to 'grave' from 'important'

-- 
775114: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775114
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/handler.s.b775114.142168152821040.transcr...@bugs.debian.org



Bug#775114: [libkdeui5] KRecursiveFilterProxyModel: The model was not working properly

2015-01-19 Thread Sandro Knauß
control: severity -1 grave
thanks

This patch should be included as it fixes a critical bug in kdelibs which 
renders Kontact unable to show user data. The data is actually 
there, but not visible or accessible to the user, and therefore is often 
perceived as a data loss issue.

The patch itself is small (-11/+5 lines), contained entirely in private code 
in the affected library, and comes with a unit test to ensure quality.

There is a pending upstream review request to include it upstream which has 
gone unanswered thus far:

https://git.reviewboard.kde.org/r/120119/

We are unsure when it will land upstream due to this lack of attention to the 
request, but the bug it fixes continues to affect users.

So despite waiting for upstream response, it is already being packaged in 
Fedora packages as well as being shipped to large institutional users (at 
least one of which uses a Debian OS as the desktop client) by downstream 
companies such as Kolab Systems.

By including this well-tested and already deployed patch, Debian can ensure 
that users relying on Kontact working well (among other KDE applications which 
use this same functionality) will not need to go elsewhere (e.g. another 
downstream) for a patched version of the kdelibs package.

Regads,

sandro

-- 
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.


Bug#775114: [libkdeui5] KRecursiveFilterProxyModel: The model was not working properly

2015-01-11 Thread Sandro Knauß
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.