This web page is written from the perspective of the primary project admin Nuklear Zelph.
Whenever "I" is referenced it is the opinion or observation of that
specific developer. This page has replaced the old website which was
out-of-date and also meant to be replaced but it never actually
happened. I know this page is ugly, I hope to get a nice looking
replacement website up fairly soon
Status of the wxDevIDE project
Currently Tony is updating SVN. He is updating the code base to be wxDev-C++ 7.4 instead of the vanilla 220.127.116.11 which was the initial version in the repository. Some of this work had already been committed.
Nuklear Zelph is busy with his text editor project.
I have actually been working on it in the background for several years and its the reason that XSTC came into being. The project is not any big deal except that it is the new home for eXtended Styled Text Control and The MultiBook which is a neat notebook component. Both of these are dependencies of the editor plugin module for wxDevIDE.
Also I am doing some work on the IDE, My hope is to make a minimalist
version that will load a project and build it on both windows and Linux.
Tony also has a couple other projects related to the IDE as well. One parses a wxWidgets project and produces an XML document, it is aimed at helping wxDev-C++ users migrate to wxDevIDE. Another is a C++ version of the package manager. This is going to have all the same functionality of the Pascal version with some improvements. That package manager will be used in wxDevIDE.
I started open source development right out of high school. My C++ class was IMO the biggest waist of time ever. I had taken a Pascal
class a few years before and I already knew what I was doing. I also
tried M$-VC6 and I hated it. I've had some other experiences with M$
products and I just don't have a very great opinion of them. The
Operating System however I do like.
So being a fresh graduate I started looking around for options. GNU GCC was easy to find and I liked their paradigms, so I adopted MinGW as my compiler. Shortly thereafter I found Dev-C++.
I offered my assistance but unfortunately the project was dying out by
then. I had decided to build cross platform software as I was interested
in Linux and I didn't want my projects to be stuck on windows. Having
Looked around for toolkits wxWidgets and GTK+ where the top two on my list of options. I was unaware of QT at the time but learned later that is is also a very popular toolkit. wxWidgets
won out because of the perceived ease of use with a uniform api across
the whole and because it was just one library compared to several for GTK. I became very interested in doing something with GTK later on and I've started drafting a GUI for xine-lib that will use a skinning technology similar to Windows Media Player. In time I looked at many IDEs####'' for MinGW and I always went back to Dev-C++.
Having found wxWidgets I had issues with getting it to work with Dev-C++ and I was not savvy enough to fix those yet. I looked at the forums and found the wxDev-C++ project. I cannot count myself as a core developer to the wxDev-C++ project as I have not done much for it, I did create most of the XRC exporting code which got me in the door. Having found the project and realizing the vanilla project was dead I wanted to help out, hence the XRC contribution. I wanted to see Dev on Linux and I learned that some of the other developers did too. It wasn't till after Guru retired from the project that I really got serious about porting Dev. I checked out Kylix about a year before it was no longer available but it turned out to be a bust anyway. Lazarus was not feature complete enough yet to be a viable option. Also it made a lot more sense to port Dev to C++ as it was made for C++ in the first place.
Having had a great deal of wxWidgets and C++ experience by the time I was thinking about really doing something about Dev's cross platform issues I had no problem with porting it to wxWidgets.
Doing so made a lot of sense as the form designer was made for it and
that would also give us the opportunity to make a WYSIWYG version. So I
started asking the other developers what they thought about porting and wxDevIDE happened.
Initially when the proposal of porting Dev-C++ to C++ the wxDev-C++
development team agreed that it was a worthwhile goal. One of the
contributors, Sof.t came forward with a set of code that he had written.
It was a wxWidgets port of the vanilla version of Dev. (18.104.22.168) After some discussion it was determined that the licence for the new project should be under the wxWindows licence.
The main goal was to duplicate the GUI while revamping the internals. there are some design flaws in Dev-C++ that we hope to remedy. One of the most obvious is that the main procedure is enormous. Dev currently does not support workspaces, does not support build targets, the integrated debugger in vanilla is broken. the wx version is much better but still has some problems that could be worked on. obviously there are more differences between the vanilla and wx versions. originally the proposal of adding build time macros for adding the form designer into Dev was given to Colin Laplace.
He didn't like the Idea of binding his project to one specific
designer, so that didn't not happen. Shortly thereafter the project went
silent and the version stuck at 22.214.171.124.
After the wxDev-C++ developer discussion I started the wxDevIDE
project. We then discussed a lot of things and decided that the editor
component in the new IDE should not be dependant on one specifically. we
decided to use wxScintilla and make use of its api as our interface api for the editor plugin component. I had built eXtended Styled Text Control
and it looked like a good option for the editor component. we also
decided that the current form designer needed a complete rewrite.
obviously it needs to be built with wxWidgets, but we also wanted to use an XML template system that would allow wxWidgets
api updates to be easy to maintain. also several flavors could be
provided without the problems of having each component in the designer
export its own code.
Tony started a project to help create forms for the new IDE. the form designer it was decided would use XRC XML with some extensions for the necessary information that XRC did not handle which would be needed by the designer.
a new package manager written in C++ had already been started at the time of the new IDE project creation.
the sources that Sof.t had put forward where committed to SVN. shortly thereafter an update that fixed compilation issues was committed.
as wxDev-C++ was in the middle of a development cycle focus shifted back to getting that release out. (7.3)
I then had some things change and could not continue with the project
for some time. As I am the primary admin things basically fell apart.
since then another release has come out (7.4), Tony found a solution to dragging buttons and other controls that would crash in GTK but work in Windows.
at present I put up a project for a text editor I have been building off
and on. I have not gotten too far on an actual app as I keep getting
side tracked with things like XSTC and The MultiBook. XSTC was moved to that project space from wxCode. a notebook component I started some time ago was also put up on that project space and a color button like the one used in Dev-C++
that I built on a whim as I had no better place to distribute it. The
project will do a lot of the legwork for the editor plugin for the IDE
as well as maintain a few of the dependencies.
Although there are no files in the release system I plan to remedy that
very soon. A windows binary showing the current state of the project
will be put on the file release system. I also hope to get the code to
build and run on Linux and put up a binary for that as well.
the focus of the project at present is basically continuing the work that was started by Sof.t and continue porting the Delphi code. Since the developer who built the plugin system for wxDev has moved on to the ReactOS
project we don't have an "expert" on that subject anymore. I will be
completing the editor module that I started and will integrate it into
the current code base. I also hope to get a bare-bones project working
as well. hopefully on both Windows and Linux.
once the editor module is in a usable state a branched GUI will be started to take its place in the new IDE. this will support AUI,
will be designed with a future plugin system in mind so changing the UI
elements is a simple matter not a chore. Also the new form designer
will use this as an application base for a standalone version of the
designer. in the future the main IDE will probably have a build macro to
trim it down for use as the standalone app for the form designer.