Code::Blocks Forums

Developer forums (C::B DEVELOPMENT STRICTLY!) => Plugins development => Topic started by: seb_seb0 on April 10, 2010, 09:27:59 pm

Title: wxSmith improvement
Post by: seb_seb0 on April 10, 2010, 09:27:59 pm
Hello,

after using wxSmith for several projects, I can make the following comments on it.
However, before going forward, I want to make the following remarks:
  
  - these are not critics. These are only ways to improve an already very useful plugin. It is my GUI designer of choice when making wxWidgets application
  - the remarks below represents the view of only 1 person (me) - and I am not even a professionnal programmer (I use it at work however, and for hobbies). Programming is only a part of my work.
  - I am volunteer to make the changes. I will however not give you a timetable, because I do not know what will be my spare time in 3 months...
 

  Here we go:
   Improvement in functionnality:
     - unify all the additionnal wxSmith contrib items in 1 single plugin. I have listed the following
            wxAUI
            wxSTC
            wxMathPlot
            wxSpeedButton
            wxTreeListControl (very useful !)
            wxImage (very useful ! wxImageList & wxBitmapComboBox are easier to use with it)
            wxContribItems
            ...
     - ToolBar editor: it is currently not possible to add a control in the toolbar. It has to be done manually
     - Menu editor: it is currently not possible to add images to menu
     - There are currently no Image Editor (for Toolbar icons, for bitmap buttons, ...)
        I have already started to program an Image Editor plugin (see http://forums.codeblocks.org/index.php/topic,12293.msg83901.html#msg83901 (http://forums.codeblocks.org/index.php/topic,12293.msg83901.html#msg83901))
     - Multi Selection / Copy / Paste: it is currently not possible to copy a set of widgets from one wxPanel/wxDialog/wxFrame to another (or if it is, it does not work properly, or I am not using properly)
    - Custom Control: this one is very useful. One thing is currently missing: adding events handlers to the control.
    - Add missing widgets from wxWidgets 2.9.0 (wxToggleBitmapButton, wxWrapSizer, ...) and wxCode
    - maybe create an option for using wxWidgets 2.8.10 or 2.9.0
    - apply the wxGLCanvas patch if not done already
      http://forums.codeblocks.org/index.php/topic,12176.msg82726.html#msg82726 (http://forums.codeblocks.org/index.php/topic,12176.msg82726.html#msg82726)
    - wxGrid : wxWidgets 2.8.10: EVT_GRID_CMD_CELL_CHANGE
                  wxWidgets 2.9.0 :  EVT_GRID_CMD_CELL_CHANGED (leads to a compile error)
    - It should be possible to add a widgets by clicking on the tool to add, and then select the resource tree.

Improvements in interface :
    - create groups in the wxPropertyGrid for gathering together by themes the properties
      example: add a Sizer group
                   style property: add 1 group per hierarchy level (1 for wxWindow, 1 for wxControl, ...)
      This feature is available in wxFormBuilder

Let me know what you think about these suggestions. If you disagree, let me know !
Again, I want to be constructive, and I am ready to discuss on all these topics.

Sebastien
Title: Re: wxSmith improvement
Post by: mariocup on April 10, 2010, 11:33:32 pm
Hello seb_seb0,

some time ago I discussed with byo some other ideas to improve wxsmith. Perhaps you will find some of them strange, but have a look:

1. For example if you use a combo box and then decide to use a choice box, then it should be possible to convert different elements. Currently you can change in the resource editor only the class name but the event list "{}-icon" and the wxs file will not be updated.

2. Create an array of elements (e.g. 5 check boxes) and increment the ids.

3. For example if you want that some combox boxes in a dialogue are left aligned it should be possible to select different elements and assign a "common" configuration.

4. A mechanism to clone elements, so that if you change the settings of the original object (e.g. alignment) then all clones are updated.

5. Some kind of grouping feature if you want to move elements to a different sizer or assign a common configuration (all right aligned).

6. Drag and drop functionality in the resources tree view, so that elements e.g. a label can be moved easily to a different sizer.

7. The resource description is a xml file. What would be cool is to have a kind of comment out functionality. For example you have a dialogue and want to redesigning it or want to keep some elements. So if you comment them out they will be disabled in the xrc file, but they could be used in the future by enabling them again. A different solution could be to move the elements to a "trash folder or archive" icon.

8. Library of elements. It should be possible to save different elements with a user defined name as a "new library element". So these library elements are available for further projects.

9. A picker to get the properties of an element and the possibiltiy to assign it to a different element

Regards,

Mario
Title: Re: wxSmith improvement
Post by: Ganbito on April 12, 2010, 04:57:39 pm
There are several ideas that sounds good. In fact, wxAui isn't complete, but there is a matter of time to work on it (and even on wxSmith, wich needs some improvements to finish the wxAui plugin).

I agree with you in the toolbar editor. It is useful, but not complete, or as intuitive as the rest of wxSmith. That's the reason why I have designed the auiToolbar with a different approach. I wanted also the auiToolbar to support controls and I think that I did it quite well. I think the toolbar can be redesigned in a similar way.

Also all critics to wxAui are welcome. I hope to complete it someday in the future.
Title: Re: wxSmith improvement
Post by: rcoll on April 13, 2010, 05:06:47 pm

  Here we go:
   Improvement in functionnality:
     - unify all the additionnal wxSmith contrib items in 1 single plugin. I have listed the following
            wxAUI
            wxSTC
            wxMathPlot
            wxSpeedButton
            wxTreeListControl (very useful !)
            wxImage (very useful ! wxImageList & wxBitmapComboBox are easier to use with it)
            wxContribItems
            ...
   

Er... wxImage?  Do you have a visual component or tool for that on your wxSmith pallette?  Or do you mean, you would like to see one created?

Ringo
Title: Re: wxSmith improvement
Post by: MortenMacFly on April 13, 2010, 05:08:47 pm
Er... wxImage?  Do you have a visual component or tool for that on your wxSmith pallette?  Or do you mean, you would like to see one created?
Nope, such wxSmith plugin exists. It wraps wxImage, wxImageButton, wxImageComboEditDialog and some more.
Title: Re: wxSmith improvement
Post by: seb_seb0 on April 13, 2010, 11:31:54 pm
Er... wxImage?  Do you have a visual component or tool for that on your wxSmith pallette?  Or do you mean, you would like to see one created?
Nope, such wxSmith plugin exists. It wraps wxImage, wxImageButton, wxImageComboEditDialog and some more.

I confirm.
Here is the source code.

It allows to edit visually an wxImageList, and provide easier access to wxImage index for wxTreeCtrl, wxBitmapComboBox,...
I do not remember who did it, but a search in the Plugin forum will tell you who is the author (not me).

Sebastien


[attachment deleted by admin]
Title: Re: wxSmith improvement
Post by: seb_seb0 on April 13, 2010, 11:38:33 pm
Thank for the answers.
Once I have finished the Image Editor plugin, I think I will start on updating the Toolbar editor and applying the patch from Cryogen.

Unless someone does it before me !
Title: Re: wxSmith improvement
Post by: seb_seb0 on April 13, 2010, 11:39:32 pm

  Here we go:
   Improvement in functionnality:
     - unify all the additionnal wxSmith contrib items in 1 single plugin. I have listed the following
            wxAUI
            wxSTC
            wxMathPlot
            wxSpeedButton
            wxTreeListControl (very useful !)
            wxImage (very useful ! wxImageList & wxBitmapComboBox are easier to use with it)
            wxContribItems
            ...
   

Er... wxImage?  Do you have a visual component or tool for that on your wxSmith pallette?  Or do you mean, you would like to see one created?

Ringo


It is you who created it !
See your post:
http://forums.codeblocks.org/index.php/topic,10428.0.html (http://forums.codeblocks.org/index.php/topic,10428.0.html)

I was refering to this one.

Title: Re: wxSmith improvement
Post by: rcoll on April 14, 2010, 07:29:48 am

It is you who created it !
See your post:
http://forums.codeblocks.org/index.php/topic,10428.0.html (http://forums.codeblocks.org/index.php/topic,10428.0.html)

I was refering to this one.


Oh, man!  This is great -- I had lost this code some time ago (facility fire) and had only a non-working beta copy of it.  Thanks for saving it!

Ringo
Title: Re: wxSmith improvement
Post by: MortenMacFly on April 14, 2010, 08:26:38 am
Oh, man!  This is great -- I had lost this code some time ago (facility fire) and had only a non-working beta copy of it.  Thanks for saving it!
You'd better ask here. I have a copy myself, even improved to be easily integrated into our SVN. Next time remember that the C::B community has a good brain. ;-)
Title: Re: wxSmith improvement
Post by: Cryogen on May 15, 2010, 04:31:52 am

 Hi Guys,

I'm also playing around with some add-ons and patches for wxSmith, so I thought I'd chime in.

Quote
  - unify all the additionnal wxSmith contrib items in 1 single plugin. I have listed the following

I guess there are arguments both ways for this. I'd certainly like to see the contrib items in wxSmith and am working on them, too. In some cases, it might be better to keep a package as a separate add-on so that users can omit it if they don't use that package.
I would like to see the existing controls ordered more logically, perhaps alphabetically.

I've set up a site for my work at http://wxsmithaddons.sourceforge.net/ (http://wxsmithaddons.sourceforge.net/). I'd be happy to work in with you guys so we all work towards the same ends.

Cheers,

  Cryo.
Title: Re: wxSmith improvement
Post by: MortenMacFly on May 16, 2010, 08:11:03 pm
I've set up a site for my work at http://wxsmithaddons.sourceforge.net/ (http://wxsmithaddons.sourceforge.net/). I'd be happy to work in with you guys so we all work towards the same ends.
That's great stuff! Don't think it not being noticed. :-)
Title: Re: wxSmith improvement
Post by: Cryogen on May 17, 2010, 04:27:54 am

 Thanks, Morten. That's great.

Cryo.
Title: Re: wxSmith improvement
Post by: seb_seb0 on May 17, 2010, 10:20:43 pm

 Hi Guys,

I'm also playing around with some add-ons and patches for wxSmith, so I thought I'd chime in.

Quote
  - unify all the additionnal wxSmith contrib items in 1 single plugin. I have listed the following

I guess there are arguments both ways for this. I'd certainly like to see the contrib items in wxSmith and am working on them, too. In some cases, it might be better to keep a package as a separate add-on so that users can omit it if they don't use that package.
I would like to see the existing controls ordered more logically, perhaps alphabetically.

I've set up a site for my work at http://wxsmithaddons.sourceforge.net/ (http://wxsmithaddons.sourceforge.net/). I'd be happy to work in with you guys so we all work towards the same ends.

Cheers,

  Cryo.


Hello,
thank you for replying.

Quote
Quote
  - unify all the additionnal wxSmith contrib items in 1 single plugin. I have listed the following

I guess there are arguments both ways for this.

I have 3 arguments for regrouping the wxSmith extension in as few plugins as possible:
   - it is easier to manage for the end-user (less plugins listed in the Manage Plugins dialog boxes, better organization of the wxWidgets palette , ...)
   - it is easier for the end-user to have a quick overview of all the widgets available. A big advantage of a RAD editor such as wxSmith is the ability to test quickly several widgets, and decide how to implement a desired GUI feature.
     The bigger the palette, the faster the process is.
     You save time, because you do not need to spend countless hours on wxCode, download a potentially good control, spend a few hours to adapt it to your configuration, and finally see it is not exactly what you need.
   - it avoids duplicate efforts from several devoloppers. There are several contributors to wxSmith - I have downloaded several of them, but for example, I was not aware that you started wxKWIC extension.
      For this reason, I think that centralizing the wxSmith extensions is a good idea.

