new kde-examples module

[Aaron J. Seigo]

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 products
> of KDE?

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

knowing how people tend to work, it'll be common for someone to look for just 
one topic at first, then later a different topic. if we make them run around 
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 != "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 find 
our examples on their own. how do i know? because i'm constantly referring 
people to them ;)

what makes this even worse is that most people who code with KDE libraries do 
not have our sources on their disk. they use binary packages. hunting in our 
sources is just not convenient in the least for most of our 3rd party 
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 
module or not join the examples module. and, i would suggest, that if you 
design your library properly this is not necessary. people should not need (or 
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 
aren't ready for broad use yet and it's ok for them not to be in examples for 
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 hunch, 
though, that if more people were actually using the examples we'd hear about 
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 
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...

-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20090902/a08fc9ef/attachment.sig>