|
From: <hv...@ya...> - 2002-01-03 21:11:24
|
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... ] |