Quote
I would like to see the existing controls ordered more logically, perhaps alphabetically.
They are sorted by libraries - when you compile wxWidgets in multilibs (not monolithic), you will see that the classification of the widgets correspond more or less to the libraries splitting. However, this is not a priority for now, in my opinion.
     
     A good update of wxSmith will put it several leagues ahead of the competitors
     WxWidgets 2.9.0 introduced several new widgets, such as wxBitmapToggleButton.
     wxPropertyGrid is missing also
     In wxWidgets 2.9.1 (SVN trunk) you have also the wxRibbon class and sub-classes

   All these widgets would greatly enhanced wxSmith

   Currently, I want to finish the XPM Editor (I did not make progress the last 2 weeks, mainly due to a very heavy workload at my company).
   As soon as I am finished with it, I will be glad to give you a hand for wxSmith improvement. Since you have already set up a fork for the plugin, I will certainly contribute, instead of making a second fork. It will avoid duplicate efforts !

Regards,

Sebastien
   
Title: Re: wxSmith improvement
Post by: Cryogen on May 18, 2010, 08:13:43 am
 Hi Sebastien,


qI have 3 arguments for regrouping the wxSmith extension in as few plugins as possible:
   - it is easier to manage for the end-user (less plugins listed in the Manage Plugins dialog boxes, better organization of the wxWidgets palette , ...)

Possibly. I don't see the plugin manager as an issue as that can be improved itself, if need be. The organisation could absolutely be improved but I think that would come from better grouping over several tabs and not necessarily from having them all in the same plugin. For example, I wouldn't want the KWIC controls lumped in with everything else as they're probably of interest to fewer users than others. We also have to consider things such as loading time and screen real estate. If you put wxSmith into 32 pixel mode you soon see how little space there is on those tabs. We could certainly group related things together, though.


   - it is easier for the end-user to have a quick overview of all the widgets available. A big advantage of a RAD editor such as wxSmith is the ability to test quickly several widgets, and decide how to implement a desired GUI feature.
     The bigger the palette, the faster the process is.

Again, I'm not convinced of that and things such as loading would be slower, however it's probably a bit early to be debating this. :-)
Part of the problem is that C::B's plugin system is a pig and doesn't seem to work as intended. If this was improved plugins might be less of an issue, generally.

    You save time, because you do not need to spend countless hours on wxCode, download a potentially good control, spend a few hours to adapt it to your configuration, and finally see it is not exactly what you need.

That's certainly a good argument for having them available in wxSmith, yes.


   - it avoids duplicate efforts from several devoloppers. There are several contributors to wxSmith - I have downloaded several of them, but for example, I was not aware that you started wxKWIC extension.

Well, that only went up the day it was listed here, so you wouldn't. ;-)

I would like to see the existing controls ordered more logically, perhaps alphabetically.
They are sorted by libraries - when you compile wxWidgets in multilibs (not monolithic), you will see that the classification of the widgets correspond more or less to the libraries splitting. However, this is not a priority for now, in my opinion.

I think we're talking about different things, here. I'm referring to sorting within tabs. I think you mean the tabs themselves. Take the "Standard" tab, for example. As far as I'm aware those controls all come from the same library but they're all over the place. I agree it's lower priority but it might also be sensible to get things organised early in the process so we can start as we mean to continue, rather than create more work for later.

    
    A good update of wxSmith will put it several leagues ahead of the competitors
     WxWidgets 2.9.0 introduced several new widgets, such as wxBitmapToggleButton.
     wxPropertyGrid is missing also
     In wxWidgets 2.9.1 (SVN trunk) you have also the wxRibbon class and sub-classes

   All these widgets would greatly enhanced wxSmith

Yes, indeed and that's not the half of it.

  Currently, I want to finish the XPM Editor (I did not make progress the last 2 weeks, mainly due to a very heavy workload at my company).
   As soon as I am finished with it, I will be glad to give you a hand for wxSmith improvement. Since you have already set up a fork for the plugin, I will certainly contribute, instead of making a second fork. It will avoid duplicate efforts !

Sounds cool.
Actually, I haven't forked anything. My page simply points to my patches here and has add-ons for the existing branch. It's something we might consider, though.

Here are some other things I'd like to see done:

-Update Codef()'s "%n" option to use wxT() rather than _T(), as that's what wxWidgets has standardised on.
-Likewise change instances of _T() in the code to wxT() or _(), as translation isn't done for some reason.
-Add an option to pass a float or double through Codef() as you can't get one through easily, currently.

Just for info. I've also added wxAnimationCtrl and wxMediaCtrl to the palette. I'll get a patch out over the next day or so once I've done some testing in Linux.

Cheers.

