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 _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel