Author Topic: New wxSmith: Testing  (Read 8902 times)

Offline byo

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 837
New wxSmith: Testing
« on: December 23, 2006, 07:49:34 pm »
Hi, everyone.

If someone's interested in new wxSmith status, here's link for precompiled win version that should work with recent nightlies (I've tested it on 18.12 and it worked fine):

http://rapidshare.com/files/8683245/New_wxSmith__rev_3419__-_Testing.7z.html

This version is UNSTABLE and it shouldn't be sued for anything except testing.
New version modifies project and source files so remember to BACKUP YOUR PROJECT before opening it using this wxSmith.
Currently I've successfully converted wxSmith's own project to new format - but I had to fix few bugs to get positive results so there's big chance that by opening your projects other bugs will come out ;)

I'll be unavailable till 10.01 so waiting tor your bug reports ;)

Marry Christmas and Happy New Year :)
     BYO

Offline ocloma

  • Single posting newcomer
  • *
  • Posts: 8
Re: New wxSmith: Testing
« Reply #1 on: December 24, 2006, 05:50:21 am »
congratulations, excellent work!!!!
Marry Christmas!!!!
zenwalk 2.8 (slackware based distribution).

Offline bugmenot

  • Multiple posting newcomer
  • *
  • Posts: 32
Re: New wxSmith: Testing
« Reply #2 on: December 31, 2006, 05:16:18 pm »
I tried the new version and I must say that it runs more stable for me than the old version with newest nightlies. The old version started to crash in many situations with newer Codeblocks versions. I'm using windows.

It certainly is a great improvement over the old version.

One bug I noticed where drawing fragments outside of the current frame. Meaning when for example you remove a control the total size of a frame shrinks in the preview. The frame is correctly drawn however the regions that now lies outside of the frame are not correctly cleared to the background color. This happens in numerous situation so you probably already know about it.

Create a new project and then add a wxSmith frame. In the project manager (that window where you can browse your source files and code completion symbols) go to the "Resources" tab. In the tree you will see a root named "Resources" below it an unnamed element which is the root for all wxSmith resources.

Another more serious bug happens when you often change a sizer property of a control. I tried changing the expand flag check box in both the regular property tab and in the quick property panel and I changed the border size using the increase and decrease buttons in the quick property panel. I clicked the buttons fast about a 50 times. I don't know if the error also happens when pushing them slowly after another. After a number of clicks the drawing starts to lag. I looks like if it remembered all the previous states (undo level?) and would draw then first before drawing the final state. When now exiting Codeblocks you might get lucky and nothing happens or it just crashes but most of the time the following assertion is triggered:
Quote
File: wxscoder.cpp
Line: 39

Expression: EM != NULL

When toggling the "Is member" check box the preview frame is redrawn. This is not necessary. 

When adding a bitmap button and loading the image from a file the following code is generated:
Code: [Select]
wxSize StaticBitmap1_Size = wxDefaultSize;
StaticBitmap1 = new wxStaticBitmap(this,ID_STATICBITMAP1,wxBitmap(_("..."));
,wxDefaultPosition,StaticBitmap1_Size,0,_T("ID_STATICBITMAP1"));
Obviously one ";" is too much.
http://www.wxwidgets.org/manuals/2.6.3/wx_wxbitmap.html#wxbitmapctor
Quote
Under Windows, type defaults to wxBITMAP_TYPE_BMP_RESOURCE. Under X, type defaults to wxBITMAP_TYPE_XPM.
However we want to read an image from a file so that wont work. I don't know how you can make it so that wxWidgets loads a file and auto-detects the type so I'd suggest looking at the extension and then passing wxBITMAP_TYPE_BMP/wxBITMAP_TYPE_GIF/... as second parameter. Perhaps even adding an option to the bitmap selector dialog to indicate the type if for example the files have non standard extension or even wrong extensions.

Also the bitmap selector dialog crops the bitmap down in the preview, perhaps shrinking would be a better options. Also it is currently not possible to load resources. (It would be great if wxSmith or another plugin could manage those.)

I didn't quiet understand how the font selector dialog works, is it already fully functional? Anyway it might be a good idea to allow the user to specified the example text (well he'll see how it looks in the preview anyway so it might not be a so good idea after all). Anyway you're using wxSystemSettings::GetFont but didn't include <wx/settings.h>.

When removing controls the corresponding headers are no longer included. However it's possible that these headers provided the declarations for the events of some handlers. The easiest fix would be to include the needed headers outside of the //(*Headers(...)//*) tags when a handler is added. This way they are included twice and when the control is removed the version outside of the //(*Headers(...)//*) tags is still there.

When adding a StdDialogButtonSizer and adding ok and yes buttons they are placed over another. (This might be wx bug and not a wxSmith one.)

By changing the wxSP_3D style of a wxSplitterWindow the preview window give the splitter too much space. The space for the border is there but it isn't used as I have unset wxSP_3D. Perhaps move wxSplitterWindow to the layout category.

That's all I could find for bugs. However I would have a few suggestions.

In the regular property editor some can have only a predefined number of values. (For example "Horizontal align" can only have 3 values.)
Delphi changed the value to the next in the list when just double clicking (no need to select in the drop down box). I found that pretty handy.

Make the delete key delete the currently selected control.

By default make controls expand.

I really loved how under Delphi double clicking a button in the preview generated the click handler and scrolled to the right position in the source code. Perhaps add a line:
Code: [Select]
//(*Handler(Foo)*)when generating a handler so that it's possible to scroll to the right place by just double clicking the control in the preview.

Add some possibility to move controls around in the tree and not only in the preview. Make it possible to move sizers around with all the controls they contain.

Allow to specify the creation code for custom widgets somewhere centrally. You add a new control to a list then add the creation code, the name and specify a bitmap which will be used to fill out the region in the preview.


Anyway even if it still needs some polishing wxSmith is already great as it is. Keep up the good work.

Offline byo

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 837
Re: New wxSmith: Testing
« Reply #3 on: January 08, 2007, 08:25:46 pm »
Thx bugmenot for your work. It's really proceless for me :)

I'll start working on most of issues presented here as soon as possible :)

Offline byo

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 837
Re: New wxSmith: Testing
« Reply #4 on: January 13, 2007, 01:37:14 pm »
few bugs fixed. Here's new version working with 10.01.07 nightly:

http://wxsmith.ovh.org/builds/wxSmith_rev3481.7z

Here's some changelog since last version (available in this topic):
  • Fixed bugs in editor preview generation - no more blinks or artifacts
  • Fixed wxStaticBitmap and wxBitmapButton widgets
  • Fixed few bugs in font property - it now works properly
  • Replaced previous font editor with simplified dialog (previous editor is available under advanced options)

Few bugs which I hadn't remove beacause of some problems:
  • Bug with "EM != NULL" assertion - I've never got this so I couldn't find the reason of this failure
  • Toggling "Is Member"  and changing few other properties still cause editor to refresh (it would require some bigger changes in property system so maybe in future). Since there's no blinkink bug, it should not be frustrating ;)
  • No support for resources
  • Problem with headers for handler functions - this will be quite hard to fix (need to parse handlers list, check what headers are required for handler arguments). Fortunately as long as pch is used, absent headers are no problem

Regards
   BYO

Offline bugmenot

  • Multiple posting newcomer
  • *
  • Posts: 32
Re: New wxSmith: Testing
« Reply #5 on: January 13, 2007, 08:44:15 pm »
Please put back in the popup showing when that the wxsmith version is expreimental and not for production purpose. One knew the moment one started Code Blocks that the extension was correctly installed. ;)

Bugs:
- When selecting a non wxsmith tab in the editor (such as for example a *.cpp file) then going into the resource tree and double clicking on a frame will bring the *.wxs to the front in the editor. However this does not work if you double click any of the sub widgets of a frame such as for example a button.
- When deleting the last subwidget of a box sizer the sub widget is deselected in both resource tree and preview window. Then it is deleted. Now nothing is selected in the preview window. In the resource tree the sizer gets a different background color (However a third one different from not selected and explicitly selected). Clicking on the sizer in the resource tree will make the back color change to "selected" in the tree but it will not be selected in the preview. It is not possible to add any widgets to the sizer. The solution is to either select the sizer in the preview or select something different in the tree and then select sizer again in the tree.
- In the property tab the new font element is simpler to use in my opinion than the old. However there is a bug : The font property is mad up of a tree : root with a name that resumes the settings. 2 childes one being a check box defining if a non default font should be used an another sub tree with the non default font details. The problem is that the name of the root element is editable. Editing it wont hurt as it is always automatically reset to the previews state but perhaps it might be better to make it non editable. Also if the default font is used then it might be a better idea to change the whole description to "default font" instead of "FALSE [... a lot of not used stuff...]".
- There's a probably hard to solve problem with the bitmap buttons (or any bitmap resource) in combination with the MinGW compiler and non English Windows versions (probably also non English Linux but didn't try). Files or path may contain non standard characters such as "θιδφίκ". The code is generated correctly. However it wont compile with the following error:
Quote
converting to execution character set: Illegal byte sequence
Probably only 7bit ANSI characters are allowed in string literals but I haven't tested it.
- When a wxBitmap widget with a bigger image than the working area is created or moved the preview window is not correctly updated when scrolled. This does not happen if the widget hasn't been recently changed.
- wxSplitterWindow also doesn't always correctly distribute its client area between its childs:

