<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/103909/">http://git.reviewboard.kde.org/r/103909/</a>
     </td>
    </tr>
   </table>
   <br />





 <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 Albert for looking at it. Not sure if I understand everything correctly, but what happens, when I have a subclass of Q/KComboBox, that does not have its own user property?

I am considering the following possible cases:

1) plain QComboBox
2) subclassed QComboBox without custom user property
3) subclassed QComboBox with custom user property
4) plain KComboBox
5) subclassed KComboBox without custom user property
6) subclassed KComboBox with custom user property (e.g. KColorCombo)

For 1) 2) 4) 5) it should ignore the new 4.8 user property, and use our custom code.
For 3) 6) it should respect the custom user property.

If I am following code paths correctly, the patch fails for cases 2) and 5). It does not find the class name in the map, falls back to user property (what Qt provides now since 4.8), and thus not handle our custom code.</pre>
 <br />







<p>- Christoph</p>


<br />
<p>On February 9th, 2012, 11:28 p.m., Albert Astals Cid 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 kdelibs, Ben Cooksley, Eike Hein, Christoph Feck, and Jeremy Paul Whiting.</div>
<div>By Albert Astals Cid.</div>


<p style="color: grey;"><i>Updated Feb. 9, 2012, 11:28 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;">https://git.reviewboard.kde.org/r/101486/ broke subclasses of QComboBox that have a USER property like KColorCombo, this patch reverts this change and introduces a different code path to ignore the USER property of QComboBox and KComboBox and make it use our custom code.</pre>
  </td>
 </tr>
</table>


<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing </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;">Ran the attached test, everything worked.

Without moving the
 userproperty = getUserProperty(w);
the KColorCombo fails

Without adding the 
 s_propertyMap->insert( "KComboBox", "" );
the editable KComboBox fails
</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=293702">293702</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>kdeui/tests/CMakeLists.txt <span style="color: grey">(63788f6)</span></li>

 <li>kdeui/tests/kconfigdialog_unittest.cpp <span style="color: grey">(PRE-CREATION)</span></li>

 <li>kdeui/dialogs/kconfigdialogmanager.cpp <span style="color: grey">(0890c0b)</span></li>

</ul>

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




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








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