Title: Re: wxSmith improvement
Post by: Cryogen on May 18, 2010, 08:24:44 am

 Another thought. It would be great if we could build a list of all the patches/fixes/add-ons that are floating around for wxSmith. I'd be happy to tack a page onto my site with a list to help us keep track, if you like.

Cheers.
Title: Re: wxSmith improvement
Post by: MortenMacFly on May 18, 2010, 09:01:18 am
I'd be happy to tack a page onto my site with a list to help us keep track, if you like.
I should have most of them captured in my local copy. I cannot provide a patch, but probably the integrated source code modules (plugins) for the C::B environment. I am just very limited in time these days.
Title: Re: wxSmith improvement
Post by: MortenMacFly on May 19, 2010, 08:28:56 pm
I've set up a site for my work at http://wxsmithaddons.sourceforge.net/ (http://wxsmithaddons.sourceforge.net/). I'd be happy to work in with you guys so we all work towards the same ends.
I've attached a patch for you that will enable compilation with wx2.9.x and wxPropGrid >1.2.x. The interface has changed and compilation is broken otherwise. Feel free to use it.

[attachment deleted by admin]
Title: Re: wxSmith improvement
Post by: Cryogen on May 20, 2010, 05:57:10 am
I've set up a site for my work at http://wxsmithaddons.sourceforge.net/ (http://wxsmithaddons.sourceforge.net/). I'd be happy to work in with you guys so we all work towards the same ends.
I've attached a patch for you that will enable compilation with wx2.9.x and wxPropGrid >1.2.x. The interface has changed and compilation is broken otherwise. Feel free to use it.

Very nice, thanks. Will this still allow compilation with 2.8? I presume not. I'm not using 2.9, yet. I've been waiting for a release version.
The updated Property Grid is nice, too. That's one I missed on my list of things to do below. I would love to use the help panel to provide function descriptions as per VS, as that's something that's sorely lacking.

Cheers.
Title: Re: wxSmith improvement
Post by: MortenMacFly on May 20, 2010, 06:48:38 am
Very nice, thanks. Will this still allow compilation with 2.8?
Sure. I am using 2.8 myself and it'll just work fine. Have a look at the #ifdefs. The code is unmodified if you compile with wx2.8.
Title: Re: wxSmith improvement
Post by: Cryogen on May 21, 2010, 04:20:45 am
 Hi Guys,

The wxAnimationCtrl/wxMediaCtrl patch is up:

http://forums.codeblocks.org/index.php/topic,12584.new.html

Cryo.
Title: Re: wxSmith improvement
Post by: Cryogen on June 08, 2010, 06:42:12 pm
 Hi Guys,

Just a quick update to keep things together.

Here are some other things I'd like to see done:

-Update Codef()'s "%n" option to use wxT() rather than _T(), as that's what wxWidgets has standardised on.
-Likewise change instances of _T() in the code to wxT() or _(), as translation isn't done for some reason.
-Add an option to pass a float or double through Codef() as you can't get one through easily, currently.

I'm getting into the guts of this thing, now. It's pretty complicated, I must say. I now see that translation is available in much of the code. Some does need to be fixed, though.
Some other thoughts that have occurred:

-There are a lot of typos in the documentation that could be cleaned up.
-The doxygen file comments are missing, which prevents some things from working.
-Doxygen sees wxPropertyGrid's docs as the main doc when you try to compile wxSmith's docs. We just need to adjust things a bit to fix this.
-The author used his preferred code style, which is fine, but it might be good to change what is output by wxSmith (not the internal code as that would be mega-work) so that it produces a standard ID format and variable names like m_Var, m_pVar, etc. I believe that would bring it more into line with C::B and wx but we'd need to discuss it.
-It would be nice to prevent controls displaying on the palette if they're not compiled into the wx lib in use.
-Others that I can't remember on the spur of the moment.

These are done and tested on Win7 and Ubuntu Karmic:
http://forums.codeblocks.org/index.php/topic,12622.0.html (http://forums.codeblocks.org/index.php/topic,12622.0.html)
http://forums.codeblocks.org/index.php/topic,12677.0.html (http://forums.codeblocks.org/index.php/topic,12677.0.html)

There is definitely room for improvement and I'm aware of at least one limitation that I need to correct soon.

This where I'm at currently...
I've added most of the remaining controls from wx2.8.
I'm currently struggling with a couple of things such as image lists for things like wxSimpleHtmlListBox and how to manage cell allocation for wxGridBagSizer.
Once I've sorted these I'll release another patch.
I've started adding doxygen file comments to the files I change and cleaning up the control palette tabs as I go. (Reorganising the tabs is trivial so it's easy to change it if we decide on another arrangement later.)
I've been updating the list at http://wiki.codeblocks.org/index.php?title=Comparison_of_wxSmith_features (http://wiki.codeblocks.org/index.php?title=Comparison_of_wxSmith_features) progressively.

I would then like to add the remaining managed windows. I've already made a start on this.
Next, I propose to do a clean up of the typos and such and release a separate patch, independent of my other changes, for that.
Finally, I'd like to look at wx2.9 and start on the controls that that introduces.

That should do for a while. ;-)

Cryo.
Title: Re: wxSmith improvement
Post by: MortenMacFly on June 10, 2010, 07:16:07 am
-Doxygen sees wxPropertyGrid's docs as the main doc when you try to compile wxSmith's docs.
This will change in the near future. wxPropGrid will be updated and be part of the core (as a DLL).
Title: Re: wxSmith improvement
Post by: Cryogen on June 10, 2010, 06:32:48 pm
-Doxygen sees wxPropertyGrid's docs as the main doc when you try to compile wxSmith's docs.
This will change in the near future. wxPropGrid will be updated and be part of the core (as a DLL).


