Yes certainly feasible. In fact I have already swigged a fair few of the qcore h files, and enough of the qgui  ones to build a few working test programs. Not sure if you need a qt mode, although there might be a case for it. 
  I have only done this for modula3 so a lot of your qt specific typemaps would have to be redone for python, java et al. Also you need some glue code for the signals and slots. The stuff I have at the moment it built on subclassing a dynamic qobject and is pretty clunky, no compile time support like pyeside. 
  When I began I had to null out a lot of the qt macros. Caused a lot of grief to swig. Once you have a decent set of typemaps, judicious use of apply works wonders and the average .i file for a qgui .h file is only a few lines long. Your mileage may vary in other languages of course. I confess I am not an expert swigger and hardly ever use c++ so I'm sure there are better ways of building a qt interface.

Regards Peter

On Thu, May 16, 2013 at 11:11 PM, Dimitar Dobrev <dpldobrev@yahoo.com> wrote:
----- Forwarded Message -----
From: Dimitar Dobrev <dpldobrev@yahoo.com>
To: "swig-devel@lists.sourceforge.net" <swig-devel@lists.sourceforge.net>
Sent: Monday, May 13, 2013 9:51 PM
Subject: Fw: [Swig-devel] Special Qt mode for SWIG

----- Forwarded Message -----
From: Dimitar Dobrev <dpldobrev@yahoo.com>
To: William S Fulton <wsf@fultondesigns.co.uk>
Sent: Monday, May 13, 2013 9:51 PM
Subject: Re: [Swig-devel] Special Qt mode for SWIG

From: William S Fulton <wsf@fultondesigns.co.uk>
To: Dimitar Dobrev <dpldobrev@yahoo.com>
Cc: "swig-devel@lists.sourceforge.net" <swig-devel@lists.sourceforge.net>
Sent: Monday, May 13, 2013 8:43 PM
Subject: Re: [Swig-devel] Special Qt mode for SWIG

On 13/05/13 12:46, Dimitar Dobrev wrote:
>      Hello,
> I'm looking into the possibility to wrap Qt with SWIG. I've already read
> it's quite the challenge but I have an idea about which I'd love to hear
> some opinions.
> You probably know about SMOKE
> <http://techbase.kde.org/Development/Languages/Smoke>, another tool for
> wrapping C++ using headers. It has a special "qt" mode which allows it
> to properly recognize and parse Qt headers. I was wondering if the same
> option could in theory be added to SWIG? If so, I'd be interested in
> working on it.

I'm not familiar with the QT world, but from what I understand it is an
extension of C++. In which case, I can't see any major obstacles as to
why the SWIG parser couldn't be enhanced to add in QT syntax. SWIG has
always expected ISO C/C++, but I don't have a problem if a flag or
something similar adds in additional support. Where is the QT syntax
documented? What are the concepts in QT and can they be mapped onto C++
concepts? For example, from what I know, QT has some sort of properties,
which are very similiar to C++ member variables or even SWIG's %extend
variables or even %attribute.

Please feel free to make a Github fork for your work on this and use
this list for discussion.

There is plenty of developer docs to read, however, I'd expect you'll
first tackle the parsing in Source/CParse/parser.y.

I don't know SMOKE, are there any reasons why SWIG might be a better fit?


    I'm not sure if there is a full list of Qt's macros but here are quite a few. All of their concepts can me expressed through C++ and this is what they do internally. They have a tool called moc (Meta-Object Compiler) that is run on their code before any other steps. It produces standard C++ which is then compiled. The problem is that it produces only "real" cpp files, not "real" headers, and, as stated in the documentation, SWIG cannot be relied upon to work properly with C++ source files. So I figure there should be an option for SWIG to be able to parse Qt headers directly.

    SMOKE is poorly maintained (a single developer who hasn't worked on the main branch for almost a year, and hasn't worked on the project at all for more than half a year). I say that as a person who has sent quite a few patches to SMOKE and reported even more bugs none of which were actually fixed and only two or three paid attention to at all. Besides, SMOKE libraries cannot be used directly, they require an additional C++ layer to be manually written specifically for the binding in question (memory management, marshaling, etc.). As far as I can see, SWIG provides much better automation for these issues.

    Anyway, what I was asking is whether SWIG could wrap Qt with reasonable effort. I read some of the mailing list archives and found some discouraging posts. So, can it be done in practice?


    So, does someone have an opinion if it's feasible?

    Dimitar Dobrev

AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
Swig-devel mailing list