Questions about porting away from kdeui classes

[Иван Комиссаров]

I started some work in my local repo.

I started from QtColorButton (from QtDesigner/QtCreator)

Why KColorButton (
http://api.kde.org/4.x-api/kdelibs-apidocs/kdeui/html/classKColorButton.html)
needs defaultColor property? What are usecases? It can be emulated checking
for button->color()->isValid(), isn't it?

Should button draw text/icon over the color rectangle? (KColorButton has
properties inherited from QAbstractButon, but they don't work for
KColorButton)

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)

2012/7/2 Mark <markg85 at gmail.com>

> On Mon, Jul 2, 2012 at 8:47 AM, David Faure <faure at kde.org> wrote:
> > On Sunday 01 July 2012 16:24:51 Mark wrote:
> >> On Sun, Jul 1, 2012 at 3:36 PM, David Faure <faure at kde.org> wrote:
> >> > On Sunday 01 July 2012 14:07:15 Mark wrote:
> >> >> On a related note for KCompletion vs QCompleter.
> >> >> I don't think the two should merge.
> >> >
> >> > I agree :)
> >> >
> >> >> QCompleter is very UI orientated
> >> >> and really meant to hook on to a input field.
> >> >> KCompletion is much more basic, it simply completes the data that's
> >> >> fed into with the string that's being searched for.
> >> >
> >> > Right but it's mostly useful in a widget, in the end...
> >>
> >> Currently, yes. However, QML doesn't have any forms of completion at
> >> this moment and that would really be useful in some cases. This is
> >> where KCompletion has a lot more value then QCompleter.
> >
> > Right. That would be a good argument for getting a new completion
> framework
> > into Qt, which would also address KDE's needs.
> >
> >> Yep. First thing would be cleaning up the KCompletion API anyway at
> >> which point the cleaned up API moves to KF5 or Qt 5.x
> >
> > We cannot move old code from KDE to Qt.
> > Mainly because of the licensing issues (past contributors didn't sign
> the Qt
> > CLA), but also because APIs in Qt are usually different (more often value
> > based, etc.), and the implementation itself, well, could benefit from a
> > rewrite.
> >
> > But yes, just like I did with QStandardPaths, QMimeType and others, the
> > solution is to write clean Qt code from scratch and put that into Qt.
> >
> > The good thing compared to before OpenGov is that, even if we don't have
> time
> > to do it now, we can at least monitor the Qt development list in order to
> > react and give input if anyone starts working on a new completion
> framework
> > for QtGui...
> >
> > --
> > David Faure, faure at kde.org, http://www.davidfaure.fr
> > Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5
> >
>
> Sounds like a nice GSoC project for 2013 :) (if we can wait that long)
> _______________________________________________
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20120703/4bd02663/attachment.html>