today's meeting notes

[Artur Duque de Souza]

Hi Marco,

On Monday 13 September 2010 16:10:54 Marco Martin wrote:
> now, maybe when qtcomponents will be ready it could be decided to just use
> those widgets, again if they will be good enough for the desktop.

That's what I'm trying to say: qt-components will probably never be "ready" as 
the conclusion of the project is that it's not worth it providing a widget set 
in QML. It's up to platform makers (this is where we enter with plasma 
*library*) to provide the widgets. Of course, qt-components may offer an 
implementation reference but it doesn't make sense to offer widgets as they 
differ from platform to platform and trying to do that is just a ton of hacks 
on top of other hacks (I say this from experience as we already tried to do 
so).

So don't expect a widget set that we can just "use" as we have today with 
QWidgets. Application developers can expect that, but platform developers 
don't. That's why if we may want to provide this in the future: so 
applications using libplasma (kdeui maybe) may use directly the "KDE widgets" 
without pain.

Summary: qt-components is not going to solve the problem for platform 
developers. They will need to write their widgets. Qt-components just show how 
to do in with less pain.

Another path is to just do the bindings, but they will not work 100%...if we 
don't create "false hopes" that everything is going to work it's fine :) 
(example, without 4.7.1 the qgw exported to QML just don't work on Flickable 
items - nobody is maintaining this so regressions can also be expected).
 
> Or alternatively we can also decide that we really need to wait for them ad
> delay the complete bindings at this point, but wouldn't seem a particularly
> wise move for me, also because would basically mean plasma mobile not
> happening.

I'm not saying that we choose one or another. My point is: we can do something 
(bindings) for the short term, but for long term we should start thinking 
about doing it as it's expected. Also to avoid headaches for us :) From my 
point of view it's not orthogonal: either bindings or proper components. From 
my point of view we can use the bindings for short term (4.6) and should start 
thinking about components for the long term.

> until then, a solution already is in there, judging from a couple of pretty
> complex uis i did with it, works quite good, so i don't much see the point
> of all of this discussion, because the real problem is one and completely
> unrelated: the use of the private class for dataengine bindings.

The point of the discussion is just that you got a sentence out of context and 
is thinking that I'm arguing that is either one or another. My options are not 
exclusive - just the opposite: I think we should go for both.

For the use of private classes on dataengine bindings: also don't expect for 
4.7 the export of classes...it may happen on 4.8 but no idea when it's going 
out :P So we need to think together about a way of getting rid of it. Which 
private classes are being used?

> as far i see from the sources a caching seems involved
> (qdeclarativepixmapcache), but looks like only memory and no svg renderer
> sharing, i could be wrong.

I would need to check too. Don't remember about this....

> it is also not possible to have a borderimage that gets elements of an svg
> with a certain prefix, it only gets the whole image, all of this it would
> make impossible to use current themes, in brief break compatibility of wat
> there is already in.

Ok. This justifies the creation of a declarative item that has proper support 
for our svgs.

Cheers,

-- 
-------------------------------------------------------
Artur Duque de Souza - MoRpHeUz
-------------------------------------------------------
http://claimid.com/morpheuz
Blog: http://blog.morpheuz.cc
PGP: 0xDBEEAAC3 @ wwwkeys.pgp.net
-------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20100913/770dc02d/attachment-0001.sig