I don't know under which circumstances this happens however I could produce it fairly often unwillingly so you should be able to reproduce it by playing around with the control. Also I think that wxSplitterWindow is more a sizer than a control so I'd place it under the Layout tab with all the other sizers.
- Under Windows when moving another window of another program over the preview window then it's always completely updated and flashes quiet a bit. Nothing serious but you might consider limiting the redraws per second.

Quote
Bug with "EM != NULL" assertion - I've never got this so I couldn't find the reason of this failure
I can't reproduce it either with the new version. Probably it was caused by the same code which caused the fragments.
Quote
Toggling "Is Member"  and changing few other properties still cause editor to refresh (it would require some bigger changes in property system so maybe in future). Since there's no blinkink bug, it should not be frustrating
No it's not frustrating at all. Just wanted to point it out. ;)

Quote
Problem with headers for handler functions - this will be quite hard to fix (need to parse handlers list, check what headers are required for handler arguments). Fortunately as long as pch is used, absent headers are no problem
I think you didn't understand what I suggested. You have for example the following code:
Code: [Select]
//(*Headers(NewFrame)
#include <wx/textctrl.h>
#include <wx/button.h>
#include <wx/frame.h>
//*)
Now I add a wxTextCtrl only handler. Meaning one which needs an event defined in that header. Now change the header code to the following:
Code: [Select]
#include <wx/textctrl.h>
//(*Headers(NewFrame)
#include <wx/textctrl.h>
#include <wx/button.h>
#include <wx/frame.h>
//*)
Doesn't look great but when the wxTextCtrl is removed you are left with
Code: [Select]
#include <wx/textctrl.h>
//(*Headers(NewFrame)
#include <wx/button.h>
#include <wx/frame.h>
//*)
and the code still compiles.

Quote
Replaced previous font editor with simplified dialog (previous editor is available under advanced options)
Where are those advanced options?

Anyway the new version ran pretty stable and didn't crash.

Offline Grom

  • Almost regular
  • **
  • Posts: 206
Re: New wxSmith: Testing
« Reply #6 on: January 15, 2007, 07:46:58 pm »
I tested new version of wxSmith. Still there are the same problems:
1. Components have no their names under the components icons.
2. There are no SatusBar, TooolBar and Menu and PopUp Menue. (I would say that is extremely important to have them)
3. Seems to be Byo works along.

Conclusion:
Today it is more important to have a good IDE for automatic GUI development with UML support then nice coding engine with fancy interface. With that strategy Code::Blocks project may have serious problems. Even I don't speak about rc3... (Just take a look on to wxDevCpp). CB in troubles... :(
gcc+winXP+suse.

Offline joubertdj

  • Multiple posting newcomer
  • *
  • Posts: 120
Re: New wxSmith: Testing
« Reply #7 on: January 16, 2007, 10:07:31 am »
Quote
Today it is more important to have a good IDE for automatic GUI development with UML support then nice coding engine with fancy interface. With that strategy Code::Blocks project may have serious problems. Even I don't speak about rc3... (Just take a look on to wxDevCpp). CB in troubles... Sad

 :) Cool... so you are going to help us in writing C::B to achieve those goals?

Offline Grom

  • Almost regular
  • **
  • Posts: 206
Re: New wxSmith: Testing
« Reply #8 on: January 16, 2007, 06:28:50 pm »
I will try to find time to do that.  :?... I have 5 projects right now...
gcc+winXP+suse.

Offline byo

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 837
Re: New wxSmith: Testing
« Reply #9 on: January 16, 2007, 07:49:54 pm »
I tested new version of wxSmith. Still there are the same problems:
1. Components have no their names under the components icons.
2. There are no SatusBar, TooolBar and Menu and PopUp Menue. (I would say that is extremely important to have them)
3. Seems to be Byo works along.

Yup, but all these are new features not supported in old wxSmith also. Current roadmap is:
* Get all old wxSmith functionality
* Fix as much bugs as possible
* Merge new version into trunk and destroy/forget about/anything else to throw away ;) the old code
* Start working on new features

