[Dynapyide-developer] New plan & class diagram

[<hv...@ya...>]

Hello,

As I belive the reasonwe have failed to get going is that the =
application aims was probably to high and the initial docs to start out =
too complex (mostly my fault).

I'm giving it a new try now, hoping that more reachable milestones in =
form of builds up to the 1.0 version will make it easier to see how we =
should be progressing. Also I've wrote in how the vapplication could be =
begun to come to use with each pre-version.

I also set a working name for each version, mainly to have something to =
call it by while developing, but also trying to invoke what the version =
will bring new in the application. My english is bad, and I tried to =
keep the theme of calling them all something ending with Ed, hope you =
can excuse it, cause its only temporary.

Please, please, please read through these very much shortened down text =
files. dynAPIideVersions.txt is very briefly outlining my plan as to how =
we will proceed with pre-versioning up til the full 1.0 version release. =
and dynAPIdeClasses is the classes diagram as I figure it, for having a =
functioning  version 0.1 build according to plan outlined.

As always this isn't set in stone. I'd be glad to get any comments or =
sugestions - even flamings (as long as reasonable). ;)

Just a few brief notes of what my vision of this application is, so =
you'll understand my thinking as outlined in these textfiles:
=20
* The application is divided into 3 cross-interacting layers of =
classtypes: Handlers (core operations and data), Managers (UI =
operations) and Modules (GUI)

* All classes and instances thereof (IDE objects) is loaded via an =
internal (class-)loading engine which works on load and reload events

* Loading is configured in javasscript in an DynAPI syntax-like manner =
(promoting the learning of DynAPI which is much forward JAVA)

* As much as possible of the in-application communication between IDE =
objects is done by invoking and answering to event calls. This way one =
object can independatly reacting upon another objects actions.

* Plugability and customization should be done to the highest possible =
extent. Any part of the application should work as independently as =
possible within the application, but also define which other parts it =
depend upon and not load unless it's there.

This is what I've figured makes a application that can be customed for =
any induviduals prefered likings and uses. From my thinking this =
class-structure achieves that to highest possible and reasonable. You're =
very welecome to disagree as long as you can define why :)

Hope to get some kinda response from everybody that still wanna be in on =
this endeavour.=20

I know the demand for this application is still high cause every now and =
then someone emails me to try and give an idea as to what we could aim =
at to get going. of course you would wish for some of them to actually =
be willing to spend some time to help developing it, but an interest in =
it is still better than no response at all...

Henrik V=E5glin [ hv...@ya... ]