Krita source & library layout reorganization

[Boudewijn Rempt]

Not something I think we're going today, but it's good to have our thoughts 
about this problem recorded & perhaps discussed. Currently, Krita's source
and library layout is the result of historic growth. 

Originally, we had a couple of libraries that were combined into a big Krita 
part -- tools and core. Paintops and colorstrategies were not separated at 
all. Cyrille made it possible for Krita to use KPart plugins, for instance 
for filters. Then I made the paintops and colorspaces into plugins, but not 
plugins that are loaded when the view is created, but when the application 
factory is created. Nowadays, filters and tools are also loaded when the app 
factory is created, and aren't subject to the kxmlgui tyranny anymore.

However, we don't have a clear separation between a shared krita library and 
the implementation of a koffice part, and we don't have a clear set of 
interfaces that plugins, dcop and scripting bindings can use, and we don't 
have a clear set of interfaces that plugins should implement (so Krita can 
know what's what.

KisFilter is an example of an interface that a filter plugin should implement, 
KisCanvasSubject an example of an interface that a plugin could use; KisView 
is an example of a KOffice part interface implementation that no filter 
should ever need to know about.

The structure I want to propose (but I'm not sure it's possible, I'm not a C++ 
guru yet) is as follows:


krita/
	/kritasdk (includes nothing)
		/coresdk
			/kis_canvas_subject.h
			...
		/pluginsdk
			/kis_filter.h
			...
	/libkrita (include kritasdk)
		/
		/kis_paint_device.h
		/kis_image.h/
		/kis_layer.h
		/datamanager
			/kis_datamanager.h
					
	/kritapart (includes libkrita and kritasdk)
		/kis_doc.h
		/kis_view.h
	/plugins (include kritasdk)
		/filters
		/colorspaces
		/tools
		/paintops
		/extensions (kxmlgui client)
	/dcop (includes kritapart and kritasdk)
		IKisDoc.h
		IKisPaintDevice.h
	/data
	/dtd
	/pics

Both libkrita and kritapart are separate shared libraries (as are all plugins, 
of course.) Maybe dcop should just be a plugin alongside all others.
	
-- 
Boudewijn Rempt 
http://www.valdyas.org/fading/index.cgi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kimageshop/attachments/20050802/8b7cf604/attachment.pgp