today's meeting notes

[Marco Martin]

On Monday 13 September 2010, Artur Duque de Souza wrote:
> 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
> [...]
> 
> 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.

ah, that's interesting.
i understood that they were supoposed to have a part with the logic and a 
separate qml file for the styling that would have been platform specific?
i should check what code there is in at the moment ;)

> 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).

yeah, it will be a bit painful at start but the only short term way.
in that particular case events get stolen, so they need a mousearea on top of 
it or to be in a plasma flickable widget, all of that needs to be documented.

> > 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

yeah, that is what i was trying to say :)
if we want to have something quickly what we have now needs to be used.
i agree in the long term things should be done in a proper way.
(for an hypotethic kde5 we could have just those, even)

> 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.

yes, exactly, i misunderstood that part :)
to me a distinct short and long term plans should be in place

> 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?

it's qdeclarativeopenmetaobject (that drags in also qdeclarativerefcount and 
the private of qobject)

i think options are basically 2:
- try to write something simple that doesn't use qdeclarativeopenmetaobject 
that could be even a bit overkill for it, will try today
- keep an internal copy of all the thing if it's likely to be exported in 
future versions

> > 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.

i'll try that shortly as well.
i think those should be exported a Svg and FrameSvg since exporting directly 
thise classes doesn't make sense (they just offer a qpainter, so couldn't be 
used at all)

Cheers,
Marco Martin