On Monday, 17 February 2014 at 01:16:44 UTC, Xavier Bigand wrote:
> Le 17/02/2014 01:36, w0rp a écrit :
>> On Saturday, 15 February 2014 at 03:36:29 UTC, michaelc37 wrote:
>> I'll try Qt5 later. The main reason I'm trying to get Qt4 working at the
>> moment is that I have experience with Qt4, but not with Qt5, and from my
>> understanding a lot of the advantages of Qt5 come from QML, and I don't
>> quite understand yet how QML would tie together with a D API.
>
> If someone is interested by Qt mainly for QML, maybe the better way is to help us on DQuick, cause it's really similar, but we try to take advantages of D to do something more friendly.

From my personal point of view my main interest is in the programmatic Qt constructions (ie. Core & Widget module, not QML) as that's my itch that needs scratching. I'm not applying any effort ATM into the QML side of Qt. I think that a native DQuick implementation would be great and would probably provide a very compelling alternative to a wrapped QML (if that ever gets done by anybody) so I hope you get lets of help from anyone interested in that side of things.

On Monday, 17 February 2014 at 00:36:58 UTC, w0rp wrote:
> On Saturday, 15 February 2014 at 03:36:29 UTC, michaelc37 wrote:
>>
>>> [1]
>>> QtD is not actively maintained.  It existed on
>>> BitBucket: https://bitbucket.org/qtd/repo
>>> before someone else forked it and moved to
>>> GitHub: https://github.com/qtd-developers/qtd
>>
>> Probably worth mentioning.
>> There are also some recent startup efforts to generate qt bindings based on smoke qt.
>>
>> https://github.com/w0rp/dqt
>> https://github.com/GlobecSys/smoke.d
>>
>> However, its qt4.
>
> I'm working on this slowly. I'll post more when I actually have something worth looking at.
>
> My library takes the SMOKE data generated by smokeqt and then does at least 90% of the work in D code to manipulate it, for generating D source files and loading C++ function pointers at runtime so you can wrap C++ classes in D classes.

I'm sure we're facing similar problems from time to time, we should probably have a chat about that. Here's to hoping we both get a successful Qt wrapping and suddenly there is a choice of Qt wrapper!

Here's a great article about the problems with C++ bindings and Qt in particular:

http://setanta.wordpress.com/binding-c/

On 2/16/14, Abdulhaq <alynch4047@gmail.com> wrote:
> that should of course be
>
> https://github.com/alynch4047/smidgen

Nice. I've had a codegen project before which is currently stalled: https://github.com/AndrejMitrovic/dgen

Some docs I wrote about peculiarities of wrapping C++: https://github.com/AndrejMitrovic/dgen/wiki

Unfortunately the tool has a long history, it went through several rewrites. From basing the typeinfo extracted from doxygen (initially the tool was only supposed to be used to generate wxWidgets bindings), to later basing it on GCCXML, to later forking GCCXML and adding my own features (https://github.com/AndrejMitrovic/gccxml), to finally realizing I won't be able to get all C++ typeinfo from GCCXML because it's based on an old GCC parser. It was an uphill battle.

Ultimately I would have to re-purpose the tool to use Clang.

I did have some initial success. I've managed to autowrap the TagLib C++ library, some small XML libraries, but ultimately the tool needs proper typeinfo that GCCXML doesn't provide.

Clang itself has a C API, but from what I've read online it doesn't export enough C++ typeinfo either, so I'd have to use the Clang C++ interface instead (maybe libtooling or something of that sort).

I might get back to working on that tool one day, I don't know yet. I've got a big queue of things to work on.

Your project looks nice though.

On Monday, 17 February 2014 at 09:46:15 UTC, Andrej Mitrovic wrote:
>
> Nice. I've had a codegen project before which is currently stalled:
> https://github.com/AndrejMitrovic/dgen
>
> Some docs I wrote about peculiarities of wrapping C++:
> https://github.com/AndrejMitrovic/dgen/wiki

Interesting reading, it seems we've run into the same problems (not surprising I suppose) and even come up with the same solutions (virtual functions, return-by-value).

>
> Unfortunately the tool has a long history, it went through several
> rewrites. From basing the typeinfo extracted from doxygen (initially
> the tool was only supposed to be used to generate wxWidgets bindings),
> to later basing it on GCCXML, to later forking GCCXML and adding my
> own features (https://github.com/AndrejMitrovic/gccxml), to finally
> realizing I won't be able to get all C++ typeinfo from GCCXML because
> it's based on an old GCC parser. It was an uphill battle.
>
> Ultimately I would have to re-purpose the tool to use Clang.
>
> I did have some initial success. I've managed to autowrap the TagLib
> C++ library, some small XML libraries, but ultimately the tool needs
> proper typeinfo that GCCXML doesn't provide.
>
> Clang itself has a C API, but from what I've read online it doesn't
> export enough C++ typeinfo either, so I'd have to use the Clang C++
> interface instead (maybe libtooling or something of that sort).
>

I feel your pain! Because my main target library was Qt I was able to bypass the whole typeinfo extraction issue by basing the binding generator on sip files and then primarily using the PyQt sip files - with the penalty that the PyQt wrapping will therefore be GPL. However, seeing how hard it can be to extract the typeinfo automatically (and the object ownership information still will need to be done manually) I'm very glad that I fell into doing it that way. A feature evolution for me would be to try and bolt on an automated typeinfo extractor front end. Riverbank already have one for generating sip files but it's practically undocumented and hard to use.


> I might get back to working on that tool one day, I don't know yet.
> I've got a big queue of things to work on.

Same here - so much to do and so little time! If I'm not careful I end up with analysis paralysis and just browse HN and these forums instead of catching up on my reading list or coding something up. Speaking of which....

On 2014-02-17 10:45, Andrej Mitrovic wrote:

> Clang itself has a C API, but from what I've read online it doesn't
> export enough C++ typeinfo either, so I'd have to use the Clang C++
> interface instead (maybe libtooling or something of that sort).

Why not contribute to Clang by adding the missing functionality. Then contributing to DStep ;)

-- 
/Jacob Carlborg

Le 17/02/2014 08:48, w0rp a écrit :
> On Monday, 17 February 2014 at 01:16:44 UTC, Xavier Bigand wrote:
>> Le 17/02/2014 01:36, w0rp a écrit :
>>> On Saturday, 15 February 2014 at 03:36:29 UTC, michaelc37 wrote:
>>> I'll try Qt5 later. The main reason I'm trying to get Qt4 working at the
>>> moment is that I have experience with Qt4, but not with Qt5, and from my
>>> understanding a lot of the advantages of Qt5 come from QML, and I don't
>>> quite understand yet how QML would tie together with a D API.
>>
>> If someone is interested by Qt mainly for QML, maybe the better way is
>> to help us on DQuick, cause it's really similar, but we try to take
>> advantages of D to do something more friendly.
>
> Writing a native D GUI library instead of wrapping a C++ one is a good
> idea. My big problem with the wrapper around Qt I'm building is that it
> will never run as efficiently as a Qt application written in C++ would,
> so that might turn some people away. The main advantage of writing the
> wrapper is pretty much that it's just less work, as creating a cross
> platform toolkit with an API as nice as Qt's takes a lot of time and
> effort.

Yep, that why we are focus on the smallest part of Qt needed to create GUI. IMO all features of QtCore have to be directly in phobos (Network, serialization, signals,...), so only Widgets and QtQuick API stay here.

The advantage of QtQuick his the modernity and it stay really small, it's mainly a script engine (property binding) coupled with a 2D modern renderer based on rasterization.
We took lua as script language cause it can support property bindings without modifications. And the renderer just wait for contributions, the minimal functional target isn't really hard to get.

But polish stay hard to do.

Le 17/02/2014 09:18, eles a écrit :
> On Monday, 17 February 2014 at 07:48:51 UTC, w0rp wrote:
>> On Monday, 17 February 2014 at 01:16:44 UTC, Xavier Bigand wrote:
>>> Le 17/02/2014 01:36, w0rp a écrit :
>>>> On Saturday, 15 February 2014 at 03:36:29 UTC, michaelc37 wrote:
>
>> Writing a native D GUI library instead of wrapping a C++ one is a good
>> idea. My big problem with the wrapper around Qt I'm building is that
>> it will never run as efficiently as a Qt application written in C++
>> would, so that might turn some people away. The main advantage of
>> writing the wrapper is pretty much that it's just less work, as
>> creating a cross platform toolkit with an API as nice as Qt's takes a
>> lot of time and effort.
>
> I agree with this but, still, a wrapper around Qt 5 (not 4!) would be a
> huge thing, especially if one wants to write Android Qt-based applications.

I can tell you Qt 5 miss some features for Android or have some bugs. I wrote some java bindings to solve Qt issues. It's not a big deal.
The main issue is the port of D and phobos on Android.

With DQuick we target openGL 2.1 to be compatible with openGL ES. We have iOS and Android in mind too.

Le 17/02/2014 09:54, Abdulhaq a écrit :
> On Monday, 17 February 2014 at 01:16:44 UTC, Xavier Bigand wrote:
>> Le 17/02/2014 01:36, w0rp a écrit :
>>> On Saturday, 15 February 2014 at 03:36:29 UTC, michaelc37 wrote:
>>> I'll try Qt5 later. The main reason I'm trying to get Qt4 working at the
>>> moment is that I have experience with Qt4, but not with Qt5, and from my
>>> understanding a lot of the advantages of Qt5 come from QML, and I don't
>>> quite understand yet how QML would tie together with a D API.
>>
>> If someone is interested by Qt mainly for QML, maybe the better way is
>> to help us on DQuick, cause it's really similar, but we try to take
>> advantages of D to do something more friendly.
>
>  From my personal point of view my main interest is in the programmatic
> Qt constructions (ie. Core & Widget module, not QML) as that's my itch
> that needs scratching. I'm not applying any effort ATM into the QML side
> of Qt. I think that a native DQuick implementation would be great and
> would probably provide a very compelling alternative to a wrapped QML
> (if that ever gets done by anybody) so I hope you get lets of help from
> anyone interested in that side of things.
>

I am completely agree with you, binding of Qt must be focused on Widgets and the core module.

I am dreaming to be able to convince some QtQuick developers to contribute to DQuick, we already have some things working better.
I am thinking to the property binding loop detection on which we are able to print the full call stack, where QML engine is only able to give the item not the property affected.
And with the power of D it's not necessary to modify existent code, here with Qt wrappers are needed.

On 2/17/14, Abdulhaq <alynch4047@gmail.com> wrote:
> Interesting reading, it seems we've run into the same problems
> (not surprising I suppose) and even come up with the same
> solutions (virtual functions, return-by-value).

And then there are things like trying to allow access to protected methods (meaning you have to re-declare them public for the C wrappers to access them), which isn't easy because simply re-declaring them only works in /some/ contests (specifically when overloads come into play it's a mess). And then having to handle namespaces.. etc etc. It's very easy to burn out. :)

I can't even recall how I planned to support multiple inheritance. I think I was planning on using interfaces, but to keep all classes neatly castable up the hirearchy at the D side it would probably mean having to make /all/ classes inherit from interfaces.

And then you have to worry about memory management. Fun stuff..

On 2/17/14, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:
> On 2/17/14, Abdulhaq <alynch4047@gmail.com> wrote:
>> Interesting reading, it seems we've run into the same problems
>> (not surprising I suppose) and even come up with the same
>> solutions (virtual functions, return-by-value).
>
> And then there are things like trying to allow access to protected methods

It looks like I already described this in the wiki, I'm repeating myself here. :)