today's meeting notes

[Marco Martin]

On Monday 13 September 2010, Artur de Souza wrote:
> Quoting Marco Martin <notmart at gmail.com>:
> > * QtComponents/ QML bindings
> > 
> >  - we need a timeframe for QtComponents, but i guess it will pass a
> > 
> > quite long
> > time before it makes it in a qt release
> > 
> >  - i think that for this reason bindings for the plasma widgets are still
> > 
> > needed, at worst the plasma widgets could get replaced by qml
> > counterparts with the exact set of properties
> 
> We need to talk about this during the mobile sprint :) The conclusions
> that are coming out from qt-components are showing that it's not worth
> it the bindings of the *widgets* (the other stuff I'm sure it's worth
> it - also to enable 'QML plasmoids'). Writing a QML version of our
> widgets would be easier and faster, and we would "just" need a bridge

well, not really faster, since the binding of the widgets is exactly the only 
part that right now is finished and working perfectly.
the problem as usual, is the layouting, bad interaction between the qgw based 
ones and qdi based ones, but at least is possible to obtain decent results 
using only, or almost only qgw based ones (i still fear the lack of a real 
layout system and size hints is going to bite really hard, especially on non-
mobile)

> between them and our theming stuff. Anyway, we can talk more about
> this on IRC and at the sprint :)

would probably just be needed a qdi subclass that can draw svg and framesvg, 
to be used in place of the rather ugly BorderImage. Theme colors are already 
binded

> >  - i would still like them to make it for 4.6, big issues remaining are
> >  the
> > 
> > use of a private qt class for dataengines (this really makes me cry) and
> > i18n (did kontact mobile solved that?) support for QIcons/KIcons would
> > be nice as well
> 
> Yep, Kontact Mobile solved this issues providing a bridge between the
> i18n() functions and also for the KIcon loading. It would be nice to
> reuse code. Otherwise it would be simple to do the same thing.

yes, i would like to see kdelibs related bindings in kdelibs itself some day

Cheers,
Marco Martin