
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd"><html><head><meta name="qrichtext" content="1" /><style type="text/css">p, li { white-space: pre-wrap; }</style></head><body style=" font-family:'Arial'; font-size:9pt; font-weight:400; font-style:normal;">> I can confirm, seems to be some race-condition.<br>

> If you switch to another album, no image is actually selected. Look at the<br>

> edit action in the toolbar for example, it is disabled.<br>

> When you just rightclick on an item, it becomes selected (edit action in<br>

> toolbar is active now), but somehow the context menu has already been<br>

> created. Right-clicking the item again "fixes" the menu.<br>

> The ContextMenuHelper normally removed disabled actions, to avoid an even<br>

> bigger contextmenu. This is why some actions are not displayed.<br>

><br>

> The actions are enabled in DigikamApp::slotImageSelected(), but the slot<br>

> seems to be called slightly after the contextmenu is created.<br>

><br>

> I guess we had this problem also before the ModelView port, but since I<br>

> always click first on an item, I've never seen it.<br>

<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>There is a timer to compress selection signals in DigikamView, so you are quite right, DigikamView::slotDispatchImageSelected is called in the event loop after the context menu event has been received.<br>

If this worked before, there was a good solution; if it never worked, we need to think about a new solution. Anyone has an old version, maybe 0.10 installed to quickly test?</p></body></html>