<br><br><div><span class="gmail_quote">On 10/28/07, <b class="gmail_sendername">Aaron J. Seigo</b> <<a href="mailto:aseigo@kde.org">aseigo@kde.org</a>> wrote:</span><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
hi...<br><br>right now when KConfigGroup can not store a type, such as a QRectF, it now<br>aborts with a kFatal().</blockquote><div><br class="webkit-block-placeholder"></div><div>looks like the code to write QRectF got lost somewhere, it reads them but doesn't write them? 
</div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">this seems a bit .... harsh. especially since it means *none* of the config<br>gets saved. this resulted in plasma not saving any of its config on exit due
<br>to one data type (QRectF) not being handled.<br><br>looking at the code, except for the line in writeConfig which could be easily<br>guarded with a return and resolve that issue, there would be no sideeffects<br>to just spitting out a warning and continuing on. only the offending entry or
<br>entries wouldn't be written out, rather than stopping the entire application<br>and dropping its configuration. that seems a bit overkill to me.<br><br>were there specific reasons for using kFatal that warrant keeping it that way?
</blockquote><div><br class="webkit-block-placeholder"></div><div>to find/fix cases like this, I'll get right on it, shouldn't take too long</div><div><br class="webkit-block-placeholder"></div><div>Thomas</div><div>
<br class="webkit-block-placeholder"></div></div>