I started some work in my local repo.<br><br>I started from QtColorButton (from QtDesigner/QtCreator)<br><br>Why KColorButton (<a href="http://api.kde.org/4.x-api/kdelibs-apidocs/kdeui/html/classKColorButton.html">http://api.kde.org/4.x-api/kdelibs-apidocs/kdeui/html/classKColorButton.html</a>) needs defaultColor property? What are usecases? It can be emulated checking for button->color()->isValid(), isn't it?<br>
<br>Should button draw text/icon over the color rectangle? (KColorButton has properties inherited from QAbstractButon, but they don't work for KColorButton)<br><br>QtColorButton is able to d'n'd text from/to the button. I added bool prop to disable d'n'd (bool dragDropEnabled). Is it needed? (pros - if app doen't have d'n'd support it is strange that one single button have this support. More, why we need to allow d'n'd in case if there's no other buttons (and no widgets to drop color. Cons are minor - it just another property)<br>
<br><div class="gmail_quote">2012/7/2 Mark <span dir="ltr"><<a href="mailto:markg85@gmail.com" target="_blank">markg85@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On Mon, Jul 2, 2012 at 8:47 AM, David Faure <<a href="mailto:faure@kde.org">faure@kde.org</a>> wrote:<br>
> On Sunday 01 July 2012 16:24:51 Mark wrote:<br>
>> On Sun, Jul 1, 2012 at 3:36 PM, David Faure <<a href="mailto:faure@kde.org">faure@kde.org</a>> wrote:<br>
>> > On Sunday 01 July 2012 14:07:15 Mark wrote:<br>
>> >> On a related note for KCompletion vs QCompleter.<br>
>> >> I don't think the two should merge.<br>
>> ><br>
>> > I agree :)<br>
>> ><br>
>> >> QCompleter is very UI orientated<br>
>> >> and really meant to hook on to a input field.<br>
>> >> KCompletion is much more basic, it simply completes the data that's<br>
>> >> fed into with the string that's being searched for.<br>
>> ><br>
>> > Right but it's mostly useful in a widget, in the end...<br>
>><br>
>> Currently, yes. However, QML doesn't have any forms of completion at<br>
>> this moment and that would really be useful in some cases. This is<br>
>> where KCompletion has a lot more value then QCompleter.<br>
><br>
> Right. That would be a good argument for getting a new completion framework<br>
> into Qt, which would also address KDE's needs.<br>
><br>
>> Yep. First thing would be cleaning up the KCompletion API anyway at<br>
>> which point the cleaned up API moves to KF5 or Qt 5.x<br>
><br>
> We cannot move old code from KDE to Qt.<br>
> Mainly because of the licensing issues (past contributors didn't sign the Qt<br>
> CLA), but also because APIs in Qt are usually different (more often value<br>
> based, etc.), and the implementation itself, well, could benefit from a<br>
> rewrite.<br>
><br>
> But yes, just like I did with QStandardPaths, QMimeType and others, the<br>
> solution is to write clean Qt code from scratch and put that into Qt.<br>
><br>
> The good thing compared to before OpenGov is that, even if we don't have time<br>
> to do it now, we can at least monitor the Qt development list in order to<br>
> react and give input if anyone starts working on a new completion framework<br>
> for QtGui...<br>
><br>
> --<br>
> David Faure, <a href="mailto:faure@kde.org">faure@kde.org</a>, <a href="http://www.davidfaure.fr" target="_blank">http://www.davidfaure.fr</a><br>
> Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5<br>
><br>
<br>
</div></div>Sounds like a nice GSoC project for 2013 :) (if we can wait that long)<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
Kde-frameworks-devel mailing list<br>
<a href="mailto:Kde-frameworks-devel@kde.org">Kde-frameworks-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/kde-frameworks-devel" target="_blank">https://mail.kde.org/mailman/listinfo/kde-frameworks-devel</a><br>
</div></div></blockquote></div><br>