That's good, thanks. That reminds me to update the list below... ;-)
Title: Re: wxSmith improvement
Post by: Cryogen on June 10, 2010, 06:44:56 pm
-Update Codef()'s "%n" option to use wxT() rather than _T(), as that's what wxWidgets has standardised on.
-Likewise change instances of _T() in the code to wxT() or _(), as translation isn't done for some reason. [This is largely wrong but we should check translations anyway]
-Add an option to pass a float or double through Codef() as you can't get one through easily, currently. [Partially done]

-There are a lot of typos in the documentation that could be cleaned up.
-The doxygen file comments are missing, which prevents some things from working.
-Doxygen sees wxPropertyGrid's docs as the main doc when you try to compile wxSmith's docs. We just need to adjust things a bit to fix this. [Fixed in C::B SVN 6354 with PropGrid 1.4]
-The author used his preferred code style, which is fine, but it might be good to change what is output by wxSmith (not the internal code as that would be mega-work) so that it produces a standard ID format and variable names like m_Var, m_pVar, etc. I believe that would bring it more into line with C::B and wx but we'd need to discuss it.
-It would be nice to prevent controls displaying on the palette if they're not compiled into the wx lib in use.
-Others that I can't remember on the spur of the moment.
-Update wxPropGrid to the latest. [Fixed in C::B SVN 6354 with PropGrid 1.4]
-Fix the awful screen flashing that occurs every time the editor display updates.

I've now got past my initial problem with image lists but the current solution only uses images from files, i.e. wxImageFileProperty, as there's no way to get wxSmith's image editor into the grid when you are dynamically adding and removing fields. We need to extend the image editor component to allow it to dynamically add and remove editors. So...

-Extend the image editor to allow dynamic addition and removal of image fields. [Fixed in my patch 18]
-The same for the colour editor.

I'm also working on a demo app. that I use as a testbed and which will provide examples of how to use the controls I add, based somewhat on the wx samples.

Cheers.
Title: Re: wxSmith improvement
Post by: Cryogen on July 19, 2010, 11:22:40 pm
Hey Guys,

I've added most of the remaining controls to wxSmith. Details here (http://forums.codeblocks.org/index.php/topic,12947.0.html).

I'm going to work on the bitmap editor next because I've made some headway there already, then I intend to add the managed windows i.e. those that need to be overridden when used, such as wxComboCtrl.

Cheers.
Title: Re: wxSmith improvement
Post by: Cryogen on August 30, 2010, 06:40:07 pm

 Hi,

I've added the image facilities in my Patch 18 and made the promised changes to wxBitmapComBox. I also updated the rough list below. I'll get the demo app out next as it's nearly there already, then look at those managed windows.

Cheers.
Title: Re: wxSmith improvement
Post by: Cryogen on August 30, 2010, 06:49:21 pm
Updated ToDo List

-Update Codef()'s "%n" option to use wxT() rather than _T(), as that's what wxWidgets has standardised on.
-Likewise change instances of _T() in the code to wxT() or _(), as translation isn't done for some reason. [This is largely wrong but we should check translations anyway]
-Add an option to pass a float or double through Codef() as you can't get one through easily, currently. [Partially done]
-There are a lot of typos in the documentation that could be cleaned up.
-The doxygen file comments are missing, which prevents some things from working. [Fixing progressively]
-Doxygen sees wxPropertyGrid's docs as the main doc when you try to compile wxSmith's docs. We just need to adjust things a bit to fix this. [Fixed in C::B SVN 6354 with PropGrid 1.4]
-The author used his preferred code style, which is fine, but it might be good to change what is output by wxSmith (not the internal code as that would be mega-work) so that it produces a standard ID format and variable names like m_Var, m_pVar, etc. I believe that would bring it more into line with C::B and wx but we'd need to discuss it.
-It would be nice to prevent controls displaying on the palette if they're not compiled into the wx lib in use.
-We will need to do similar checking for controls that are new in wx2.9.
-Update wxPropGrid to the latest. [Fixed in C::B SVN 6354 with PropGrid 1.4]
-Fix the awful screen flashing that occurs every time the editor display updates.
-Extend the image editor to allow dynamic addition and removal of image fields. [Done in my patch 18]
-The same for the colour editor.
-Demo app. [Done and will be updated progressively]

Title: Re: wxSmith improvement
Post by: Loaden on August 30, 2010, 07:06:18 pm
Good work! :D
Title: Re: wxSmith improvement
Post by: Cryogen on September 03, 2010, 07:05:39 am

 Hi Chaps,

A note. I've found a regression, today, in wxSmith. The colour property has stopped working. The colour swatches don't appear and I can't set colours. Alos properties, such as the font one, which contain the text "Click to edit" and a button to launch an editor aren't showing the text and the preview doesn't update for the font case, at least. I'm slogging back through the SVN versions to see whether it's something I've done or it happened somewhere else. So far it seems that it's not my latest image-related changes as removing all of the files doesn't restore the functionality.

Could you do me a favour and check whether you see any of these symptoms on your end? If not then it definitely sounds like me. I'm sure they were OK before the last round of updates after I got my computer back so it may have happened while I was out of the loop.

I'm also having a problem running a parallel version of C::B, so I don't have to trash my dev. version. I keep getting the dialogue telling me to set the CODEBLOCKS_DATA_DIR envvar or re-install. The first doesn't work and the second isn't possible. I've tried running it in various ways manually, from the command line, within C::B after build, etc. but always the same result. Any ideas?

