About wxSmith development

[Grom]

We use UML for development planing. That is ok to start without diagram some small programming project. But, If you are developing back bone of a huge comput math project - you have to use UML. We can decide what we will do only after a serious discussions of a diagram of classes which should cover large set of problems. Specially in case if you start international project and you can't meet other side near the same blackboard.
UML inside codeblocks will bring a lot of people, include students who always want to do something and try them self on real projects.

[MortenMacFly]

UML inside codeblocks will bring a lot of people, include students who always want to do something and try them self on real projects.

Yes, but not if the UML diagrams cannot be sync'd in both directions. Otherwise one could use an external tool, as well -> sync'ing into the sources which compile with C::B.
With regards, Morten.

[byo]

... But, If you are developing back bone of a huge comput math project - you have to use UML....

Yup, agree. I was really against UML some time ago. I thought that only adventage of it was class diagram because it allowed me to create code skeleton faster than usual. But in big group of developers where everyone want to show his idea in his personal way, expecially if workign on some bigger project one unified language is necessary compromise. Even now I don't like few things in UML, but maybe because I've never worked on really huge project

Ok, but back to the subject of this thread:

I've finished adopting ALL widgets from old wxSmith to new one. That means that all major goals of rewrite has been reached. New version still misses few functions but it's usable.

Now it's time for testing and bug-hunting

[takeshi miya]

New version still misses few functions but it's usable.

Now it's time for testing and bug-hunting

Great news

[Christiaan]

Great work 

Compiled it from SVN and it works better then the old wxSmith.

Opened a old wxSmith project and found a couple of small bugs.

Notebook->AddPagePanel1,_("My Page"),false);
There is a "(" missing between AddPage and Panel1

In file wxnotebook.cpp on line 261 changing:
Code << GetVarName() << _T("->AddPage")
to:
Code << GetVarName() << _T("->AddPage(")
seams to fix the problem

undefined reference to `MainFrame::ID_NOTEBOOK1'
The //(*IdInit(NewFrame) section is missing possible a conversion error.

After adding:
//(*IdInit(MainFrame)
//*)
to my mainframe.cpp the IdInit was generated and my project compiled without errors.

[byo]

Opened a old wxSmith project and found a couple of small bugs.

Notebook->AddPagePanel1,_("My Page"),false);
There is a "(" missing between AddPage and Panel1

In file wxnotebook.cpp on line 261 changing:
Code << GetVarName() << _T("->AddPage")
to:
Code << GetVarName() << _T("->AddPage(")
seams to fix the problem

Yop, you're right I haven't tested that code yet (same bug was in wxChoicebook and wxListbook).

undefined reference to `MainFrame::ID_NOTEBOOK1'
The //(*IdInit(NewFrame) section is missing possible a conversion error.

After adding:
//(*IdInit(MainFrame)
//*)
to my mainframe.cpp the IdInit was generated and my project compiled without errors.

I've already fixed that, in fact there's another section missing:

//(*InternalHeaders(MainFrame)
//*)

to make it working in all cases. wxSmith shuld do the conversion automatically

Thx for your report (I desperately need such reports right now )

Regards
  BYO

[nottin]

Getting this error when building new wxSmith:

 g++ -DHAVE_CONFIG_H -I. -I../../../../../../../src/plugins/contrib/New_wxSmith/wxwidgets/defitems -I../../../../../../src/sdk -I/usr/local/lib/wx/include/gtk2-unicode-release-2.8 -I/usr/local/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread -I../../../../../../../src/sdk -I../../../../../../../src/sdk/wxFlatNotebook/include -I../../../../../../../src/sdk/wxscintilla/include -I../../../../../../../src/sdk/wxFlatNotebook -I../../../../../../../src/sdk/propgrid/include -O2 -ffast-math -g -O2 -DCB_PRECOMP -Winvalid-pch -fPIC -DPIC -MT wxsdatepickerctrl.lo -MD -MP -MF .deps/wxsdatepickerctrl.Tpo -c ../../../../../../../src/plugins/contrib/New_wxSmith/wxwidgets/defitems/./wxsdatepickerctrl.cpp  -fPIC -DPIC -o .libs/wxsdatepickerctrl.o
