Bug 199975

Summary: Issues in Album view on Windows
Product: digikam Reporter: David Eriksson <meldavid>
Component: Albums-MainViewAssignee: Digikam Developers <digikam-bugs-null>
Severity: normal CC: anantapalani, caulier.gilles, Julien, marcel.wiesweg, mike, pietras.sp
Priority: NOR    
Version: 1.0.0   
Target Milestone: ---   
Platform: Microsoft Windows   
OS: Microsoft Windows   
Latest Commit: Version Fixed In: 4.0.0
Attachments: Screenshot of border debugging

Description David Eriksson 2009-07-13 09:25:16 UTC
Version:           1.0.0-beta3 (using 4.2.3 (KDE 4.2.3), MinGW 3.4.5)
Compiler:          gcc.exe
OS:                Microsoft Windows (i686) release 5.1 (XP Professional)

When hovering the mouse over a picture a blue border appears around the picture, I guess to indicate that this is the picture under the mouse. This blue border does however not disappear when the mouse is moved to another picture so after moving the mouse around all images have this border. All border disappear when I do something else like select one image or scroll up or down until all blue borders are of screen.
Single click on an image does not trigger the view/edit action as before. Instead I have to double click to trigger the action.
Non of this issues are there when I run the same version under Ubuntu.
Comment 1 Marcel Wiesweg 2009-11-29 16:06:58 UTC
Someone showed me this staying-border problem during the coding sprint, so I guess it's still around. But I cannot reproduce this. So is anyone present who can reproduce this problem and is willing to compile with a few debug patches added?

The single vs. double click behavior is controlled by Qt and determined by system settings.
Comment 2 Andi Clemens 2009-11-29 16:12:47 UTC
I can confirm this for WindowsXP: Borders stay "open", click behavior is broken, but this is a more general problem, because in Linux it is the same.
If you set Linux / KDE to have double-click behavior, the image can still be closed with a single click, but it will only show with a double click (very inconsistent).
Comment 3 Michael G. Hansen 2009-11-29 16:19:25 UTC
I have two user accounts on my system, a regular one and a testuser. The testuser does not have the staying-border-problem, but the regular one does. I do not know exactly where their system settings are different, though...

Qt 4.5.3, KDE 4.3.2

Comment 4 Michael G. Hansen 2009-11-29 16:20:22 UTC
Forgot to mention that this is on linux...
Comment 5 Marcel Wiesweg 2009-11-30 20:04:21 UTC
The code drawing this border is located in imagedelegate.cpp, line 378:
if (option.state & QStyle::State_MouseOver) { ...

There is also a similar code block above (371) which is probably never used.
I see these possibilities: Either the item is not redrawn when the mouse leaves, or the 371-code block is used, why ever. Or the MouseOver flag is erroneously set.
It's a bit difficult to debug because the method is called for every QModelIndex and for each redraw, so quite often. You could use debug messages restricted to when a certain model index (e.g. row=0) is painted.
There is ImageDelegate::mouseMoved to get info about where the mouse is.
Comment 6 Michael G. Hansen 2009-11-30 23:15:25 UTC
Created attachment 38728 [details]
Screenshot of border debugging

Ok, this is how far I got:

if (option.state & QStyle::State_MouseOver)
    r = d->rect;
    p->setPen(QPen(option.palette.color(QPalette::Highlight), 3, Qt::SolidLine));
    p->drawRect(1, 1, r.width()-3, r.height()-3);
} else
    kDebug()<<"NOT mouseover!!!";
    r = d->rect;
    p->setPen(QPen(Qt::green, 3, Qt::SolidLine));
    p->drawRect(1, 1, r.width()-3, r.height()-3);

With this code, all items are black with a green border by default (middle icon). Mouse over the icon on the left and over the one on the right in the screenshot -> it gets a blue border, debug output "mouseover". Move mouse away -> debug output "NOT mouseover", but the blue border stays, and you can see that the black brush is clipped to where the overlays are located, therefore the border was not erased...

The black artefacts around the green border are drawn at the beginning of the function with a width of 5, and also don't erase the background of the blue border...

Now execute the same code under a user account where the staying-border-problem does not occur, and there is no clipping, the black brush covers the entire inside of the green border when the mouse is moved away.

So, how do we proceed?

