--nextPart11082679.V01zqVV0T4
Content-Type: Text/Plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

On September 2, 2009, Friedrich W. H. Kossebau wrote:
> In general a good idea. :)

:)

> * Will it be a good idea to mix all examples for all the different produc=
ts
> of KDE?

i think so; this gives people a "one stop shopping experience" for example=
=20
code. it also means if someone is interested in, say, Phonon they will be m=
ore=20
likely to grab all the other examples in one big package and by doing so be=
=20
exposed to more of our wonderful work.

knowing how people tend to work, it'll be common for someone to look for ju=
st=20
one topic at first, then later a different topic. if we make them run aroun=
d=20
our source packages hunting it would be pretty annoying for them.

> There is the workspace, there are standalone programs, there is the Dev
> Platform, there is kdesupport (and more?). To get people into getting the
> idea that KDE !=3D "just the desktop environment" examples might be better
> split and live near the products they are for (e.g. kipi-plugin examples =
in
> extragear/graphics/kipi-plugins/examples and kioslave examples in
> kdelibs/examples/kioslave), i.e. in the same module.

this is -exactly- the situation we have now. and it sucks: people do not fi=
nd=20
our examples on their own. how do i know? because i'm constantly referring=
=20
people to them ;)

what makes this even worse is that most people who code with KDE libraries =
do=20
not have our sources on their disk. they use binary packages. hunting in ou=
r=20
sources is just not convenient in the least for most of our 3rd party=20
developers.

> * What about example plugins which rely on private (and with hidden
> symbols) API?

then they either need to provide copies of these classes in the examples=20
module or not join the examples module. and, i would suggest, that if you=20
design your library properly this is not necessary. people should not need =
(or=20
want!) to use private bits in their app code.

> codebase. For Okteta I started (not yet commited) to add example subdirs
> with template/example files to dirs with pluggable systems and compile
> these files to static libs, based on a set Makefile flag.

could these same static libs live in examples/? if not, then Okteta's libs=
=20
aren't ready for broad use yet and it's ok for them not to be in examples f=
or=20
the time being.

> * How to ensure that the examples do not bitrot?

they already do bitrot. so this would not be a new problem. i do have a hun=
ch,=20
though, that if more people were actually using the examples we'd hear abou=
t=20
breakage sooner.

> While I agree it is a very good idea to improve visibility of example code
> it should not be collected at one central place, but instead at dedicated
> places inside each module, comparable to how the manuals are organized.

see above for why this simply doesn't work. we can certainly divide things =
up=20
within an examples/ module, though.

> This would also help with versioning of the examples (and the API they are
> based on).

see Kevin's email for this.

> > (the addition of more examples in kdecore/auth/examples is what jogged =
my
> > memory on this one :)
>
> (It's example time? Just started to write examples for Okteta plugins last
> WE :)

hehe...

=2D-=20
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 Framework

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

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

iEYEABECAAYFAkqeZVMACgkQ1rcusafx20MLtgCfbVZfXh4Nn2IyT8UPGUZDxb0i
8xoAoLEFn4GzWZi2yPfmxncP+nubB24q
=sanp
-----END PGP SIGNATURE-----

--nextPart11082679.V01zqVV0T4--