Hello Reasamp, thank you for your fast response, careful reading and asking questions.
> I was about to post some very minor bugfixes and do some api docs, but > when this came up, I decided to halt the docs part. Since this seems to be > a good time to do any major/semimajor design changes, here goes a few > suggestions and questions - both from a stranger's perspective (given that > I am new to this project): Now after years of doing the right things (in sense of features) I see a chance to get the things right and easy (in sense of design). As you see, the most important idea of the proposed design is a concept of independent extension packages implementing independent map and node properties and seamlessly integrated into the framework. > * Seems ApplicationController can have only one instance of > FreeMindContainer. Maybe we could share one ApplicationController over > many FreeMindController, sort of like our web browsers which run multiple > windows in the same process tree? Might help a few synchronization > problems between user preferences (right now, if we run two instances of > FreeMind and one changes user prefs, other might not sync up. Then later, > when saving prefs on exit or something, those changes might be lost). I like your idea. Although it is beyond the pure refactoring, we could keep it in mind and implement it later, may be after the refactoring is finished. > * FreeMindContainer#isApplet() - while useful, I'd prefer if later on > FreeMind makes use of other containers like text-based, or something else. > So a similar but more generic method could be added here as well, > isOfType(String). I know this is basically the same as invoking reflection > on 'this', but for the sake of completeness it feels like it might have a > place here. It depends on the use case, but I see that the methods like in the most cases should generally be replaced by better OO solutions. Let us remove this method for now. > * What is an "Active Map" for a ModeController? Does every mode of map > have a separate "Active" map of it's own? You are right as there is actually only one selected or active map at the same time. I can remove both ModeController#getActiveMap() and ModeController#getActiveMapView(), because they rather belong to the ApplicationController (and they are already present there). > * ModeController#getActiveMapView() - shouldn't the return type be a > MapView? I see. > * ModeController#getMenuBar()/getToolBar() - seems like we are > implementing the entire menu for every mode. If so, should every new > feature added require tweaks in the menues/toolbars of every single > ModeController implementation? I was thinking may be we could assign a few > attributes to every menu item/action or make them implement an interface > so that different ModeControlloers can pick which item they want on their > own. Not sure if this is actually possible, but could make maintaining > features much easier if well done. I agree that in the most cases not the few ModeControllers but the numerous actions should declare what they are good for and what submenus, or tool bar items they should occupy. I know that this part of the design is lacking of some essential details like which still have to be defined. > * Usually, the close() method of a resource comes with the class > representing that resource. However, here we have to call > ModeController.close to close a MindMap object. Usually I see that kind of > method attached to the MindMap object (like File objects have a close > method, NOT a System.close(File) method). So it seems more intuitive to me > that Map create/load/save/close methods should be in the MindMap class. > createMap and loadMap could translate to create(ModeController) and > load(ModeController) in MindMap, save and close could become non-static > instance members. I know this would probably mean they simply wrap the > corresponding calls in a ModeController, but it reduces the need for a > ModeController object to be exposed in areas where it could be treated as > an implementation details hidden inside a MindMap, simplifying codes. I am not sure whether the MindMaps containing the model should be provided with strategies of how those models are created, loaded or saved. Because there can be potentially many different input/output formats and initial states and because I do not expect that such strategies depend on the MindMap content, I still think that ModeControllers should be responsible for choosing of the proper logic and managing of the possible options. And if we look at some extension, for instance if you have an extension managing attributes, the extension should know how to create/load/persist/clean up corresponding model elements. Such extension is registered only by the ModeController and not by the map as long as no attributes have been created for this map. > * The getIntProperty has a "default value" parameter, so how come the > getProperty (presumeably the String counterpart) doesn't? The methods have been copied from the current classes. Now I do not think that we need any default parameters because such parameter can just become a part of the default properties. > * What is the exact distinction between a ResourceString and a > PropertyString? Is it that one is readonly and the other isn't? Properties can be changed by user. ResourceString historically means language resources. > Any reply at all would be appreciated - it would let me get a much better > understanding of the project details and ideas. Any reply is welcome - it is nice to develop a better design together. Dimitry ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Freemind-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freemind-developer
