<html>
 <body>
  <div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
   <table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 solid;">
    <tr>
     <td>
      This is an automatically generated e-mail. To reply, visit:
      <a href="http://git.reviewboard.kde.org/r/106569/">http://git.reviewboard.kde.org/r/106569/</a>
     </td>
    </tr>
   </table>
   <br />





<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
 <p style="margin-top: 0;">On September 25th, 2012, 9:03 p.m., <b>Frank Reininghaus</b> wrote:</p>
 <blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
  <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Thanks for analysing this issue and for the patch!

We should of course let those events propagate. However, I'm a bit confused. The docs of QObject::eventFilter() don't mention anything about setting the 'accepted' state of the event. If I understand it correctly, the event is filtered (i.e., not handled further) only if eventFilter() returns true.

Even if your patch fixes the issue, I'm therefore wondering if it just hides the real bug.

I think that what is actually supposed to happen is that DolphinView does not filter the event and that the KItemListView does not handle the event either, such that the unhandled event is passed through to the parent widgets until it ends up in the KonqCombo, such that KonqMainWindow::eventFilter() gets it, right? If that is true, I think the real bug might be that some class pretends to handle the event, such that its parents don't see it, although it does nothing with the event.

I had a quick look at the code and found that KItemListView::event() accepts the event and returns true if m_controller->processEvent() returns true, but does not ignore() the event if that is not the case. I haven't tested it yet, but maybe that is the real problem?</pre>
 </blockquote>




 <p>On September 25th, 2012, 9:13 p.m., <b>Thomas L├╝bking</b> wrote:</p>
 <blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
  <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Accepting the event means that it's not further propagated (to the parenting widget)
returning "true" in the event filter means to "eat" the event, ie. prevent regular handling in following eventfilters or even the widget event handling itself.

The patch will ensure that the (input, i assume) event goes up to the parent widget and is handled there if nothing else accepts it.
If you returned true, no further processing would happen at all (ie. even DolphinView::event() would process it)

You should btw. ensure that the parenting QScrollArea accepts it, or oxygen will get bugs because selecting items in dolphin will start to move the window ;-)

Disclaimer: i've not even seen the bug, just generally commented on question and the one-liner diff</pre>
 </blockquote>





 <p>On September 25th, 2012, 9:15 p.m., <b>Thomas L├╝bking</b> wrote:</p>
 <blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
  <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">PS: the actually more correct fix was to align to the Qt::WA_NoMousePropagation attribute and set it accordingly (allowing the usercode to manage the behavior this way)</pre>
 </blockquote>





 <p>On September 26th, 2012, 11:13 a.m., <b>Frank Reininghaus</b> wrote:</p>
 <blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
  <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Thanks Thomas for your message.

> Accepting the event means that it's not further propagated (to the parenting widget)
> returning "true" in the event filter means to "eat" the event, ie. prevent regular handling in following eventfilters or even the widget event handling itself.

Yes, that's just what I thought.

> The patch will ensure that the (input, i assume) event goes up to the parent widget and is handled there if nothing else accepts it.

Yes, but what I meant is that the patch ensures that by "ignore()'ing" the event in the wrong place. AFAIU, the eventFilter() should not mess around with the 'accepted' state of the event at all. I think the actual problem is that some event() method does not handle the event, but forgets to ignore() it.

> You should btw. ensure that the parenting QScrollArea accepts it, or oxygen will get bugs because selecting items in dolphin will start to move the window ;-)

Hm, but then I don't see how the key press should actually reach one of the parents inside Konqueror, but maybe I've misunderstood how Konqueror's Control+Tab feature actually works. Maybe I have to debug the path that the event takes step by step when I find some time.</pre>
 </blockquote>








</blockquote>

<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">No need because I can answer that question for you. The events reach inside Konqueror because Konqueror's view class (KonqView) installs an event filter on the widget of the part it embeds just like DolphinView does here. It does it so that it can intercept certain events just like DolphinView. 

Anyhow, none of that really matters because you are indeed correct. The culprit in this case is the KItemListView::event function. In order to allow the event propagation up the chain, it should call event->ignore() when it does not consume events just like it calls event->accept() for the events it does. Simply returning true or false is not enough for the events to be sent up the chain for the reasons already discussed above. I will update the patch accordingly. </pre>
<br />








<p>- Dawit</p>


<br />
<p>On September 25th, 2012, 3:38 p.m., Dawit Alemayehu wrote:</p>






<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('http://git.reviewboard.kde.org/media/rb/images/review_request_box_top_bg.png'); background-position: left top; background-repeat: repeat-x; border: 1px black solid;">
 <tr>
  <td>

<div>Review request for Dolphin and KDE Base Apps.</div>
<div>By Dawit Alemayehu.</div>


<p style="color: grey;"><i>Updated Sept. 25, 2012, 3:38 p.m.</i></p>






<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
 <table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
 <tr>
  <td>
   <pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">This patch fixes a bug where pressing CTRL+Tab does not switch tabs when active tab in Konqueror is a Dolphin's filemanagement part. It happens because DolphinView installs an event filter and does not call event->ignore() or event->setAccepted(false) to allow those events to be propagated up the event chain.</pre>
  </td>
 </tr>
</table>




<div style="margin-top: 1.5em;">
 <b style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Bugs: </b>


 <a href="http://bugs.kde.org/show_bug.cgi?id=302329">302329</a>


</div>


<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">

 <li>dolphin/src/views/dolphinview.cpp <span style="color: grey">(0584972)</span></li>

</ul>

<p><a href="http://git.reviewboard.kde.org/r/106569/diff/" style="margin-left: 3em;">View Diff</a></p>




  </td>
 </tr>
</table>








  </div>
 </body>
</html>