New Plugin: wxCrafter Integration with CodeBlocks

[eranif]

Hi,

I wrote a small plugin that integrates wxCrafter Standalone application with CodeBlocks
The plugin includes:

- Instantly create a wxWidgets project using a wizard with wxCrafter resource file
- Added new view 'wxCrafter' tab which allows you to quickly create a new "wxForm"
- All generated files are automatically added to the project and to all build targets

The source code for the plugin can be found here:
https://github.com/eranif/wxCrafterCB

A short video showing the plugin in action (recommended to view in 1080p):
https://www.youtube.com/watch?v=667mdb2AQaE

A plugin installer for Windows (it also installs wxCrafter 1.5 + the Code::Blocks plugin):
http://codelite.org/downloads/wxCrafter/wxCrafterDownloads.php?windows_plugin_cb

I only built it for Windows (my users requested it for Windows only ) ...

Note that the plugin was compiled against CodeBlocks 13.12 SDK, so I am not sure if it will work with a recent nightly

Eran

[oBFusCATed]

Hm, interesting plugin and tool. 

[MortenMacFly]

Hi Eran,

that's very interesting... I'll try to compile/use this tool.

In case it is well working, would you want us to integrate this permanently into the SVN source tree? This would integrate it into nightly builds and (of course) releases, too. Hence you would need access to continue development...

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

Just share your thoughts...

[ollydbg]

I see wxCrafter is not a free software (nor a open source software). If we put the plugin in our trunk, do we promote such kind of software usage? I personally have concern about this. (I may be wrong...)

[oBFusCATed]

...we can integrate this plugin through svn::externals...

Won't work he is using git.
I also have missed the non-OSS-ness part of the wxCrafter.

And I'm generally against adding every single plugin in the plugins/contrib subdir.
We should try to make things easier for plugin writers (stable api/abi, etc) instead.

[MortenMacFly]

...we can integrate this plugin through svn::externals...

Won't work he is using git.

Thats why I wrote:

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.
We should try to make things easier for plugin writers (stable api/abi, etc) instead.

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.

About the none-OSS - that's another story. In fact I played with wxCrafter and it has some advantages over wxSmith (though I still prefer using wxSmith myself). There is a freeware version which I would expect remains free (if not we can still remove it at that time). In the end we also have interfaces to commercial compilers like MSVC or Intel which is even worse. Should we remove those, too then?

[eranif]

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

Eran

[MortenMacFly]

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.

[ToApolytoXaos]

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.

[stahta01]

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.

You are already allowed to use closed source plugins; how do you think it can get more "permissive" license (business-wise that is)?

Tim S.

[eranif]

If wxCrafter was fully FOSS-ed would be more than convenient for many

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

I simply created a plugin to allows CodeBlocks to interact with yet another tool (let call it wxCrafter) in a smoother way, you can choose to use it or to ignore it.
The plugin itself (again, _not_ wxCrafter) is open source, what Morten suggested was to add the plugin sources to the SVN

Does not this affects Code::Blocks's concept or are there any plans to move plugin to a more "permissive" license

I really don't understand this statement. The plugin is opened source. wxCrafter is not. Don't mix between the two

Eran

[digifuzzy]

Is this the same tool as this ?

From web page:

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.

[eranif]

Insert Quote
Is this the same tool as this ?

Yes, its the same tool

Eran

[ToApolytoXaos]

I really don't understand this statement. The plugin is opened source. wxCrafter is not. Don't mix between the two

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

My apologies for once again.

[stahta01]

Anyone succeed in downloading the CB 13.12 plugin?

I am have issues; but, my internet is sometimes poor.

Tim S.

[eranif]

Anyone succeed in downloading the CB 13.12 plugin?

I am have issues; but, my internet is sometimes poor.

Tim S.

Thanks for reporting this, I have updated the link

Eran

[MortenMacFly]

Well I tried to compile this plugin but I failed miserably.

First f all there is no C::B project file... so I installed CodeLite and opened the workspace. But unfortunately it tells me it cannot find the reference to the clang compiler which would be wrong anyways - it should use MinGW as C::B is compiled using MinGW, too.

I am not that deep in CodeLite to know what to do. Do I need clang? My experience with clang on Windows is that its not working unless you are using Visual Studio. Can you provide some hints what to do on a Windows platform, please?

[MortenMacFly]

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

However, the plugin is integrated, I can start the wizard to create a new project, I see the wxCrafter tab but then nothing happens. I cannot add any wx element (like wxFrame). There is also no error message - just nothing happens. I also don't see an option to setup a path to wxCrafter - I believe this might be needed?!

[eranif]

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

the plugin should be reading the path to wxCrafter from registry, unless you don't have the new version (you will need the latest wxCrafter 1.5)

Code

        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();
        }

As you can see, I have left a "FIXME" there

Try downloading this one ( I assume that you are using Windows )
http://codelite.org/downloads/wxCrafter/wxCrafterDownloads.php?windows

FYI: The C::B plugin installer that I have uploaded in my earlier posts also includes wxCrafter standalone bundled

Eran

[MortenMacFly]

FYI: The C::B plugin installer that I have uploaded in my earlier posts also includes wxCrafter standalone bundled

OK, but I would like to use it for trunk, so this installer is of no help.

Additionally as I have all my S/W portable the registry entry is missing. I'll try what happens if I create it. On the long run it would be nice to have an option to set wxCrafter explicitly. :-)

[eranif]

On the long run it would be nice to have an option to set wxCrafter explicitly. :-)

Sure, I will add it

Eran

[eranif]

Done, I have added configuration settings dialog that allows you to set a different path to wxCrafter. The default value is set to /usr/bin/wxcrafter on Linux and to the value that exists in the registry for Windows.

Do:

Code

git pull --rebase

for the latest change

Thanks,
Eran

[MortenMacFly]

Code

git pull --rebase

for the latest change

Working with this plugin for some time I realised its also the root of an annoyance I was not able to track down until now:

If you have this plugin enabled, you'll get this error on C::B startup:
---------------------------
Codeblocks Error
---------------------------
Resource files must have same version number!
---------------------------

I was looking for a long time which XRC files cause the version mismatch but didn't find one. Now I did by accident: It seems that you integrate XRC files as ASCII stream in the sources of the plugin that must contain a version number. As these are not proper XRC files its well hidden from the developer (me).

Would you please either make these XRC files... well... XRC files or remove the version number? In C::B all XRC files share the same (version-free) header like:
<?xml version="1.0" encoding="utf-8" ?>
<resource xmlns="http://www.wxwidgets.org/wxxrc">
[...]


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.

[Alpha]

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 on their repositories as well.

[MortenMacFly]

Github states you can use subversion on their repositories as well.

Good catch! ...and it actually works!