Ray, The refactoring itself should not change any user interface or behavior issue. It just should create some significantly clearer and easier design open for future development.
> I'm not yet in agreement that we should go with a > small kernel model for the new design. If we try to make > the kernel too small, we'll wind up using lazy loading for elements of > the architecture that are used all the time. It looks like I have expressed myself in a way leading to misunderstanding. I do not propose to extract any parts of functionality in plug-ins. The main purpose of the proposed design is reducing the complexity of the main MindMap, MindMapNode, Controller and ModeController classes by moving models, controllers (actions) and views of their different properties in different mutually independent classes and packages. For instance we could write > b) Each node contains: > * pointers to children nodes > * pointer to the parent node > * pointer to the map > * node formatting information (form and color) > * optional cloud formatting information (color) > * Text > * Text formatting information > * An optional Note > * Optional Icons and so-called state icons > (e.g. Attribute or Note icon) > * An edge coming from the parent node > * Edge formatting information > * A Time/Date Stamp for when it was created, and when it was last > edited. > * Other properties like latex So I propose to use leave only the structural information in the MindMapNode: > * pointers to children nodes > * pointer to the parent node > * pointer to the map and create packages freemind.format.model freemind.format.controller.mindmapmode > * node formatting information (form and color) freemind.cloud.model freemind.cloud.controller.mindmapmode > * optional cloud formatting information (color) freemind.text.model freemind.text.controller.mindmapmode > * Text > * Text formatting information freemind.note.model freemind.note.controller.mindmapmode freemind.note.view.mindmapmode freemind.note.view.browsermode > * Note and so on. Changing or extending of such small packages with similar structure is much easier than handling and improvements of huge interfaces and classes we have without such structure today. The proposed Extension Object mechanism describes how specific property controller and model objects can be seamlessly attached to the "main" controller and model objects so that the program performance is not noticeable decreased. Dimitry ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Freemind-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freemind-developer
