...we can integrate this plugin through svn::externals...Won't work he is using git.
Thats why I wrote:...we can integrate this plugin through svn::externals...Won't work he is using git.
Another options is (how we do it i.e. with the FortranProject plugin) that you use SVN sow we can integrate this plugin through svn::externals.
And I'm generally against adding every single plugin in the plugins/contrib subdir.I think this is another topic. For now, all I am thinking of is that you can have a single build with relevant external plugins so they make it into nightlies but being managed by an own person not necessarily a member of the C::B development team. With relevant I mean plugins that have a stable development team (so they don't get stalled) and that provide important (new) features. So I am far away from putting "everything" into contrib. In fact I want to put into contrib only whats available in a long-term period. And I believe with Eran thats the case. I would be happy if everything in contrib is a svn::external repo and managed by somebody else.
We should try to make things easier for plugin writers (stable api/abi, etc) instead.
would you want us to integrate this permanently into the SVN source tree?This will be more than great
I'll try to compile/use this tool.Let me add a CMakeLists.txt file so you can generate a Code::Blocks project with it (atm , I used codelite to build it)
Another options is (how we do it i.e. with the FortranProject plugin) that you use SVN sow we can integrate this plugin through svn::externals. This way you would have full access to the repo and it would be one of yours...I can move the plugin sources to SF and use SVN - this is not a problem at all by me ( I have no preferences for git over svn )
Just share your thoughts...
I can move the plugin sources to SF and use SVN - this is not a problem at all by me ( I have no preferences for git over svn )I think that would be the best solution for both sides unless we cannot find an agreement within the team.
If wxCrafter was fully FOSS-ed would be more than convenient for many, I'm sure. But my major concern is about its license.
Does not this affects Code::Blocks's concept or are there any plans to move plugin to a more "permissive" license (business-wise that is)?
This is something that concerns me greatly and I would like some clarifications please.
If wxCrafter was fully FOSS-ed would be more than convenient for manyHow is wxCrafter related here? its a tool, similar to VC compiler, Intel compiler or even Windows Explorer all of are not open source tools... and yet CodeBlocks allows access to them...
Does not this affects Code::Blocks's concept or are there any plans to move plugin to a more "permissive" licenseI really don't understand this statement. The plugin is opened source. wxCrafter is not. Don't mix between the two
What is wxCrafter?
wxCrafter is a RAD tool which allows a rapid development of wxWidgets based applications.
You can use wxCrafter as a CodeLite IDE plugin or as a standalone application
wxCrafter utilizes the code completion engine of codelite for better code generation and maintenance.
Insert QuoteYes, its the same tool
Is this the same tool as this ?
I really don't understand this statement. The plugin is opened source. wxCrafter is not. Don't mix between the twoMy apologies eranif; it was my bad, i'm sorry. I did not know about plugins' permissions. After I read more about it from wiki pages, I understood completely what you said.
Anyone succeed in downloading the CB 13.12 plugin?Thanks for reporting this, I have updated the link
I am have issues; but, my internet is sometimes poor.
Tim S.
Well I tried to compile this plugin but I failed miserably. :'(OK - I managed to create a C::B project file myself. (If you are interested I can provide it to you).
I also don't see an option to setup a path to wxCrafter - I believe this might be needed?!Sorry for the long silence, been busy in the last few days...
wxRegKey key(wxRegKey::HKLM, wxT("Software\\wxCrafter\\settings"));
if ( !key.QueryValue(wxT("InstallPath"), wxcrafterPath) ) {
// FIXME :: report an error
return false;
} else {
wxFileName fnWxc(wxcrafterPath, wxT("wxcrafter.exe"));
fnWxc.AppendDir(wxT("Standalone"));
wxcrafterPath = fnWxc.GetFullPath();
}
FYI: The C::B plugin installer that I have uploaded in my earlier posts also includes wxCrafter standalone bundledOK, but I would like to use it for trunk, so this installer is of no help.
On the long run it would be nice to have an option to set wxCrafter explicitly. :-)Sure, I will add it
git pull --rebaseWorking with this plugin for some time I realised its also the root of an annoyance I was not able to track down until now:Codefor the latest changegit pull --rebase
Also, I would like to state again that if this was a subversion repo (probably on sourceforge) it would be easy to integrate into C::B trough an SVN external. Having this plugin on GIT and the need to self-compile it makes it well hidden.Github states you can use subversion (https://help.github.com/articles/support-for-subversion-clients/) on their repositories as well.
Github states you can use subversion (https://help.github.com/articles/support-for-subversion-clients/) on their repositories as well.Good catch! ...and it actually works!