Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development
wxSmith improvement
Cryogen:
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
--- End quote ---
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:
--- Quote from: Cryogen on May 15, 2010, 04:31:52 am ---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.
--- End quote ---
That's great stuff! Don't think it not being noticed. :-)
Cryogen:
Thanks, Morten. That's great.
Cryo.
seb_seb0:
--- Quote from: 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
--- End quote ---
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.
--- End quote ---
Hello,
thank you for replying.
--- Quote ---
--- Quote --- - unify all the additionnal wxSmith contrib items in 1 single plugin. I have listed the following
--- End quote ---
I guess there are arguments both ways for this.
--- End quote ---
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.
--- End quote ---
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,
--- Quote from: seb_seb0 on May 17, 2010, 10:20:43 pm ---
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 , ...)
--- End quote ---
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.
--- Quote from: seb_seb0 on May 17, 2010, 10:20:43 pm ---
- 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.
--- End quote ---
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.
--- Quote from: seb_seb0 on May 17, 2010, 10:20:43 pm --- 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.
--- End quote ---
That's certainly a good argument for having them available in wxSmith, yes.
--- Quote from: seb_seb0 on May 17, 2010, 10:20:43 pm ---
- 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.
--- End quote ---
Well, that only went up the day it was listed here, so you wouldn't. ;-)
--- Quote from: seb_seb0 on May 17, 2010, 10:20:43 pm ---
--- Quote from: Cryogen on May 17, 2010, 10:20:43 pm ---I would like to see the existing controls ordered more logically, perhaps alphabetically.
--- End quote ---
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.
--- End quote ---
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.
--- Quote from: seb_seb0 on May 17, 2010, 10:20:43 pm --- 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
--- End quote ---
Yes, indeed and that's not the half of it.
--- Quote from: seb_seb0 on May 17, 2010, 10:20:43 pm --- 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 !
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version