Can't figure out Swig

[zorocke]

I'm not really looking for help on this topic, I'm sure more time with the massive swig manual can fulfill all of my answers.

But, i'm wondering... Is any one else using swig with their projects, and finding it easy?

I started trying to get swig working with my C++ engine which consists of about 10 simple .cpp/.h files, and so far I've spent over 5 hours just trying to figure out how to use swig or even understand what's going on. I wanted to use swig to wrap my engine in C#, so that i could start easily creating gui tools in c#... But so far, I've made zero progress.

With the hours of frustration I've already had with swig, Qt using c++ is starting to look much more appealing.

I'm trying to weigh the sides here: spend time learning a new tool swig, OR just get over it and write c++ gui tools and deal with c++'s difficulties???

[Zonder]

You could try CXXI instead it's not mature but if your engine interface isn't complex it will probably work just fine.

http://tirania.org/blog/archive/2011/Dec-19.html

If you do try it I would be interested in the results I am trying to get some time my self to look into it

[zorocke]

It looks interesting.

But I have decided to just write my tools using Qt because supporting a C# wrapper for my engine even with these tools such as swig and the one you mentioned seems like more work than it's worth. It can't be that bad, I've used Qt before. I just thought I would try and get on board with the whole C# crave when it comes to UI and rapid development... Oh well, I guess it will need to wait for another project.

[jacmoe]

Did you check out QtQuick?
http://qt.nokia.com/qtquick/

[zorocke]

Did you check out QtQuick?
http://qt.nokia.com/qtquick/

QtQuick is more focused towards development for mobile platforms as opposed to desktop applications?

[jacmoe]

No. It's the way forward:

Qt 5 should be the foundation for a new way of developing applications. While offering all of the power of native Qt using C++, the focus should shift to a model, where C++ is mainly used to implement modular backend functionality for Qt Quick.

With Qt 5 we should put Qt Quick into the center of Qt without being disruptive for existing code developed for Qt 4. It will rather be a restructuring that will allow us to change the way we will think about application development in the future.

While traditional Qt/C++ applications will continue to work with Qt 5, there will be some fundamental changes on how applications can and will be written.

We should expect that over time all UIs will be written in QML. JavaScript will become a first class citizen within the Qt community and we should expect that a lot of application logic and even entire applications will be written in JavaScript instead of C++. The expectation is that many application developers will actually start out with QML and JavaScript and only implement functionality in C++ when required. For those specific use cases, the full power of the C++ APIs offered by Qt can be used to implement time critical and complex application functionality.

While we propose keeping the QWidget based programming model and API set available for compatibility, long term we also see QML as the future for user interfaces on the desktop. The solution here will most likely be QML-based component sets that integrate with the native styling APIs on the desktop platforms.

From this page:
http://labs.qt.nokia.com/2011/05/09/tho ... bout-qt-5/

Actually, KDE 4.8 is already using QtQuick (QML) for plasma widgets, so it's already happening.

[jacmoe]

I am very excited about QtQuick

[Sslaxx]

Lots of people on that blog page you linked to, Jacmoe, aren't though.

[jacmoe]

Understandable. It was written a year ago.

I didn't bother to read the comments because it has evolved since then, and now it's in actuall use - namely for KDE's plasma widgets.
And Qt 5 is going to make it the default environment.

Just think about it: Rapid Development using a scripting language, but still the full power of the underlying C++ framework is available to you.

Hope that my excitement doesn't wear off when I actually start using it.

[CABAListic]

Hm, aside from me not liking Javascript particularly, the one thing that bothered me when I took a glance at QtQuick was this: It sounded as if it's intended to be your application's "central point" that you could extend by C++ plugins. But that's not what I want - I want it to be embedded within my C++ application, not the other way around.
I admit I didn't spend too much time with it and didn't try it for real, so I might have misunderstood. But it sounded to me a lot like the Python/C++ relationship - extending Python with C++ modules is easy, embedding Python not so much (compared to other scripting languages).

[jacmoe]

As I understand it, it sits on top of the framework.
C++ nuts like you and me can still use the framework without QtQuick/QML.

I am also 'put off' by it being called 'javascript', but I suppose I have to try it out first.