Code::Blocks Topic is solved
-
- Super wx Problem Solver
- Posts: 396
- Joined: Wed Oct 05, 2005 1:19 am
Code::Blocks
Hi for those of you who don't know there is this really cool IDE called Code::Blocks. It is built with wxWidgets. They are looking for people that can help with the development of the IDE and the associated RAD editor.
Check it out here.
http://www.codeblocks.org/
The wxSmith development thread is here.
http://forums.codeblocks.org/index.php/topic,372.0.html
Check it out here.
http://www.codeblocks.org/
The wxSmith development thread is here.
http://forums.codeblocks.org/index.php/topic,372.0.html
Last edited by sethjackson on Mon Nov 07, 2005 3:25 pm, edited 4 times in total.
Try wxFormBuilder!
https://sourceforge.net/projects/wxformbuilder/
I use codeblocks for my wx-projects, even for development of wxFormBuilder.
Codeblocks is a great IDE, I really like it and the formula codeblocks+wxFormBuilder works very well for me.
Recently, wxFormBuilder 1.0 has been released and a new branch of this project will be started soon. The future of wxFormBuilder will depend on the interest and colaboration of other people into the project. I plan to create a public forum on sourceforge for all kind of ideas, suggestion, design proposals, etc.
I respect to other people who prefer developing another RAD from scratch instead of helping the wxFB development and I would like to say that there won't be any kind of competence with those projects, if you think that wxFB is useful for you, just use it, and if you want, you can contribute. There are many kinds of contributions: comments, suggestions, tutorials, translations (thanks metalogic), bakefiles, etc, etc.
I'd like to finish with some words for Upcase:
I think that your work (wxRapid) is really interesting, a few times you say that you lack of time for your project and I like to know if you would like to discuss your approach for future wxFB releases because I think that "sizer based" and "free hand" approaches could be compatibles.
Regards,
Jos
https://sourceforge.net/projects/wxformbuilder/
I use codeblocks for my wx-projects, even for development of wxFormBuilder.
Codeblocks is a great IDE, I really like it and the formula codeblocks+wxFormBuilder works very well for me.
Recently, wxFormBuilder 1.0 has been released and a new branch of this project will be started soon. The future of wxFormBuilder will depend on the interest and colaboration of other people into the project. I plan to create a public forum on sourceforge for all kind of ideas, suggestion, design proposals, etc.
I respect to other people who prefer developing another RAD from scratch instead of helping the wxFB development and I would like to say that there won't be any kind of competence with those projects, if you think that wxFB is useful for you, just use it, and if you want, you can contribute. There are many kinds of contributions: comments, suggestions, tutorials, translations (thanks metalogic), bakefiles, etc, etc.
I'd like to finish with some words for Upcase:
I think that your work (wxRapid) is really interesting, a few times you say that you lack of time for your project and I like to know if you would like to discuss your approach for future wxFB releases because I think that "sizer based" and "free hand" approaches could be compatibles.
Regards,
Jos
Last edited by jhurtado on Sat Oct 29, 2005 7:38 am, edited 2 times in total.
I'm pro Code::Blocks, I think it is a great tool, and I apreciate a lot the work made by the developers involved in that project. But since the begining, I felt very disapointed that they choosed to make wxSmith for Code::blocks instead of using the already existing at that point wxFormBuilder, making unnecessary reinvent-the-weel-yet-one-more-time work, and forking the options yet one more time for the users, making things more confusing and the efforts less productive: for instance, if wxFormBuilder is abandoned because of lack of interes, it will be just wasted work. I think OSS community cannot afford the luxury of wasting precious volunteer work, specially when almost not a single project has reached the goal that like 10 are trying to met, in the case of wx-GUI designers.
The making of wxSmith is not a desision that is made by the main developers, it is started by someone else.
the development of Code::Blocks isn't suffer under the development of wxSmith.
And for some people it is a problem that wxFormBuilder is a sepperate application and not a plugin which is integrated in C::B.
And you can't force the main developers of wxSmith to work on an other project. They like to work (and reinvent the wheel) on wxSmith.
the development of Code::Blocks isn't suffer under the development of wxSmith.
And for some people it is a problem that wxFormBuilder is a sepperate application and not a plugin which is integrated in C::B.
And you can't force the main developers of wxSmith to work on an other project. They like to work (and reinvent the wheel) on wxSmith.
OS: win XP pro
Compiler: MingW
wxWidgets version: 2.6.2
Compiler: MingW
wxWidgets version: 2.6.2
That's not the problem. The problem is thatmispunt wrote:The making of wxSmith is not a desision that is made by the main developers, it is started by someone else.
the development of Code::Blocks isn't suffer under the development of wxSmith.
1- GUI Development work is less concentrated -> then, less productive.
2- Users "suffer" because they have so many options, some offer some things, some other things, but ironically, none of the options is complete so they have to use a mixture of tools that complicates work and finally could drive away some people from wxWidgets.
3- Valuable Developers, like Jos
Last edited by buildere on Mon Nov 07, 2005 9:22 pm, edited 1 time in total.
-
- Super wx Problem Solver
- Posts: 396
- Joined: Wed Oct 05, 2005 1:19 am
The idea consist in to encapsulate wxFormBuilder into a class and build the application into a DLL. This DLL will have one exported function which will create the instance of this class (wxFormBuilderInterface *).
Codeblocks developers will use this instance for sending commands (undo, redo, generate code, etc) to wxFormBuilder and they won't need to know wxFB internals.
Regards.
Codeblocks developers will use this instance for sending commands (undo, redo, generate code, etc) to wxFormBuilder and they won't need to know wxFB internals.
Regards.