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
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
