Thread: Re: [Wxdevide-devs] discussing wxDevIDE publicly

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

> defenatly need to talk about wxDevIDE. i took a look at the
> code and then i felt overwhelmed and kinda quit. some of the
> delphi stuff is duplicated over an already exsisting C++
> solution. Tstringlist could be replaced with wxArrayString,
> unless there is a viable reason we need to keep the other
> one or that the wx version is too unstable. i have not seen
> that it is. 
> 
> 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++. 

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.

> also in
> keeping the interface the same it will mean configuration
> dialogs too. most generally for the compiler this is easy
> from what i have seen, but the editor is a different matter.
> we can't make it a clone, but that is not the point. we
> have an issue with the [editor dialog]&[editor] combo.
> do we just MAKE the dialog as Devish as possible and pass it
> to the ide or do we make a template class and have the
> plugin fill it out. obviously if we don't use a plugin
> for this there is no problem, but, planning for the future
> makes things a lot easier.
> 
> If I understand you correctly, I believe that
> the editor "plugin", should contain the editor
> itself as well as the config dialog. This should be as wxDev
> as possible, removing what is not supported (I don't
> think graying out is an option here since graying out
> suggests that some action results in UNgraying), and adding
> any options that are not supported by synedit (Code Folding
> for example). This info could/should be in its own config
> file, separate from the general stuff for the IDE.

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.

      ____________________________________________________________________________________
¡Obtén la mejor experiencia en la web!
Descarga gratis el nuevo Internet Explorer 8. 
http://downloads.yahoo.com/ieak8/?l=e1

Thread: Re: [Wxdevide-devs] discussing wxDevIDE publicly

A modernized, platform independant version of Dev-C++

wxdevide-devs