https://bugs.kde.org/show_bug.cgi?id=261645


Szymon Stefanek <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[email protected]




--- Comment #8 from Szymon Stefanek <pragma kvirc net>  2011-04-18 23:40:19 ---
Unfortunately I no longer have the devel source tree set up so I can't test/fix
it directly. However the problems is exactly the one described in comment #5 by
Sergio. Filters and disconnected-UI jobs don't go together.

I agree that it's a bit messy. The key point for disconnected-UI was
performance. I'm not sure if this is still really needed as the Qt model-view
implementation has probably improved in the meantime. Some testing would be
needed.

However.

Disconnecting the UI means "not telling the model-view framework that single
items are being inserted" and later (when UI is reconnected) declaring
layoutChanged() at once. Filters, however, use QTreeView::setRowHidden() so the
view must be "aware" of the items being inside it.

Disconnected UI jobs are usually very short but they can still be interrupted:
inside Model::viewItemJobStepInternal() there is a path that returns control to
the event loop with mModelForItemFunctions left to 0. 

Two possible solutions:

- If a filter has to be applied when a disconnected UI job is running,
reconnect the UI (and remove the disconnected-UI flag from the job). This means
moving the UI reconnection code from Model::viewItemJobStepInternal() to its
own function and calling it in two places.

- Reconnect the UI as soon as a job with disconnected UI is interrupted (or
finishes, as it is now). This is simpler as it can be done entirely inside
Model::viewItemJobStepInternal() but it possibly reduces the performance a bit
(?).

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Kdepim-bugs mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/kdepim-bugs

Reply via email to