So, we're at the second point. And as long as wxSmith is not included inside nightlies, it won't have many new things.
And the fact that I'm working alone (I hope I've understood you correctly ;)) is nothing new to me and to wxSmith from the very beginning of the code. But I've thought about other workers during rewrite and hopefully it will be much easier to work with other people here (I mean in new wxSmith framework code) :)

Quote
Conclusion:
Today it is more important to have a good IDE for automatic GUI development with UML support then nice coding engine with fancy interface. With that strategy Code::Blocks project may have serious problems. Even I don't speak about rc3... (Just take a look on to wxDevCpp). CB in troubles... :(

Ok, maybe it's not objective point of view, but I think that wxSmith is not so important for C::B as it may look like. It may be replaced with other tools (like wxFormBuilder, wxGlade and many others). It's not so hard to make C::B cooperate with them, and the time needed to learn how to use these tools shuld be no more than few hours.
And there's no UML plugin worked on right now AFAIK :(.

So maybe C::B is in trouble but this is open-source. We do not lose any money, we do not lose jobs if we fail. We simply give you all we can. And if it's not enough, so... we do not keep anyone tighed to this IDE.

Ok, but Grom some important issue. So here's my question:

Is there anyone interested in helping me with wxSmith?
C++ and any knowledge about wxWidgets appreciated :)

If someone is interested in making some graphic for wxSmith
(mostly icons, buttons etc) I would also be grateful for this
kind of help :)


Ok, maybe few answers to bugemnot's last bug report:

I haven't removed warning message, it shuold be displayed as usual (or maybe I've messed something up, but I got this message on my PC).

Only selecting resource item in resource browser causes editor to be switched.
But I may change it.

Problem with invalid code is known to me but it may require some hard work to fix - sometimes it's caused by problems with encoding in C::B. Try switching encoding in options, maybe that will help.

The problem with header still remains. Currently I don't see easy solution (you one is simple and suffixient but hard to implement). Currently I'll leave this bug open.

Regards
   BYO

Offline mike__t

  • Multiple posting newcomer
  • *
  • Posts: 11
Re: New wxSmith: Testing
« Reply #10 on: January 28, 2007, 06:15:03 am »
The new version seems to work a lot better on Linux, although the select handles seemed to get out of position with the controls on occasion.

Just out of curiousity, will xrc import be returning?

Online stahta01

  • Lives here!
  • ****
  • Posts: 7018
    • My Best Post
Re: New wxSmith: Testing
« Reply #11 on: February 01, 2007, 01:29:25 am »
I was patching code in prep for testing wxWidgets 2.9 cvs and found something that looks strange.

Should you not be using "wxSAVE|wxOVERWRITE_PROMPT" instead of "wxOPEN|wxOVERWRITE_PROMPT"?

Tim S

wxSmith\wxwidgets\wxwidgetsguiappadoptingdlg.cpp:245
Code: [Select]
void wxWidgetsGUIAppAdoptingDlg::OnCreateBtnClick(wxCommandEvent& event)
{
    wxString FileName = ::wxFileSelector(
        _("Please select cpp file where application class should be created"),
        m_GUI->GetProjectPath(),
        _T("myapp.cpp"),
        _T("cpp"),
        _T("C++ source files|*.cpp|All files|*"),
        wxOPEN|wxOVERWRITE_PROMPT);
« Last Edit: February 01, 2007, 01:33:28 am by stahta01 »
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 32 bit.
On Debian Stretch, compiling CB Trunk against wxWidgets 3.0.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline byo

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 837
Re: New wxSmith: Testing
« Reply #12 on: February 01, 2007, 09:21:13 pm »
I was patching code in prep for testing wxWidgets 2.9 cvs and found something that looks strange.

Should you not be using "wxSAVE|wxOVERWRITE_PROMPT" instead of "wxOPEN|wxOVERWRITE_PROMPT"?

Tim S

Yes, obviously a bug :) Already fixed in svn

The new version seems to work a lot better on Linux, although the select handles seemed to get out of position with the controls on occasion.

Just out of curiousity, will xrc import be returning?


I'll code XRC importing but I thought about something different than in previous wxSmith. I'll start coding it somewhere in next month probably. Now you can do some trick:
If you have f.ex. wxFrame, create select new wxFrame from wxSmith menu, check Use XRC, enter name of xrc file what you want to import and set name of class to name of resource (name parameter in XRC file of root <object> node). Then it will use data from this xrc file.

BYO