Marcel: The State_HasFocus branch is executed when an item has been selected with the mouse.

Comment 7 Marcel Wiesweg 2009-12-01 21:02:51 UTC
Is the differing behavior dependent of digikam config (copying over the digikamrc, with backup ;-) ?)

Can you check the painter's clipRegion(), maybe the current painting is not executed because it's clipped?
The area to be painted is given by option.rect, is this one correct?

The overlays are little widgets themselves, repositioned each time a new item is entered. That will explain why their region stays black, though I'm unsure about the exact mechanism.
Comment 8 Michael G. Hansen 2009-12-03 21:47:03 UTC

copying the digikamrc does not work for me, I always get the Configuration Wizard of Digikam when I try it.

Clipping: QRegion(size=0), bounds = QRect(0,0 0x0)
The options.rect is okay.

Another oddity: If I block the installation of overlays in ImageDelegate::installOverlay, the testuser (without the staying borders problem) still works okay (without overlays), but for the regular user the mouseMove events do not lead to a repainting of the delegate (no debug messages from the ImageDelegate::paint function). Therefore I guess that whatever should trigger a repaint of the ImageDelegate on mouse moves is somehow broken there, but I could not figure it out.

Comment 9 Marcel Wiesweg 2009-12-04 12:37:07 UTC
When copying the digikamrc you need to adjust the "Database File Path" setting. All other settings should not make the first-run wizard appear.
(That's my first approach: If this is settings dependent, we can isolate which setting is the problem)

The second question: When the mouse is moved away, is ImageDelegate::paint() called but with no effect, or is it not called at all?
Make sure, when testing with more than one item in the view, to include the index's row() in the debug output to identify.
If it's not called at all, the next level to check will be KCategorizedView::paintEvent().
Comment 10 Michael G. Hansen 2009-12-05 15:21:33 UTC
The staying-borders problem appears to be caused by the 'Plastique' style. If I start KDE for a fresh user, the staying-borders problem is not there. Then I change the widget style from Oxygen to 'Plastique' in the System Settings and the staying-borders problem is there.

Marcel, can you reproduce this?

Comment 11 Marcel Wiesweg 2009-12-05 16:05:53 UTC
Yes that's it! Absolutely reproducable.
Comment 12 Marcel Wiesweg 2009-12-05 16:36:31 UTC
So to me it appears that when digikam is started with Plastique as style (changing while running may not show the effect), any paint operation on the view's viewport, done on an item after the mouse moved away from this item, is reverted (*).

(*) I say reverted because on areas covered by transparent widgets, the effect of the paint operation is visible.

Is Plastique coming from KDE or Qt? Should we change the component of this bug?
If painting works with default styles but reproducibly not with a certain one, I would assume a problem with this style.
Comment 13 Andi Clemens 2009-12-05 16:42:53 UTC
I can see painting issues in IconView for every style and theme in Linux, too.
Just change the theme (from Default to Dark for example) and watch the iconview. It is not updated correctly, only when hovering over the items in the iconview.
I need to close the current album and switch to another to make the iconview refresh its style.
Comment 14 Andi Clemens 2009-12-05 16:43:17 UTC
So I guess it is more of a general problem in the iconview?
Comment 15 Marcel Wiesweg 2009-12-06 16:33:51 UTC
I just see a missing redraw. All newly painted items will be drawn with the new theme. Probably easy to fix.
Out themes are not the problem here - it's an issue with a specific QStyle.
Comment 16 Marcel Wiesweg 2009-12-19 16:31:25 UTC
*** Bug 212108 has been marked as a duplicate of this bug. ***
Comment 17 Julien Narboux 2010-12-30 09:09:06 UTC
Can someone reproduce this bug with 1.7.0 ?

Comment 18 caulier.gilles 2011-12-14 09:25:09 UTC

it still valid using digiKam 2.3.0 for windows ?

Gilles Caulier
Comment 19 Ananta Palani 2013-06-10 14:23:52 UTC
(In reply to comment #0)

David and Andi, can you still reproduce this with the new digiKam 3.1.0 release? Here is a link to the installer:
Comment 20 caulier.gilles 2013-11-08 15:17:17 UTC
I tried with digiKam 3.5.0 under windows, and problem is not reproducible. I close this file...

Gilles Caulier