It would certainly be hard to get things done without Dimitry's energy
and enthusiasm. I think it's best to work out an overall road map for
the future, though, especially if we're thinking about doing a major
refactoring. I think we need the following goals, most of which Dimitry
has already expressed:
1. Match the current capabilities of the current FreeMind
2. Provide a clear architectural model that is both easy to
understand and easy to extend. We need to consider possible future
directions for FreeMind and make sure we don't design ourselves
into a corner. (I don't think that's likely, but it's always good
to be cautious.) For instance, I think it would be good to have
FreeMind support the multiple document model that most Windows
applications support. The user should be able to have multiple
maps open in multiple windows. It would also be nice to be able to
link maps to each other. (If that's not a capability that already
exists that I've overlooked.) I'm not suggesting we necessarily
put those in during refactoring, merely that we avoid going down
paths that would prevent those kinds of additions.
3. Provide much clearer and more comprehensive documentation of the
core code, mostly via JavaDoc. We also should consider developing
an online documentation Wiki, similar to that used by Blender and
other projects.
4. Build with testing in mind. We should plan on building a
regression test suite that we update with each new release.
Ray
Eric Lavarde wrote:
Hi,
I can't say much about the how, but concerning the what, I do fully
agree with Dimitry: the best way to get a community of developers is to
have a clear plugin architecture, where new developers can start working
on, without caring much about the core of the program.
As a side note, new or old design, javadoc descriptions are very much
welcome.
Chris, I truly think that you need to give Dimitry a clear answer about
how you want to proceed: either you have the bandwidth to work with him
on the "future" (old adapted or new) design, or you should accept that
he drives the future direction of FreeMind.
I truly think that, for an Open Source project, the person with the most
"drive" (Schwung/Dynamik/Antrieb) should drive it, else you loose too
much momentum. And currently it's Dimitry who has the most drive (not
difficult, he doesn't have a child :-) ).
Hope we can progress on this point,
Eric
Dimitry Polivaev wrote:
Hello,
last days I have spent many time analyzing current state of the program
design. And I have run into troubles: IMHO the complexity of the program
which can be measured on amount of different interfaces, classes and
dependencies between them, is significantly bigger than required by the
features we have. The purposes of many classes and the patterns they
follow are neither documented nor self evident, the class and methods
names are not really helpful either.
Because simplicity and clarity of the program design is very important
for both its long life and my satisfaction as a developer, I am not very
happy about it.
I see the following ways to deal with the problem:
1. Because the only two persons significantly contributed to the program
in the last years, we could try to exchange and complete our knowledge.
We could provide a javadoc documentation explaining the intention of the
relevant classes and packages. We could also use any kind of synchronous
communication with the purpose of understanding the things before trying
to change them. We could use chat, skype or phone, but I could also
personally come to Berlin for one or two sessions. This way we could
design the changes together.
2. Alternatively I could develop a new design by myself. The new design
would have a relatively small kernel and further mutually independent
packages depending only on this small kernel.
The new design would extensively use the Extension Object pattern
proposed by Erich Gamma and used in Eclipse. The pattern is described in
his book "Contributing to eclipse", it is also explained in
http://www-st.inf.tu-dresden.de/Lehre/WS04-05/dpf/slides/9-framework-extensibility.pdf
(Personally I have read the book, the pdf is just a link returned by
google).
This pattern makes possible attaching of the any extension objects to
some object which does not depend on them by itself. Using this pattern
we could attach new actions to the controller or new model elements to
maps or nodes without changing their own code.
Such design would make no difference between managing of the freemind
"native" actions and model elements and of the elements coming from a
plug-in. (NodeView is already able to display added elements, it results
from refactoring I did 2007). The current plug-in framework (which IMHO
is very difficult to use and to understand) could be replaced by more
transparent and light-weight solution. But if I had to work alone, I
would be not able to consider Chris's ideas and wishes.
Dear Chris, that's why I would like to ask you to write your wishes
about how to organize our work and communication here if this list.
Best regards, Dimitry
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Freemind-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freemind-developer
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Freemind-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freemind-developer
