From kde-panel-devel  Wed Jun 22 14:38:57 2011
From: "Aaron J. Seigo" <aseigo () kde ! org>
Date: Wed, 22 Jun 2011 14:38:57 +0000
To: kde-panel-devel
Subject: Re: Plasma QML documentation
Message-Id: <18186218.eX1QufbiWJ () freedom>
X-MARC-Message: https://marc.info/?l=kde-panel-devel&m=130875360116904
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--===============0754813435=="


--===============0754813435==
Content-Type: multipart/signed; boundary="nextPart11291444.hY1OnaVg3i"; micalg="pgp-sha1"; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7Bit


--nextPart11291444.hY1OnaVg3i
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"

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

--nextPart11291444.hY1OnaVg3i
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)

iEYEABECAAYFAk4B/oEACgkQ1rcusafx20OihACfT6PxunIv5XZUo5eA5B2iQT5t
FoUAnR2UzoStvl/08d6clvVVqz/FKOs+
=zSyH
-----END PGP SIGNATURE-----

--nextPart11291444.hY1OnaVg3i--


--===============0754813435==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

--===============0754813435==--