However, I must mention earlier that I am really really new to wxwidgets . My C/C++ development is only up to DOS-GUI level, no experience in MFC , OWL all kind of framework before. Furthermore, I have not use C/C++ for 5 years.
I would like to help you, so if you have some little ore little bigger "todo´s" for a bored coder, tell me! p.s: wxDev-Cpp have some some little bugs, look at sharpDevelop, they have a good design decision for the problem of Forms - Designer and XML. The Patterns can be used in c++ also... :P
Hope to hear form you soon...
take a lok at wxFormBuilder, its in c++, when I first saw it, i immediately thought that it would be the perfect base for a RAD plugin to codeblocks
Now, about JOINING the team:
Currently i'm the "teenage helper holy crap batman!" sidekick. It'd be unwise to let "newcomers" in just because we felt like it.
However, you CAN:
* download and install tortoiseCVS in your machine (or any cvs if you use linux)
* use CVS to get the codeblocks source code (using anonymous -readonly- account) and study it.
* make any changes you wish to YOUR copy. If you mess up, you perform a "clean update" CVS operation on your copy so it's left untouched. (Ah, the advantages of CVS :)
* post suggested fixes and questions in this forum. That's what it is for, after all! :)
Your first assignment would be to download CVS, download the wxWidgets 2.4.2 source code, and compile it according to the "compiling codeblocks" posts in the forums. You should download and install beta 6 mingw bundle, to make sure we're having the same setup.
So if you do this, you'll have taken the first step in the stairway of the Code::Blocks development team. You wouldn't be "officially" in the team, but more like "fandevs" (invented term of mine), and you would help us a lot! After all, I was a fandev before becoming a team member.
That's cool! About the bundle, I don't use it. I prefer to have codeblocks use my already existing mingw directories.
If you REALLY want to install the bundle, you have to uninstall the other version, and then install the bundle... i think... actually I only tried to download and run once, and I gave up ^^;.
Anyway, good luck, and welcome to the Codeblocks fandev club! :P
let's wait till beta7 is released.I is already released, you probably ment beta8 ;) oops, no, it is an old post :lol:
1. Do you think that it looks promising?
2. Do you think that implementing it as a Code::Blocks plugin would be a good idea / possible?
3. Is there somebody working on something similar?
4. Who would like to team up and develop this beast?
So... welcome to the community,and hopefully, to the team
P.S. Mind telling us where your Code::Blocks review is? ;-)
Implementing it as a plugin is something I would love to give into trusting hands, as learning about the SDK and changing the code should be done by someone who knows what he's doing.hmm. that is not including me :cry: I think I just have to try :lol:
I mean, I do want to share the code (I suppose I get some credit for that), but how can/should we do it? What's your normal procedure? Sourceforge, or just a shared zip?
I'd be willing to do that and maintain the main code base, as I started it and the code sometimes is very "hackerish" (I guess this is normal for such a project, but anyway)
Implementing it as a plugin is something I would love to give into trusting hands, as learning about the SDK and changing the code should be done by someone who knows what he's doing
I want to get some stuff working (like loading a project) before I put the code somewhere.
I think it would be better to make it a custom editor, registered for XRC files (for example). I haven't looked at your code, but to implement a custom editor in C::B, you just inherit from EditorBase (which inherits from wxMDIChildFrame and when we ditch MDI it will inherit from wxPanel). Unless you are doing magic stuff in your initialization code, I believe it should be pretty easy to embed you editor in C::B :D
We can add the code in CVS and you can work from there. This way more people might want to join you :D
And don't forget the motto of open source: release-early, release-often ;)
.
I'm not quite sure I got that, maybe due to my fair knowledge of how C::B was implemented and how the SDK works. Currently the editor is a MDI Frame, too. So you mean I should implement it so that it gets "embedded" into C::B on start? Like adding a toolbar, menu etc. to the main editor?I just played with the plugin generator plugin and saw that it has options for that currently disabled.
Maybe I should comment the code in some places, although I doubt that it will be easy to understand.
To really embed your editor, it can't be an MDI frame. It must be an EditorBase (which is a wxMDIChildFrame for now). Also, until we add a docking library in C::B, your tool windows should have the wxFLOAT_ON_PARENT style flag.
Quote from: upCASEMaybe I should comment the code in some places, although I doubt that it will be easy to understand.
Why not grab Windows Paint (TM) and make a nifty diagram of how the classes work?Quote from: MandravTo really embed your editor, it can't be an MDI frame. It must be an EditorBase (which is a wxMDIChildFrame for now). Also, until we add a docking library in C::B, your tool windows should have the wxFLOAT_ON_PARENT style flag.
And you may also want to take a look at the codecompletion plugin to see how it allocates a tab in the left pane (for the property editor).
Hi,
Thanks for the suggestions! I'll give them some thought.
Making DB into a plugin is non-trivial, and potentially
a distraction from my rather long to-do list, but generating
a CB project should be more do-able.
Regards,
Julian
upCase: your program looks very prommising, hopefully we can get a plugin of it very soon.
First step will be a MIME plugin I guess.
... as you can see in the thread "wxMDIChildframe crash" (can't change the title, sorry :-P )...
I am just following the list, and if I understood things propperly, the code byo is working on, is based on work form upcase (who has no time anymore).
Byo also abandonned his first own attempt for a RAD tool.
The way I got it is that byo is working on a wxFormBuilder plugin
Hmm, upCase's work looks very nice and I hope that there will be a plugin in future allowing to bind it to C::B :).
Uh... weren't you actually working on it? :? NOW I'm confused.
IF nothing will be changed, there will be three different plugins for wxWidget RAD development. Somehow it's good because developers will be able to choose what they want. But shouldn't C::B has one RAD tool system ? And if Yes, which one of projects mentioned above should be used ? (I guess that nobody would like to abandon his project so this may be a serious problem ;) )
Perhaps we could merge the projects, and get the best out of them ?
OK guys. This is serious. I realized that there is NO wxWidgets designer tool in C++. At least not open source.
Hmm, I have one question dedicated to C::B leaders (mandrav, rickg22), what's Your opinion ?
What *particularly* worries me is the object construction handling of events. Byo's approach is to make a derived class out of each widget. While it does work, i'm sure there's an alternative approach, like trapping the events so they won't get to the widgets or something.
What *particularly* worries me is the object construction handling of events. Byo's approach is to make a derived class out of each widget. While it does work, i'm sure there's an alternative approach, like trapping the events so they won't get to the widgets or something. I think I read something in the wxWidgets manual about disabling events for GUI designers (and that's what we're doing, right?)
upCase, how did you implement this part?
Hey,
What happened with the RAD tool... We are all waiting for a release to test it, to give some feedback at least.
Give me some info if there are any news, please.
Thanks a lot.
My current solution: use DialogBlocks until wxSmith gets stable (I'm refering not that it's crashing, but stable on the API and code generation)
////@begin WxCoolBarSampleApp initialisation
// Remove the comment markers above and below this block
// to make permanent changes to the code.
#if wxUSE_GIF
wxImage::AddHandler( new wxGIFHandler );
#endif
wxCoolBarSampleFrame* mainWindow = new wxCoolBarSampleFrame( NULL, ID_FRAME );
mainWindow->Show(true);
////@end WxCoolBarSampleApp initialisation
"RAD tool is included in Windows version of RC2 installer but not selected by default."
....
Man... RAD tool is included on Windows version and not on linux version? ... hmmm :? :cry:
Why?
(wxSmith is not yet included into automake build :()
(wxSmith is not yet included into automake build :()
This is because you 're adding/removing files all the time :)
Seriously, I can (and probably will) add it in the build system but are you willing to add/remove files to/from the build when you change the project? I.e. you will have to keep it in sync with the project files...
mandrav, is it possible to add wxSmith to the automake build and if any changes of the files in the project , we can do manual modification on the wxSmith portion in the automake build script ?