Centralize tree-filter class?

[Frans Englich]

On Monday 10 July 2006 19:51, Stephan Kulow wrote:
> Am Montag, 10. Juli 2006 21:23 schrieb Frans Englich:
[...]

> I don't think such a class has to be centralized as the application
> specific demands usually outweight the common base. So putting such a class
> on some webpage and a reference to patternist would suffice. Unfortunately
> all tries to come up with such a "solution base" always suffered from
> outdating too quickly ;(

Yeah, it probably is sensible. Also, all this item models stuff is pretty new 
for KDE so it's a bit difficult to at this point tell what will be stable over 
time.

This idea of copy&pasting classes was also brought up in the early 
kdelibs-structure discussion. Perhaps that approach should be organized a bit 
more?

I'm thinking about a dir in SVN where classes are stored. It is treated 
exactly as a directory in kdelibs except for that it isn't a library:

* Classes must be documented
* They are not exported
* QTestLib tests should exist
* branched appropriately so one can rely on them(that means such a module 
should be placed in trunk/KDE/ as opposed to trunk/?)
* Binary incompatible changes are ok as long as they are source compatible
* Source incompatible changes must be accompanied by porting
* Doxygen is displayed like for other modules(e.g, EBN/DKO)

People can bring this dir in as an svn:external, and include the files into 
their compiles.

I think it would be great, and achieves many of the points of 
putting something in kdelibs.

trunk/KDE/testcollection ?

It could help reduce the pressure for including things in kdelibs, when having 
this as outlet.


Cheers,

		Frans