../../../../../../../src/plugins/contrib/New_wxSmith/wxwidgets/defitems/./../wxsevents.h:114: error: 'wxArrayString' does not name a type
../../../../../../../src/plugins/contrib/New_wxSmith/wxwidgets/defitems/./../wxsevents.h: In member function 'const wxString& wxsEvents::GetHandler(int)':
../../../../../../../src/plugins/contrib/New_wxSmith/wxwidgets/defitems/./../wxsevents.h:80: error: 'm_Functions' was not declared in this scope
../../../../../../../src/plugins/contrib/New_wxSmith/wxwidgets/defitems/./../wxsevents.h: In member function 'void wxsEvents::SetHandler(int, const wxString&)':
../../../../../../../src/plugins/contrib/New_wxSmith/wxwidgets/defitems/./../wxsevents.h:83: error: 'm_Functions' was not declared in this scope
make[2]: *** [wxsdatepickerctrl.lo] Error 1
make[2]: Leaving directory `/home/bjorn/dev/apps/codeblocks/build/src/plugins/contrib/New_wxSmith/wxwidgets/defitems'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/bjorn/dev/apps/codeblocks/build/src/plugins/contrib/New_wxSmith/wxwidgets'
make: *** [all-recursive] Error 1

using wxWidgets 2.8.1 on Ubuntu 6.10 (Edgy Eft)

[stahta01]

Getting this error when building new wxSmith:

 g++ -DHAVE_CONFIG_H -I. -I../../../../../../../src/plugins/contrib/New_wxSmith/wxwidgets/defitems -I../../../../../../src/sdk -I/usr/local/lib/wx/include/gtk2-unicode-release-2.8 -I/usr/local/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread -I../../../../../../../src/sdk -I../../../../../../../src/sdk/wxFlatNotebook/include -I../../../../../../../src/sdk/wxscintilla/include -I../../../../../../../src/sdk/wxFlatNotebook -I../../../../../../../src/sdk/propgrid/include -O2 -ffast-math -g -O2 -DCB_PRECOMP -Winvalid-pch -fPIC -DPIC -MT wxsdatepickerctrl.lo -MD -MP -MF .deps/wxsdatepickerctrl.Tpo -c ../../../../../../../src/plugins/contrib/New_wxSmith/wxwidgets/defitems/./wxsdatepickerctrl.cpp  -fPIC -DPIC -o .libs/wxsdatepickerctrl.o
../../../../../../../src/plugins/contrib/New_wxSmith/wxwidgets/defitems/./../wxsevents.h:114: error: 'wxArrayString' does not name a type
../../../../../../../src/plugins/contrib/New_wxSmith/wxwidgets/defitems/./../wxsevents.h: In member function 'const wxString& wxsEvents::GetHandler(int)':
../../../../../../../src/plugins/contrib/New_wxSmith/wxwidgets/defitems/./../wxsevents.h:80: error: 'm_Functions' was not declared in this scope
../../../../../../../src/plugins/contrib/New_wxSmith/wxwidgets/defitems/./../wxsevents.h: In member function 'void wxsEvents::SetHandler(int, const wxString&)':
../../../../../../../src/plugins/contrib/New_wxSmith/wxwidgets/defitems/./../wxsevents.h:83: error: 'm_Functions' was not declared in this scope
make[2]: *** [wxsdatepickerctrl.lo] Error 1
make[2]: Leaving directory `/home/bjorn/dev/apps/codeblocks/build/src/plugins/contrib/New_wxSmith/wxwidgets/defitems'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/bjorn/dev/apps/codeblocks/build/src/plugins/contrib/New_wxSmith/wxwidgets'
make: *** [all-recursive] Error 1

using wxWidgets 2.8.1 on Ubuntu 6.10 (Edgy Eft)

