wxSmith improvement

[seb_seb0]

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)
     - 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
    - 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

[mariocup]

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

[Ganbito]

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.

[rcoll]

  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

[MortenMacFly]

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.

[seb_seb0]

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]

[seb_seb0]

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 !

[seb_seb0]

  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

I was refering to this one.

[rcoll]

It is you who created it !
See your post:
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

[MortenMacFly]

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. ;-)

[Cryogen]

 Hi Guys,

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

  - 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/. I'd be happy to work in with you guys so we all work towards the same ends.

Cheers,

  Cryo.

[MortenMacFly]

I've set up a site for my work at 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. :-)

[Cryogen]

 Thanks, Morten. That's great.

Cryo.

[seb_seb0]

 Hi Guys,

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

  - 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/. 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.

  - 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.

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
   

[Cryogen]

 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.