One of the problems with:
all the right things but no more
as you point out, is that different people want different things. The
desired feature set for any given application grows with time. What
might ultimately make the most sense, is for the application to keep
track of what features are used the most frequently, and pre-cache any
code or data that might take a while to load. Since very few user will
use the whole feature set, this should give our users a much more
satisfactory experience than if we let the whole application bloat up
and hog memory or if we try to pick which functions we think will be
used most. (Obviously, there will be a core set of functions we'll keep
in memory because they are used by all the other functions.)
I think that one focus in the future should be on pure interface issues.
We want to make it as easy as possible to use FreeMind. That means we
should make it easy for the user to understand what is happening at any
given time, and make it easy work quickly. We also have to make the
entire interface consistent, so the user doesn't have to learn a
different set of rules for different parts of the program. Some of that
work has already started and I think it's already improved the look and
usability of the program.
Ray
Reasamp wrote:
thanks for your questions. This week I have absolutely no time to
answer, but I shall so it ASAP. In particular I am going to write about
* goals of the proposed refactoring,
* differences and similarities between eclipse and FreeMind,
* advantages and disadvanteges of Lazy Loading for extensions.
* extention mechanisms for menus, tool bars and other GUI elements.
Even before this mail, I simply assumed that these things would be coming
up as soon as you have the time:) Guess I can wait
But anyway, adv/disadv for lazy loading is something widely available in
Eclipse plugin whitepapers and tutorials all over the net. Don't think
documenting that out would be necessary if it is similar enough with
Eclipse (I mean, we do have other sources to figure that out). I'd rather
like to see that time spent in the details specific to Freemind, perhaps
with some short description of things from Eclipse if that helps to
establish the context.
And about goals, I'd like to put in two notes about features loosely
related to goals. To me it seems that FreeMind needs to become an easily
accessible tool with just all the right things but no more. Trouble,
obviously, is that the right combination depends on the people. So as
number and complexity of features/plugins increase, we might want to ship
them as separate packages to keep the application look and be acceptably
lightweight. This means some simple but basic assumptions come under
consideration:
* We need a plugins manager. If I install a plugin which I dont like, I
need to be able to remove it. I'd like to be able to enable/disable
plugins/groups of plugins without actually going into the plugins folder
and moving them out. This in turn means the generic plugins interface will
provide enough information for such management.
* Plugin packages should not have to share the same directory as root
freemind installation. This is specially true if we intend 3rd parties to
develop plugins in the long run. This would, once again, enable me to
simply delete those additional files if I don't like them. Similarly, if
FreeMind is uninstalled/updated, plugin data should not be lost. So our
plugin discovery feature will need to be a bit robust.
Reasamp
-------------------------------------------------------------------------
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
-------------------------------------------------------------------------
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
