I know that Marek was doing a lot of development for 220.127.116.11. Is anyone else still working on dev-cpp development?
I've been working with the wx-devcpp project (which is built on the 18.104.22.168 code base) and we're starting to look at memory leaks. It would be helpful if we could combine forces with dev-cpp developers.
I would recommend emailing Colin directly. You will probably get a better answer that way.
The last months were difficult for Marek and I, it is sometimes difficult to keep working on an open source project while you have a lot of other works to do at the same time.
I am going to have some free time next week, so I was considering making a new release of Dev-C++. Please contact me directly by email if you want that we work together on fixing bugs and leaks.
While it's not my place to say, I would suggest you just add them to the project. That way they can remove their wxWidgets sourceforge project and properly merge their code with ours on the cvs so that we all have just one build with the bug fixes of ours and the wx functionality of theirs.
Hi everyone. I'm also a dev on wx-devcpp project. I've been thinking of write a plug-in system for DevCpp, to allow us to deploy wx-devcpp as a runtime add-on. But for this work to be worth to do I need to know if Colin would accept to merge the changes needed on main DevCpp (assuming the code is well done, and tested previously, etc.). With this, DevCpp project can continue on its own and we at wx-side can deploy new changes or take advantage of new releases from plain DevCpp in a better manner. What do you guys think?
Yes, it's been quite some time i've been thinking of making a plugin system to extend Dev-C++, but unfortunately never got the time to develop it. wxDevCpp would be better too i guess as a Dev-C++ plugin than a fork of the project (otherwise contributions to one of the project won't benefit to the other, as a very obvious example).
Now we should also discuss what the plugin system should be able to handle. I think support for new editors and compiler systems should be on the top priority. Also, this plugin system should be able to load DLLs written in C or C++... the problem Dev-C++ is now suffering, is lack of support from developers who do not know Delphi programming, and I believe supports for such plugins would greatly benefits to the number of contributions to the project.
Please let me know your thoughts on this.
Hi again Colin, and the rest of people interested. I'm glad to announce that the promised plug-in system is finally seeing the light of day. I'm in a preliminar Alpha stage still, but you can see it as a proof of concept:
This is a version of wx-devcpp running as a plugin side-by-side with DevCpp. You need to install wx-devcpp 6.9 beta: https://sourceforge.net/project/showfiles.php?group_id=95606 and replace the executable and add the "plugins" folder, in order to try it out. It has some recent fixes to the vanilla DevCpp code merged from wx version, (memory leaks Tony mentioned in the beginning of this thread and other fixes) that we may merge back to your distribution some day. It is buggy and the interfaces need to be redesigned in order to allow more general plugin-types work, but that will be not too hard to do. Non delphi (C or C++) plugins are not an option yet, but I can see if that's possible someday.
Comments are welcome.
Very nice ! i'm glad to hear you found the time to do this, and will try it out as soon as i can.
I am quite in the same situation as Marek, my professional life has evolved in a way i do not have time to do more work on Dev-C++ for now. However, i'm very happy to see some people actually trying to improve it and help the project continue.
I will check your changes hopefully in some days, and will let you know about it.
If i understood well, this version is based on latest Dev-C++ CVS, including bug fixes merged from wxDevCpp right ?
Thanks again !
>If i understood well, this version is based on latest Dev-C++ CVS, including bug fixes merged from wxDevCpp right ?
That's right. However, there are many errors, and the plugin system is yet pretty rigid, I need to work it. There are also the sources for wxDevCpp designer as a plugin.
I've finally tested your changes. It looks nice !
At least this could permit to merge the wxDevCpp project to the main Dev-C++.
Also, could you please elaborate on what the plugin system you wrote currently permits ?
Also i see it is very important to enable plugins to be written in C or C++. Through an object plugin interface it would not really be possible i think, but calling plain C functions inside DLLs from Delphi is possible. I think we should look into this way too.
I'm glad to inform you that I have a much newer version of the plugin system, and it has indeed support for C/C++ plugins! (of course, it is early code). So far, the C dll's support is a subset of the Delphi's .bpl support, and that's because there is more flexibility for using delphi objects, forms, etc. Invoking C functions is totally supported, however, I'm still working on the best way of embedd visual objects within the IDE, in order allow that the user can invoke some functions directly. I've managed to embedd toolbar buttons, but it has some issues with the display (artifacts). I also plan to embedd menu entries and form windows, but I'm not so sure how hard that will be.
As for the question of the capabilities of the plugin system, so far it permits:
From delphi bpl's:
- Embedd menu entries, toolbars, message tabs (those in the bottom of the screen), and pretty much any component dockable within the IDE. All those components react to user interaction just like any native component would, so you can add any functionality you want to them.
- Respond to some "important" events within the vanilla code. These events were choosed based on the wx-devcpp requierements (lets say, the user switches tabs in the editor panel, the compiler is invoked, a project is created, or closed, the IDE startups or is about to close...). This is an arbitrary way of choosing them, however, wx-devcpp is a pretty complex addon, so I thought it would be a good template for undestanding what events could be needed to be aware of from a plugin.
- Invoke certain functions of the vanilla code. Again, this is based on wx-devcpp requirements. I still can make it a little more generic, however (and remember I don't have previuos experience on plug-in systems) I'm not sure there is a "clear" way of thinking what functions will be needed from a plugin in advance.
From DLL's: As I said, those are a subset of the delphi native runtimes (something like 80% of the functionality is available).
If you want, I can upload the current version next week, so you can take a look.
Good work then if you already came up with a solution for using C, i'd like to see that too when you can.
wx-DevCpp is probably a very good example of what should a plugin API propose for writing plugins.
Now another important thing which have to be thought too is to be able to make the API be upgradable in the future. Some kind of version checking should be done for the IDE to see which version the plugin supports and thus behave like this version of the API.
You can contact me by email too if you want.
That's great news. I haven't had time to touch dev-cpp code for a while. In fact because of changes in my professional life I don't even have delphi installed at this point.
From what you're saying it sounds great. I'll try to find some time to check it out. Other thing is that in my opinion person who is proficient enough in delphi and dev-cpp code structure could join dev-cpp developers and post the code him/herself. Good start to do that would be to post simple and readable patches through sf patch system.
Again - keep on good work
Sorry, I forgot to mention that you need to place the libraries vcl60.bpl and rtl60.bpl that come with any delphi6 distribution in order to make the program run. This is due to a compilation flag needed for runtime packages. Those 2 libraries are redistrtibutable within software made with a Delphi6 Personal license (refer to this document: http://bdn.borland.com/article/images/27583/deploy.txt ). However, I'm not sure if it is legal to post a link to those 2 files alone in a public forum...
> I think support for new editors and compiler systems should be on the top priority
Yes, the idea is that the plug-in system should work for other kind of editors (not only wx-devcpp). Also, I don't know if you are aware, but the guys at wx-devcpp are almost finishing changes on the IDE that allows the user to switch to VC compiler from Microsoft. I guess we can extend that to other compilers easily, since they are building a XML template system for the compiler flags. We can discuss how to merge that change on DevC++ also.
>Also, this plugin system should be able to load DLLs written in C or C++...
This is the tricky part. I have an overall good idea on how to write the plug-in system for delphi objects. I've managed to write a subset of this functionality for wx-devcpp, that's why I think I can write the plug-in system in the first place. But in regards to C/C++ DLL's we'll need to think a little more on how to do that, but is a good idea.
Ok, sounds very good. Are the other developers of wxDevCpp aware about that discussion ? Let me know maybe we can add all the developers to the Dev-C++ developer mailing list that we can discuss all this altogether.
Well, I commented them about this a couple of days ago, and I think at least the guy who started this thread is aware. Let me tell them about this talk, and organize ourselves and I'll let you know when we are ready for start working with you.
Thanks for your responses!
Excuse me sirs, but wx-devcpp has so wonderful XP-style-icons, is it possibly bring in devcpp such icons??
:) Thank you in advance
I should be joining the team if i can get it to port.
With some reflection, I think the plugin system should be a high priority after critical bug fixes. Once the system is done, it will attract C/C++ developers and cause a chain reaction of interest from there.
Hi, I write here in hopes for contacting Colin again. I don't know if you remember this thread; and/or if you received my last email a couple of weeks ago, I'm posting here in case you didn't got my email.
We at wx-devcpp are ready with the plugin stuff (well, doing some beta testing right now) and wan't to talk about merging back our stuff to your project. What do you think?
Esteban Aguilar B.
I've just replied to your email and CC'ed the interested persons.
Good work again.
Hello. I was look to the DevC++ with consideration always. It was and it is a good tool I always want to recommand mostly to everyone wants a small IDE to compile the projects.
Having an old release, it start showing it's age. Probably the today way to improve DevC++ is to make it work on Vista, to get a newer GCC, to import VS.NET projects, to solve bugs, leaks, etc. Probably to be ported to a newer Delphi (Turbo!?). What I wanted to ask is if is time and wanting, to put all sources in SVN and choose someone to integrate patches only (I don't know if Colin has time for that). In a short term at least quick fixes will integrate with a high rate, the big fixes will came later (or never), but at least will give back to community the project.
For an interim period (somelike 4 monts, till summer will came and probably the vacantion for students appear, and probably other will like to get the ownership, if not again Colin) I can integrate patches because I have somehow a free time and I have somehow experience with Delphi language (and sincerly if is accepted will be a honour for me).
Wish the best, and thanks for your work real!
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.