Plasma QML documentation

[Aaron J. Seigo]

On Wednesday, June 22, 2011 11:25:10 Marco Martin wrote:
> On Wednesday 22 June 2011, Aaron J. Seigo wrote:
> > On Thursday, June 16, 2011 13:08:35 Marco Martin wrote:

> > > * binded qgraphicslayouts and old plasma widgets (i really do *not*
> > > want to publicize that thing...)
> > 
> > this can perhaps be linked to from a "legacy support" section on the
> > page, and point to just the widgets page split out from the JS API (see
> > below more more on the splitting)
> 
> yeah, a legacy support page would be good, probably the widgets would have
> to be different from the js page since you create them in a different way
> PushButton {
>   text: foo
> }
> vs
> button = new PushButton()

yes; it's easy enough to split out the widget API onto a separate page which 
both sets of documentation can point to.

> > > * qtextracomponents: they depend just from qt, but i would document
> > > them there (and yes i still am on the position that image providers
> > > cannot even remotely replace them :p)
> > 
> > where are QtExtraComponents shipped? Qt itself, or?
> 
> kde-runtime as well, are things that should really be in the base components
> but they have been really clear they don't want to implement, like elements
> to display qicons, qimages and qpixmaps

ok; going forward i don't think these belong in "runtime" .. i think you and i 
have slightly different opinions on this, but to me these are "libraries for 
QML" and while they are technically run-time dependencies (in that nothing 
links, in the C/C++ sense, to them) they are the equivalent of libraries for 
QML. i really think all of these QML bits belong in a Frameworks module of 
their own that can be used independently.

> > > * parts in common with the JS api (except services that are briefly
> > > talked about): they could be copied but would be harder to update
> > > since
> > > all work would have to be done 2 times: is enough to cross link the
> > > needed sections?
> > 
> > what we could do is split the JavaScript API page up into several pages.
> > it's already way too long anyways :)
> > 
> > then the main JS API page could link to those pages, and the QML pages
> > could link to the relevant ones. we'd just need to ensure that the
> > documentation is valid and appropriate for both JS and QML. do you have
> > a
> > list of sections on the JS API page that would also be relevant to QML?
> > i
> > can easily do the page splitting from there...
> 
> yeah, so there would be at least separated pages for the first level
> 
> the qml one would basically need chapters:
> 1.4
> 1.5
> 1.8 (well, not yet, the qpainter part is still not really binded, but will
> be eventually needed)
> 1.11
> 1.12

ok ... i will get working on this...

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20110622/82a211f6/attachment.sig