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 -------------------------------------------------------
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
