Re: [Wxdevide-devs] discussing wxDevIDE publicly

[M N. <m.n...@wa...>]

On Sun, Jul 26, 2009 at 7:15 PM, Esteban Aguilar B. <nab...@ya...>wrote:

>
> > I have always said that we need to keep the
> > "LOOK AND FEEL" of wxDevC++. How we implement it
> > (e.g. Tstringlist/wxArrayString) is, for ME, unimportant. As
> > long as it looks like wxDevC++ and feels like wxDevC++
> > (especially the designer) then I'm a happy
> > chappie.
>
> I agree with Mal. In fact, I think the point of wxDevIDE is the chance of
> getting rid of tons of things wxDevCpp does wrong. Sure, the current code
> may be helpful in understanding several things, like how the compiler, the
> debugger or the designer stuff works, etc. but in my opinion it would be a
> big mistake just taking the code and try to translate it to C++.


Designing the IDE should be reasonably simple, since we are just replicating
a lot of dialogs in the first place. And I do agree that attempting to
merely translate the Delphi to C++ is fraught with problems.


>
>
> You don't want to try to deal with the huge ass TMainForm mess again. In
> fact, a good desing separates the GUI stuff from the business domain
> objects; in that regard, the TMainForm implementation is a fundamentally
> flawed desing.
>
> I can give several other examples of things wxDevCpp does wrong: for one,
> event-driven sections of code are very difficult to understand. I've had
> lots of pain looking for the right place in code that gets executed after
> some obvious action in the GUI; there are several places that use things
> like the repaint event of some component to check on the state of some other
> component to trigger some action. Again, a good design requires the control
> of the flow of actions to be condenced in some well defined objects in which
> these tasks are clearly identified.


I too found it difficult to fathom when some of the code was actually being
run.


>
>
>
>
> I've written a proposal on how the plugins support could be modeled.
>
> http://wxdevide.wiki.sourceforge.net/wxDevIDE+API?f=print
>
> I know it is a little confusing, but my idea could be summarized in
> observing which parts of the IDE are good candidates for plugin replacement,
> and implement all the comunication between them and the cotroller objects
> throwgh interfaces (c++ abstract classes).
>
> At this point I think I would like to contribute in this area of the
> project, if you guys agree.
>
>
I say go ahead. Any hard and fast documentation is good when we are all so
spread out as we are.

Best regards
Mal