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?Nope, such wxSmith plugin exists. It wraps wxImage, wxImageButton, wxImageComboEditDialog and some more.
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.
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.
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. ;-)
- unify all the additionnal wxSmith contrib items in 1 single plugin. I have listed the following
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. :-)
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.
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 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.
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 , ...)
- 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.
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 !
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.
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.
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?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.
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.
-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).
-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).
-Update wxPropGrid to the latest. [Fixed in C::B SVN 6354 with PropGrid 1.4]-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.
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.
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.
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.Could you try again, please. By accident the 1.4'er version chosen to use had a serious bug. :-(
Does not fix it :(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. :-(
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.
Does not fix it :(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. :-(
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
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).
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
int type = wxEnumPropertyClass::DoGetValue().GetLong();
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.
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. :-)
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.
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.