The patch for the new wxSmith is here; note, the OLD wxSmith is already patched.
  [ Patch #1766 ] NEW (experimental) wxSmith patch for wxWidgets 2.8 Submitted By: stahta01
   https://developer.berlios.de/patch/?func=detailpatch&patch_id=1766&group_id=5358
  How to get the new wxSmith is here
   http://forums.codeblocks.org/index.php?topic=3765.msg33855#msg33855

Have you applied my wxWidgets 2.8 patch?
See thread http://forums.codeblocks.org/index.php?topic=4495.0

Please post the link errors against wxWidgets 2.8 in my thread http://forums.codeblocks.org/index.php?topic=4495.0

Note: I have NOT tested my patch on the new wxSmith in the last two weeks if it has an compile or link error please post it in my thread and I will check it out. Note, I don't use wxSmith so don't ask me to do testing of it.

Tim S

[byo]

New wxSmith has just been merged into trunk. It should be available with next nightly.
Remember to save project right after converting to new format
Unfortunately I've yet found two bugs during convertion from old format to new one. So please take this into consideration:

• If you have different projects for win and linux, open them both and save. Then search for duplicated //(*InternalHeaders and //(*IdInit section in sources - it's added twice since sources are processed two times. Just remove one of them
• //(*InternalHeaders may be placed just at the beginning of file (it will compile but usually first include should be corresponding header file). In this case just move section into proper location

I'll probably fix these bugs on Monday so Sunday will have to be little "buggy"

Here's short log what's in new wxSmith comparing to old one:

• Totally rewritten framework. This one is much more stable and easier to extend
• Project wizard removed. wxSmith can now use standard wxWidgets project and convert project to make it compatible with wxSmith
• IMPORTANT!!! Event handlers are now connected using Connect() method instead of event tables. This mean that EVENTS ARE NOT PROCESSED WHILE CREATING WINDOW. Previously when some foo->SetValue() or something simillar was called during initialization it could throw events
• Data is no longer duplicated in wxs file when resource uses xrc
• There's ability to use one xrc for few resources
• New drag assist - when changing position inside sizer, only one half of destination item is highlighted. If it's left one, dragged item wil be placed before destination item, if right one, item will be added after it.
• Identifiers are now created using wxNewId() instead of enums. This prevented duplicating identifiers when added panel resource into other one
• Some automatically-generated headers are put into cpp file instead of header (this may speed up compilation time in some cases)

Source code for resources will be automatically regenerated when opening resource's editor for the first time (after conversion).

I hope you'd like this new "smithy"
Regards

   BYO

[Grom]

Cool, thanks a lot!!!
When we will have statusbar, toolbar and menu? Is that new wxSmith expandable to add those components? If yes... This is not a problem

[Michael]

I hope you'd like this new "smithy"
Regards

   BYO

Great job Byo .

Best wishes,
Michael

[byo]

Cool, thanks a lot!!!
When we will have statusbar, toolbar and menu? Is that new wxSmith expandable to add those components? If yes... This is not a problem

Sure, it should not be hard to add. I have got some generic idea on how to implement them already. The only thing that I'm worried about is that XRC standard doesn't support these extra things directly from frame/dialog. So there's possibility that it will be available only without XRC file (of course I'll add ability to edit it as separate resource )

[byo]

Ok, wxMenuBar, wxToolBar and wxStatusBar are now supported. wxToolBar class may still have some serious bugs, I haven't tested it very well but for simple tasks (like creating toolbar with few icons) it worked fine.

There are still few things in my (and probably yours) wishlist: most important one is to add any preview inside editor (currently new items can be edited by double-clicking on it's icon in tools list or through resource and property browser), second thing is to add images support into menus. Third one will be to create separate resources for items, but this may be delayed a little bit becuase of first two "wishes" and some other things planned.

In the meantime I've checked xrc sources better and they support loading wMenuBar, wxToolBar and wxStatus directly into frame without need of external resource so also xrc-based resources support them.

If someone is interested in what's really going on in wxSmith, I've made some small web page wxsmith.ovh.org - this is only a scratch-pad I've written when I was sick of c++ and wanted to write something in some other language Please do not consider it as a competition to forum, most things should go here, but I've thought that putting all that details into forum would be just messy.

Regards
  BYO