On Monday 13 September 2010, Artur de Souza wrote: > Quoting Marco Martin <notm...@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 _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
