KoShapeControllerBase is _not_ (aha! got you!) the base class for
KoShapeController, instead it's an interface that document classes that
own shapes can implement to allow adding/removing shapes to their
internal shape data structure.

In other words, it's a base class for documents whose content is based
on shapes, in other words, a KoShapeBasedDocumentBase class...

Until 2006, it was called KoShapeControllerInterface, which made
sort of sense.

As discussed on irc:

15:29:42 < boud> I'm getting completely confused between KoShapeController and KoShapeControllerBase...
16:04:43 < sebsauer> boud: a good indicator that they are bad designed
16:10:03 < boud> yes, I totally agree
16:12:10 < svuorela> they need a AbstractKoShapeControllerBaseInterface to derive from
16:13:42 < boud> with one implemenation: SimpeKoShapeControllerBaseInterfaceImpl
16:14:14 < boud> I was browsing the git log, and it turns out that last summer I was hurting because of this design as well
16:15:53 < boud> actually, KoShapeControllerBase used to be called KoShapeControllerInterface, but that was renamed in 2006
16:17:19 < boud> jaham called it "Interface" -- and that still seems more accurate, since most methods are pure abstract. Thomas Zander renamed it.
16:24:49 < boud> I really wish I could get the shapecontroller right out of the canvasbase
16:27:18 < boemann> boud: to be far the renaming was idscussed on the ml and base is if it also implements base behaviour
16:27:22 < boemann> be fair
16:27:43 < sebsauer> lol re AbstractKoShapeControllerBaseInterface ... maybe turn it to a AbstractKoShapeControllerBaseInterfaceFactory ?
16:28:11 < sebsauer> or even a AbstractKoShapeControllerBaseInterfaceFactorySingleton
16:28:17 < boemann> sebsauer: no a factory cant return interfaces :)
16:28:27 < sebsauer> boemann: in C++ it can :-)
16:28:38 < sebsauer> interfaces without pure virtual
16:28:40 < sebsauer> 's
16:28:51 < boemann> ok it can but not accoring to our defs
16:29:22 < sebsauer> but yes, it's not nice and also misses a strategy-pattern
16:30:01 < boemann>  AbstractKoShapeControllerStrategyBaseInterfaceFactorySingleton
16:30:16 < sebsauer> sounds like a good name
16:30:30 < boemann> ok boud go ahead implementing our new design ;)
16:30:34 < sebsauer> :)
16:32:05 < svuorela> it's especially a good name for people who are paid by character ...
16:32:31 < boemann> :)
16:32:53 < boud> boemann: but this class doesn't implement the base behaviour for KoShapeController...
16:33:10 < boud> boemann: it's kind of an interface a document class implements so KoShapeController can add/remove shapes to the document
16:33:28 < boemann> oh
16:33:33 < boemann> nasty
16:33:43 < boud> the ***base renamings were last year, this was already in 2006
16:33:55 < boemann> ah
16:34:15 < boemann> i'd say we need to rename it
16:34:25 < boud> and every time, every time I look at these classes I am just as confused as you were just now -- surely KoShapeController must implement KoShapeControllerBase?
16:34:55 < boud> maybe KoShapeControllerDelegate?
16:35:21 < boemann> yeah
16:35:41 < boemann> if not a completely different name
16:36:25 < boud> it also creates a KoResourceManager and sets that on the shape factories for some reason... need to dig in again
16:36:34 < sebsauer> Ko42
16:37:20 < boud> lol
16:37:59 < svuorela> that's a great name. and then it can be subclassed to Ko43 when more virtuals are needed
16:38:26 < boud> how about KoShapeBasedDocumentBase...
16:38:53 < boemann> fine with me
16:39:05 < sebsauer> :-)
16:39:23 < boud> ok, will do
16:39:32 < svuorela> KoBasedShapeBasedDocumentBasedBase
16:39:32 < boud> I can't think of anything better
16:40:08 < boud> done..