>
> The code is tested and just-about one-click build. Currently it's
> in a subversion repository but I plan to move to github. I'd love
> someone to use Smidgen to try wrapping a small C++ library as I
> think it would make the job quite easy, if anyone reads this
> (since I have not formally announced the thing yet) then please
> let me know and I'll get the code out there).
>
yes github please.. i'd like to check this out.

> yes github please.. i'd like to check this out.

OK I'm in the process of migrating the code to github. I was in such a hurry yesterday evening I didn't list the features properly:

FEATURES
========

* All D
* Understandable, maintainable code
* Wraps protected and virtual methods, allows virtual methods to be overridden in D
* Mixin classes in target C++ library supported
* Allows custom type conversions between C++ and D types
* C++ enums mapped to D enums and are type checked in D
* Wraps nested C++ classes
* Tested
* Based on the sip format. This is well proven and allows simplified maintenance of wrappers for multiple versions of the target library.  (All larger target libraries will need some ongoing maintenance of the wrapper regardless of the wrapping technology).

Once all the code is in github I'll just check that a totally clean build is working, and then give you a heads up. FYI the repository is at

https://github.com/alynch4047/smidgen/tree/master/morsel

> https://github.com/alynch4047/smidgen/tree/master/morsel

that should of course be

https://github.com/alynch4047/smidgen

On Sunday, 16 February 2014 at 02:37:50 UTC, michaelc37 wrote:
>>
>> The code is tested and just-about one-click build. Currently it's
>> in a subversion repository but I plan to move to github. I'd love
>> someone to use Smidgen to try wrapping a small C++ library as I
>> think it would make the job quite easy, if anyone reads this
>> (since I have not formally announced the thing yet) then please
>> let me know and I'll get the code out there).
>>
> yes github please.. i'd like to check this out.

OK I believe that smidgen is now fully hosted on github.

Using smidgen as it stands I would hope that you could wrap a simple C++ library. However, no-one else has tried it yet so there are bound to be a few teething problems, please feel free to email me (anyone trying it out or just taking a look) at alynch4047 at gmail dot com if you have any questions / problems. Alternatively perhaps we could use one of the forums here??

I have not yet uploaded the initial Qt5 wrapping (or VTK), I'll try to do that over the next day or two.

On Sunday, 16 February 2014 at 20:05:27 UTC, Abdulhaq wrote:
> On Sunday, 16 February 2014 at 02:37:50 UTC, michaelc37 wrote:
>>>
>>> The code is tested and just-about one-click build. Currently it's
>>> in a subversion repository but I plan to move to github. I'd love
>>> someone to use Smidgen to try wrapping a small C++ library as I
>>> think it would make the job quite easy, if anyone reads this
>>> (since I have not formally announced the thing yet) then please
>>> let me know and I'll get the code out there).
>>>
>> yes github please.. i'd like to check this out.
>
> OK I believe that smidgen is now fully hosted on github.
>
> Using smidgen as it stands I would hope that you could wrap a simple C++ library. However, no-one else has tried it yet so there are bound to be a few teething problems, please feel free to email me (anyone trying it out or just taking a look) at alynch4047 at gmail dot com if you have any questions / problems. Alternatively perhaps we could use one of the forums here??
>
> I have not yet uploaded the initial Qt5 wrapping (or VTK), I'll try to do that over the next day or two.

D wrappings for VTK would be great!

I have a SWIG version of D-VTK but it is a little flaky and soooo slow to generate. I've just started work developing D wrapper for VTK based on their Java wrapper but it's very early stages (started yesterday in fact).

If you've got a VTK wrapping that generates D code I'd love to check it out.

Cheers,
ed

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. If you have the SMOKE data already in a shared library already I recommend this, as you can get much better results this way. There is some additional C++ code for two reasons. First, because smokeqt doesn't generate bindings for QString, which is weird and annoying, so I have to provide functions with C calling conventions written in C++ for creating QStrings. The second reason is that the functions for creating and deleting the QtGUI and QtCore SMOKE structs just don't seem to work when you call them directly from D, but do work when I wrap them again in functions with C calling conventions.

Right now I have a generator which spits out a full list of methods and classes, also enums with the right values at the moment, and I need to do more work to get it to map from C++ type to D type, generate required import lines for tying things together, and then generate the snippets of code in methods to tie to the code I wrote before for loading the function pointers on startup. After that it should work, but not well enough to be that useful.

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 I manage to get my bindings to work, I could see how you could take that and move on to creating a generalised C++ binding generator, but what you get would never be that great. It would be much better to have some kind of support in the language or runtime for doing the remaining things D can't do at the moment, like matching C++ function calling conventions, calling virtual methods, I don't know how you'd get multiple inheritance or stack-based classes to work. I get why all of this stuff just doesn't exist already, because it's really hard to implement and requires a lot of careful thought about it.

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.

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.

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 have a SWIG version of D-VTK but it is a little flaky and soooo slow to generate. I've just started work developing D wrapper for VTK based on their Java wrapper but it's very early stages (started yesterday in fact).
>
> If you've got a VTK wrapping that generates D code I'd love to check it out.
>

The smidgen binding generator is (I believe) sufficiently feature rich to wrap all of VTK, but I've only wrapped a half dozen classes as proof of concept for now (I've been focussing on Qt5). My plan on the VTK side has been to use the automated binding generator in VTK to produce the *.sip (similar to *.h) files that smidgen needs.

VTK is quite a large library so I would expect the wrapper to be a bit slow to generate, however it shouldn't be flaky when running. I would suspect that you've got a glitch in object ownership somewhere? My plan has been that the automatic VTK binding generator for e.g. python knows about object ownership, and so I can tap in to that to generate the correct smidgen annotations that are needed for that aspect of the binding. I've also found that you can get problems when wrapped methods return instances typed as base classes that need casting to more specific types.

I'm wondering if we can pool our efforts somehow? Because I need to finish the last parts of smidgen (e.g. enums with specific values and subtleties with C++ multiple inheritance)and the Qt5 wrapping side of it I couldn't divert much from my current trajectory, but if you get a chance then have a look at what smidgen is doing and see if you think you'd get any benefit using it (and you'd have my efforts working to extend smidgen for you if needed). As soon as I've uploaded the current smidgen-vtk I'll notify here.

Another way we might be able to cooperate is getting a full understanding of the current built-in VTK binding generator technology.

Is your SWIG wrapping online somewhere? - I'd like to take a look.