Thanks.
Title: Re: wxSmith improvement
Post by: Cryogen on September 03, 2010, 07:19:50 am

In other news I've completed the first cut of the demo app. It's available at the addons site below. It brought to light several errors, omissions and misunderstandings, which I've fixed and will provide a patch for tomorrow.

Cheers.
Title: Re: wxSmith improvement
Post by: seb_seb0 on September 03, 2010, 07:26:56 am

 Hi Chaps,

A note. I've found a regression, today, in wxSmith. The colour property has stopped working. The colour swatches don't appear and I can't set colours. Alos properties, such as the font one, which contain the text "Click to edit" and a button to launch an editor aren't showing the text and the preview doesn't update for the font case, at least. I'm slogging back through the SVN versions to see whether it's something I've done or it happened somewhere else. So far it seems that it's not my latest image-related changes as removing all of the files doesn't restore the functionality.

Could you do me a favour and check whether you see any of these symptoms on your end? If not then it definitely sounds like me. I'm sure they were OK before the last round of updates after I got my computer back so it may have happened while I was out of the loop.

I confirm this problem on Windows.
Title: Re: wxSmith improvement
Post by: Jenna on September 03, 2010, 07:42:51 am
Confirmed, starting a preview with th e"Show preview"-button after changing the text of a listbox (e.g.) shows the correct text, but the preview has no close button.
The text does not appear in wysiwyg-preview and is not saved.
Colour can not be customized.

For a simple textcontrol updating the text works, but chnging the colour has no effects, changes are not written to the cpp-file .
Title: Re: wxSmith improvement
Post by: Jenna on September 03, 2010, 08:08:47 am
After reopening the project the close... buttons of the preview are there, and anothe rstrange thing: doble-clickinhg into the empty area of the underlying wxFrame updates the cpp-file and the wysiwyg-preview.
Title: Re: wxSmith improvement
Post by: PaulS on September 03, 2010, 02:42:08 pm
Another regression is when adding an event handler.  When you first click on the down triangle to add a handler the drop down is filled with horizontal lines.  Mousing over it causes the correct text to appear. 

This occurs on windows 7 in the current nightly but works properly in 6454.

I tried to report this in one of the more user oriented forums several days ago (search for "trash" if you care) but received no reply.  Should I have posted here although I am not a developer? If I was ignored because it was already reported please give me a clue on what keywords I should have searched on.  I did try.
Title: Re: wxSmith improvement
Post by: Cryogen on September 03, 2010, 06:37:11 pm

  Hi Paul,

Another regression is when adding an event handler.  When you first click on the down triangle to add a handler the drop down is filled with horizontal lines.  Mousing over it causes the correct text to appear. 

This occurs on windows 7 in the current nightly but works properly in 6454.

Many thanks for reporting. I don't see this, myself. I don't use nightlies, though. I'm currently using SVN 6557. I haven't seen the behaviour you describe in any SVN releases I've used. I also use Win7. I take it you're using the 24/8 nightly? Can someone using nightlies confirm this, please? Paul's original report is here: http://forums.codeblocks.org/index.php/topic,13171.0.html.

I tried to report this in one of the more user oriented forums several days ago (search for "trash" if you care) but received no reply.  Should I have posted here although I am not a developer? If I was ignored because it was already reported please give me a clue on what keywords I should have searched on.  I did try.

I can assure you that you weren't ignored. Responses depend on who looks where and when but it may well have been noted. The best and most "correct" place for bug reports is https://developer.berlios.de/projects/codeblocks/. Bugs tend to get lost in the forums.

There are some helpful details at http://forums.codeblocks.org/index.php/topic,1673.0.html, but you do need to look in the Developer forum to see that. :-)

So, thanks again and we'll try to verify what's going on for you.

It would help me with the others if you could tell me whether you see those symptoms in your nightly.

Cheers,

 Cryo.
Title: Re: wxSmith improvement
Post by: Cryogen on September 03, 2010, 06:52:16 pm

 Thanks for the confirmations, guys. It looks like I have some investigation to do.  :shock:

Title: Re: wxSmith improvement
Post by: Jenna on September 03, 2010, 08:13:10 pm

 Thanks for the confirmations, guys. It looks like I have some investigation to do.  :shock:


It slipped with the wxPropgrid update (svn r6339) and not with your patches.
So we have to look there.
Title: Re: wxSmith improvement
Post by: MortenMacFly on September 03, 2010, 08:34:01 pm
It slipped with the wxPropgrid update (svn r6339) and not with your patches.
Could you try again, please. By accident the 1.4'er version chosen to use had a serious bug. :-(
Title: Re: wxSmith improvement
Post by: PaulS on September 03, 2010, 09:52:50 pm
You asked if I was using the August 24 nightly, No I'm using August 30th svn 6562.  However, I must recant.  The problem is probably my own doing.

On my primary machine it fails as I reported on 6562 and works fine after reinstalling 10.5 release (not sure what that svn was).
This afternoon I updated a second machine to 6562 and that one works just fine.  Put 6562 back on the primary machine & it still fails. 

Both machines are Thinkpads running Windows 7 with all the latest Microsoft updates.  They are different models and have different screen resolutions and different video components.

All files in the Codeblocks directory have the same dates. The shared subdirectory is too big to check manually.  I will look for a tool to compare directories of non-text files but don't know of one off hand.

If no one else is seeing this problem (junk in display when adding a event handler) don't waste your time.  If someone else is please speak up.


