Here is an article about difficulties in cross-platform GUI development (nothing new, really).

http://www.informit.com/articles/article.aspx?p=787261

QtD doesn't need GCD anymore, apparently. I remember there were several fussy requirements for QtD a year or so ago that were rather off-putting.

http://www.dsource.org/projects/qtd

Another GUI toolkit I have come across is this one:

http://www.tecgraf.puc-rio.br/iup/

It sounds very interesting and is based on ANSI C and / or Lua. If D bindings aren't too hard to implement it might be of interest to the D community.

It runs on OS X too using X11, but maybe the GTKD add on for Mac has solved this issue already:

http://www.tecgraf.puc-rio.br/iup/en/toolkits.html

On Friday, 28 December 2012 at 23:10:54 UTC, Chris wrote:
> Here is an article about difficulties in cross-platform GUI
>
> Another GUI toolkit I have come across is this one:
>
> http://www.tecgraf.puc-rio.br/iup/
>
Sorry, just realized there's an abandoned DIUP project.

On 2012-12-28 19:50, Chris wrote:

> And starting from scratch with D2?

That would be the worst idea.

> How much would that take?

I would be stupid to start from the beginning. That would take most effort and the most time of all options.

-- 
/Jacob Carlborg

On Friday, 28 December 2012 at 23:29:46 UTC, Jacob Carlborg wrote:
> On 2012-12-28 19:50, Chris wrote:
>
>> And starting from scratch with D2?
>
> That would be the worst idea.
>
>> How much would that take?
>
> I would be stupid to start from the beginning. That would take most effort and the most time of all options.

Perhaps yes, I'm not yet familiar enough with the internal mechanisms of porting and I don't know D1 because I started with D2 (Phobos).

On 2012-12-29 13:10, Chris wrote:

> Perhaps yes, I'm not yet familiar enough with the internal mechanisms of
> porting and I don't know D1 because I started with D2 (Phobos).

D1 is just missing some features and we're using Tango here instead of Phobos. But since this is a port of a Java library, you basically just think Java, if you know it.

-- 
/Jacob Carlborg

On 2012-12-29 00:10, Chris wrote:
> Here is an article about difficulties in cross-platform GUI development
> (nothing new, really).
>
> http://www.informit.com/articles/article.aspx?p=787261
>
> QtD doesn't need GCD anymore, apparently. I remember there were several
> fussy requirements for QtD a year or so ago that were rather off-putting.
>
> http://www.dsource.org/projects/qtd

Don't if QtD works. It's not native and it hasn't been update for two years. Last thing I heard they struggled with the C++ bindings.

-- 
/Jacob Carlborg

On Saturday, 29 December 2012 at 12:35:22 UTC, Jacob Carlborg wrote:
> On 2012-12-29 13:10, Chris wrote:

> D1 is just missing some features and we're using Tango here instead of Phobos. But since this is a port of a Java library, you basically just think Java, if you know it.

Yes, I know Java and I wrote a no-nonsense application using SWT/JFace a couple of years ago, so I'm basically familiar with both of them. I know Cocoa & Objective-C too. That's why I'd like to help you out with the DWT Mac project, time permitting.

I was also thinking about an interim solution that uses Cocoa as UI layer and have the business logic entiely in D2 using a bridge or something. I have read your description of the ObjC bridge and have done something similar too. I was thinking that developing minimal binding/bridging mechanisms for various languages would be a good thing in order to glue D to anything you want. Again, time is a crucial factor.

On 2012-12-29 13:55, Chris wrote:

> I have read your description of the ObjC bridge and have done
> something similar too. I was thinking that developing minimal
> binding/bridging mechanisms for various languages would be a good thing
> in order to glue D to anything you want. Again, time is a crucial factor.

The problem with this bridge is bloat. A Hello World GUI application takes around 60MB in size. It's basically a dead end.

This is a better solution:

http://michelf.ca/projects/d-objc/

It adds support for extern (Objective-C), i.e. ABI compatibility with Objective-C. Michel Fortin hasn't worked on this for a couple of years but I have started to continue on his work.

-- 
/Jacob Carlborg

On Saturday, 29 December 2012 at 15:07:06 UTC, Jacob Carlborg wrote:
> On 2012-12-29 13:55, Chris wrote:
>
 problem with this bridge is bloat. A Hello World GUI
> application takes around 60MB in size. It's basically a dead end.
>
> This is a better solution:
>
> http://michelf.ca/projects/d-objc/
>
> It adds support for extern (Objective-C), i.e. ABI compatibility with Objective-C. Michel Fortin hasn't worked on this for a couple of years but I have started to continue on his work.

I've heard of this project but always had one problem or another with it. I agree that it is the better solution but I could never make it work properly (probably my own fault).

I agree that bridges are never a good solution (cf. the Cocoa-Java Bridge). I was thinking of a mechanism that isn't bloated, i.e. that only takes what it needs, if that's at all possible. I've succeeded in using ObjC from D (via D's C compatiblity) and it wasn't bloated. My idea is to call D from within a Cocoa application, so that Cocoa is only the interface layer. In the same way D could take care of the business logic on other platforms too and use a C based GUI having a thin "translation" layer between the two. It's not as smooth as having native bindings and a unified API like DWT, wxD etc. but it gives me freedom of choice and flexibility.

Btw, how does D fare with mobile phones? Are there issues with 32 and 64 bit? The JavaScript backend (see post above) might come in handy here.

On 2012-12-29 16:38, Chris wrote:

> I've heard of this project but always had one problem or another with
> it. I agree that it is the better solution but I could never make it
> work properly (probably my own fault).

If you download the pre-compiled alpha it should just work out of the box just as a regular DMD release does.

> I agree that bridges are never a good solution (cf. the Cocoa-Java
> Bridge). I was thinking of a mechanism that isn't bloated, i.e. that
> only takes what it needs, if that's at all possible. I've succeeded in
> using ObjC from D (via D's C compatiblity) and it wasn't bloated.

I created basically complete bindings for the Foundation and AppKit frameworks and some others as well. That will cause bloat. I think it's either virtual methods that cannot be optimized away or templates that causing the bloat. The problem with the approached used by DWT/SWT is they only create bindings for what's needed. I guess that's also why it's not as bloated. Then one needs to create binding for each new method one wants to use. That's quite a cumbersome workflow.

> My idea is to call D from within a Cocoa application, so that Cocoa is only
> the interface layer. In the same way D could take care of the business
> logic on other platforms too and use a C based GUI having a thin
> "translation" layer between the two. It's not as smooth as having native
> bindings and a unified API like DWT, wxD etc. but it gives me freedom of
> choice and flexibility.

Yeah, that would be possible as well.

> Btw, how does D fare with mobile phones? Are there issues with 32 and 64
> bit? The JavaScript backend (see post above) might come in handy here.

Mobile devices are usually use the ARM architecture, which isn't supported by DMD. You would either need to use GDC or LDC. I think the biggest problem here is that the runtime isn't properly adapted to ARM.

-- 
/Jacob Carlborg