today's meeting notes

[Marco Martin]

On Monday 13 September 2010, Artur de Souza wrote:
> Quoting Marco Martin <notmart at gmail.com>:
> > 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)
> 
> Yes, layouting and a lot of other things that are not working well
> with qgw. Alexis did a really amazing job on this when he was working
> with QML but this is no longer maintained and keeping the hope that
> it's going to work is just "false hope" unfortunately :(.

yes, the binding for layouts is in plasma sources directly.
now i'm not sure if it's less painful using qgws with the qml anchors (yes, it 
does work, the root element has to have an hardcoded size tough) or relying on 
the layout bindings fork, but, even if our widget are going to be redone in 
the future (yes i know what will happen to qgraphicsview) redoing it right now 
means:
- it's not going to be done for 4.6 (or even 4.7 or 4.8)
- while could be almost perfect(tm) for the mobile case it's not going to be 
good enough for the desktop, because they are going to behave slightly 
different from the other widgets, even if they are mimicking the other ones. 
for instance text areas won't have context menus (i don't think it's possible 
at all in qml?) pushbuttons won't have the exact same behaviour and 
capabilites, to reimplement the pushbutton/toggebutton/toolbutton/button with 
menu is going to be a big amount of work.
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.

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.

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 problem with creating qdi based ones is that we can suffer of the
> proxy->proxy problem. The KDE-pim guys tried this and it just made
> things worse. To properly do this you almost have to duplicate what
> qgraphicsproxywidget does. So, it's really easier to just change the
> way we do widgets. It has been some months now that we tried different
> approaches and going a step back will allow us to go two further later,
> 
> > 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
> 
> This may be needed, but I thought that svg was supported on qml already...
> 
some considerations about technical minutiae of svg/framesvg vs 
image/borderimage:

yep, it does, Image and BorderImage can have a svg as source
tough there again i'm not sure either the right approach is done or is done 
the one good for us.
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.

it is not possible to access to sub elements, so no rendering of a single 
eleent or checking for the hint elements (thats all out of scope for the svg 
rendering of qml i think, so i don't think it would even make sense trying of 
making qml svg support more sofisticate)

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.


Cheers,
Marco Martin