Title: Re: wxSmith improvement
Post by: Jenna on September 03, 2010, 10:00:57 pm
It slipped with the wxPropgrid update (svn r6339) and not with your patches.
Could you try again, please. By accident the 1.4'er version chosen to use had a serious bug. :-(
Does not fix it  :(
Title: Re: wxSmith improvement
Post by: Cryogen on September 05, 2010, 11:56:49 pm
You asked if I was using the August 24 nightly, No I'm using August 30th svn 6562.  However, I must recant.  The problem is probably my own doing.

On my primary machine it fails as I reported on 6562 and works fine after reinstalling 10.5 release (not sure what that svn was).
This afternoon I updated a second machine to 6562 and that one works just fine.  Put 6562 back on the primary machine & it still fails. 

Both machines are Thinkpads running Windows 7 with all the latest Microsoft updates.  They are different models and have different screen resolutions and different video components.

All files in the Codeblocks directory have the same dates. The shared subdirectory is too big to check manually.  I will look for a tool to compare directories of non-text files but don't know of one off hand.

If no one else is seeing this problem (junk in display when adding a event handler) don't waste your time.  If someone else is please speak up.

Thanks for the details, Paul. No-one is reporting it so far.
WinMerge will do what you want and is free and excellent.

Ciao.
Title: Re: wxSmith improvement
Post by: Cryogen on September 06, 2010, 12:02:56 am
It slipped with the wxPropgrid update (svn r6339) and not with your patches.
Could you try again, please. By accident the 1.4'er version chosen to use had a serious bug. :-(
Does not fix it  :(

Yeah, agreed. Morten's latest commit didn't change things. My investigation so far shows that it happened with SVN6339, as Jens said. Going back to 6219, the previous change for wxSmith, everything works. I've only looked into wxsColourProperty so far. If you change the code in wxsColourProperty::PGCreate() in wxscolourproperty.cpp. lines 506/507 to reactivate wxSystemColourProperty instead of wxsMyColourPropertyClass, the error doesn't occur so it's in wxsMyColourPropertyClass. So far I haven't been able to trace it.

Cheers.
Title: Re: wxSmith improvement
Post by: Cryogen on September 06, 2010, 04:10:40 am

 I have to say that I'm stumped with this at the moment. If anyone has more experience with the inner workings of it they would probably do better than me. It gets very convoluted with macros and there's such a lot of code that it's not easy to know exactly what's happening where, at times. I can think of two general possibilities. One is that some of the changes made when propgrid 1.4 was introduced caused the problems. The other, which seems more likely, is that the behaviour of propgrid changed and it wasn't picked up. I can't see where the problems lie at this stage.

Cheers.
Title: Re: wxSmith improvement
Post by: Jenna on September 06, 2010, 04:22:14 am
It's most likely the second one, itmight be related to wxPGId (used in wxsXXX::PGCreate) and wxPGPropArg in newer wxPropgrid, but the depth of wxSmith and wxPropGrid is somewhat unclear to me.
Maybe I find the time to investigate more the next days.
Title: Re: wxSmith improvement
Post by: seb_seb0 on September 06, 2010, 09:45:22 pm
Hello,

I do not know if you have seen my post here:
http://forums.codeblocks.org/index.php/topic,13243.msg89078.html#msg89078 (http://forums.codeblocks.org/index.php/topic,13243.msg89078.html#msg89078)

I have sent a patch against SVN 6570 which solves the problem with wxsMyColourPropertyClass.
It is a 10 lines patches, and it solved the problem for the colour combobox in wxSmith.

Let me know if that helps you, or if I misunderstood completly the last posts.

Sebastien
Title: Re: wxSmith improvement
Post by: Jenna on September 07, 2010, 10:17:10 am
Hello,

I do not know if you have seen my post here:
http://forums.codeblocks.org/index.php/topic,13243.msg89078.html#msg89078 (http://forums.codeblocks.org/index.php/topic,13243.msg89078.html#msg89078)

I have sent a patch against SVN 6570 which solves the problem with wxsMyColourPropertyClass.
It is a 10 lines patches, and it solved the problem for the colour combobox in wxSmith.

Let me know if that helps you, or if I misunderstood completly the last posts.

Sebastien

It shows the colourboxes, but the rest is not working (can not chose a colour).
There seem to be api-changes, so some of the choices do not longer work.
For the coulours we can use the properties of wxPropGrid, I don't know if there is a need to still use the customcolourpropoerty.
I did not find a solution for the editors, but don't have much time to look into it (not at home the next two or three days).
Title: Re: wxSmith improvement
Post by: seb_seb0 on September 07, 2010, 09:28:03 pm
Hello,

I do not know if you have seen my post here:
http://forums.codeblocks.org/index.php/topic,13243.msg89078.html#msg89078 (http://forums.codeblocks.org/index.php/topic,13243.msg89078.html#msg89078)

I have sent a patch against SVN 6570 which solves the problem with wxsMyColourPropertyClass.
It is a 10 lines patches, and it solved the problem for the colour combobox in wxSmith.

Let me know if that helps you, or if I misunderstood completly the last posts.

Sebastien

It shows the colourboxes, but the rest is not working (can not chose a colour).
There seem to be api-changes, so some of the choices do not longer work.
For the coulours we can use the properties of wxPropGrid, I don't know if there is a need to still use the customcolourpropoerty.
I did not find a solution for the editors, but don't have much time to look into it (not at home the next two or three days).

Unfortunately you are right.
If I find some time, I will try a bit deeper. I will let you know if I find something.

Sebastien
Title: Re: wxSmith improvement
Post by: Cryogen on September 08, 2010, 05:17:05 am
Hello,

I do not know if you have seen my post here:
http://forums.codeblocks.org/index.php/topic,13243.msg89078.html#msg89078 (http://forums.codeblocks.org/index.php/topic,13243.msg89078.html#msg89078)

I have sent a patch against SVN 6570 which solves the problem with wxsMyColourPropertyClass.
It is a 10 lines patches, and it solved the problem for the colour combobox in wxSmith.

Let me know if that helps you, or if I misunderstood completly the last posts.

Sebastien

Nice catch, thanks Seb. That's one step forward, at least. I'm still looking as well.

Title: Re: wxSmith improvement
Post by: Cryogen on September 09, 2010, 10:19:09 pm

 Hi Guys,

Two things. I've done some more work on wxSmith's problems, specifically the colour property. The main problem seems to be that

Code
int type = wxEnumPropertyClass::DoGetValue().GetLong();

in wxsMyColourPropertyClass::OnEvent() usually returns 0. I would have said "always" except that during the last run I saw the value 33 a few times, for unknown reasons. Either way, it always ends up failing to match any of the conditionals and therefore, we get no action. I've been unable to trace why, other than that it falls through to wxPGProperty::DoGetValue(). I can't see how the value is set or why it's not getting the right value.

I also tried building a new property based on the 1.4 docs, but it behaves the same way as soon as I start using wxEnumPropertyClass.

I think we need to try to resurrect it if we can because it adds some features over the default wxSystemColourProperty, such as the "default" entry. One option might be to steal that and modify it.

There seems to be some sort of refresh problem, in general, that stops the text appearing for the other properties but, again, where and why is anyone's guess.

If whomever did the upgrade has a better knowledge of wxSmith's internals, perhaps it should go back to them to find out what didn't upgrade as intended?

The other thing is that I received a call 15 mins ago saying that I've finally got a real job. So, from Monday, I will have much less time to work on C::B. Reality bites, huh? ;-)
I'll still be around, though.

Cheers.
Title: Re: wxSmith improvement
Post by: Jenna on September 17, 2010, 12:31:09 pm
I attach a patch that seems to fix the issue for wxsColourProperty, it's not deeply tested (and not tested at all on windows and mac), but seems to work.

Please other devs (and users of course) please test and give feedback.

I will look into the other issues (wxListbox and others) later.

The patch is against trunk (r6595), but I think it works with all other branches too.

EDIT:
attachment removed, actual patch see http://forums.codeblocks.org/index.php/topic,12362.msg89758.html#msg89758 (http://forums.codeblocks.org/index.php/topic,12362.msg89758.html#msg89758)
Title: Re: wxSmith improvement
Post by: Jenna on September 17, 2010, 09:02:23 pm
After some testing, I found that the patch is just a starting point not a solution, it works for existing elements, but crashes if a new one with colourproperty is added.
Title: Re: wxSmith improvement
Post by: Jenna on September 19, 2010, 12:50:11 pm
After some testing, I found that the patch is just a starting point not a solution, it works for existing elements, but crashes if a new one with colourproperty is added.
New version (a little larger), but this time it seems to work correctly.

It's against trunk and not (yet) tested on windows.

Any feedback is welcome.

EDIT:
attachment removed, actual patch see http://forums.codeblocks.org/index.php/topic,12362.msg89758.html#msg89758 (http://forums.codeblocks.org/index.php/topic,12362.msg89758.html#msg89758)
Title: Re: wxSmith improvement
Post by: MortenMacFly on September 19, 2010, 08:45:18 pm
Any feedback is welcome.
I had applied the first one, too - no serious issues so far. I'll try this one, too. If you hear nothing all is fine. :-)
Title: Re: wxSmith improvement
Post by: Jenna on September 19, 2010, 11:34:30 pm
Small update to my previous patch (build/link-fix for windows):

either use the patch attached here or remove WXDLLIMPEXP_PG from class-declaration of wxsMyColourPropertyClass in wxscolourproperty.cpp:124.

I remove the older patches.
Title: Re: wxSmith improvement
Post by: Cryogen on September 20, 2010, 12:44:29 am
 [EDIT](nonsense removed)

My bad, the patch didn't, apparently. Ergh. It's working well, now.  :oops:

Win7 and SVN 6575.

Bye.
Title: Re: wxSmith improvement
Post by: Jenna on September 21, 2010, 12:08:46 am
Just committed the fix for the colourproperty.
Title: Re: wxSmith improvement
Post by: Jenna on September 28, 2010, 07:37:40 am
Just committed the fix for the colourproperty.
The other issues (related to wxCustomEditorProperty) should be fixed in trunk now (svn r6441) and will be fixed in cc- and dbg-branch afetr the next merge.
Title: Re: wxSmith improvement
Post by: Cryogen on September 30, 2010, 02:58:30 am

 Hey Jens,

The other issues (related to wxCustomEditorProperty) should be fixed in trunk now (svn r6441) and will be fixed in cc- and dbg-branch afetr the next merge.


Many thanks for fixing this. It's all working properly now, and better thanks to the enhancements you made. It also fixed another issue I was seeing that must have been related.

Cheers,

 G.
Title: Re: wxSmith improvement
Post by: Cryogen on October 12, 2010, 05:36:31 am

 Hi Guys,

I've added the rest of wxSmithImage's editors to wxSmith. Patch 21 in the patchorama. Details are here: http://forums.codeblocks.org/index.php/topic,13213.0.html.
I'll update the demo app over the next few days. I think the tree editor will allow me to complete the treebook control, now, as well, which is nice.

Ciao.