I was wondering... Qt feels like the best API for writing GUI apps, but it's written in one of the most cumbersome languages around.  Now, technically there are C bindings to Qt so I can use it from D, but then I lose the OO-ness of Qt.

Has anyone tinkered with setting up "proper" D bindings for Qt?  I would imagine it would make life a lot easier for those of us who are about to enter this realm. :-)

I'm guessing on Linux it might not even be too hard because apparently the KDE team have a standard way they create language bindings for all of Qt and KDE. Whether that would make a way to link the Windows version... who knows.  I need to support both in the end though or my app will only ever see my desktop. :-/

--
Jabber ID: trejkaz@jabber.xaoza.net
"Jabber: Because all other instant messengers suck."

It was considered and then discarded, since Qt is GPL on Unix and non-free on other OS, which makes it usually a bad choice for small commercial use. Besides, it is somewhat inflexible.

There is a object-oriented GTK wrapper: dui.sf.net

There is also a SWIG port here: http://andy.tadan.us/d/ -- i guess it could generate a wxWindows binding which would work similarly to wxPython, just in D. It would also be of use to anyone who would try to port any other C++ toolkit - it creates C-side wrappers for C++ code, then imports and wraps this code into D.

Work is being done on a pure D GUI toolkit based off IBM SWT.

-eye

trejkaz@xaoza.net schrieb:
> I was wondering... Qt feels like the best API for writing GUI apps, but it's
> written in one of the most cumbersome languages around.  Now, technically there
> are C bindings to Qt so I can use it from D, but then I lose the OO-ness of Qt.
> 
> Has anyone tinkered with setting up "proper" D bindings for Qt?  I would imagine
> it would make life a lot easier for those of us who are about to enter this
> realm. :-)
> 
> I'm guessing on Linux it might not even be too hard because apparently the KDE
> team have a standard way they create language bindings for all of Qt and KDE.
> Whether that would make a way to link the Windows version... who knows.  I need
> to support both in the end though or my app will only ever see my desktop. :-/
> 
> --
> Jabber ID: trejkaz@jabber.xaoza.net
> "Jabber: Because all other instant messengers suck."

In article <c638jr$2cpc$1@digitaldaemon.com>, Ilya Minkov says...
>
>It was considered and then discarded, since Qt is GPL on Unix and non-free on other OS, which makes it usually a bad choice for small commercial use. Besides, it is somewhat inflexible.

Inflexible how, specifically?  Everything is somewhat inflexible.

As far as the Qt licenses go, Qt/Mac is either going GPL or it's already
happened, and whereas Qt/Windows is non-free, it's not like no open
source project has produced Windows binaries which are linked to it
since you can (a) ask Trolltech personally since they're not ogres,
and (b) there is a recent non-commercial (but still non-free) release
which comes with a $30 book.  I think that's a small price to pay for
the current easiest API to use.

>There is a object-oriented GTK wrapper: dui.sf.net

I would have nothing against Gtk if its widgets made even the slightest attempt to be convenient.  I don't see why I should have to manually add the copy, cut, paste commands to a context menu and set up a listener to pop up the context menu, on every single text input field I ever create. Of course I'm still learning Qt so for all I know it might be the same on that.  Although I know wxWindows doesn't have the problem, even if wxGTK does.  (The non-existence of wxQt is extremely frustrating as well.)

>There is also a SWIG port here: http://andy.tadan.us/d/ -- i guess it could generate a wxWindows binding which would work similarly to wxPython, just in D. It would also be of use to anyone who would try to port any other C++ toolkit - it creates C-side wrappers for C++ code, then imports and wraps this code into D.

This sounds promising since I've seen SWIG in action with Java. I'll see if I can beat it into submission. :-)

>Work is being done on a pure D GUI toolkit based off IBM SWT.

What's the plan, take the worst toolkit from Java and port it to a new language?  If D (a language with garbage collection) is planning to take off, the last thing developers would want is an API where you're forced to manually deallocate every object.

TX

>>Work is being done on a pure D GUI toolkit based off IBM SWT.
> 
> 
> What's the plan, take the worst toolkit from Java and port it to a new
> language?  If D (a language with garbage collection) is planning to take
> off, the last thing developers would want is an API where you're forced to
> manually deallocate every object.
> 
> TX
> 
> 

Oh? The port is not necessarily a "pure" port ;-).  It would be too ugly.  There's plenty of room to improve upon it using D features.

Trejkaz Xaoza schrieb:

> In article <c638jr$2cpc$1@digitaldaemon.com>, Ilya Minkov says...
> 
>>It was considered and then discarded, since Qt is GPL on Unix and non-free on other OS, which makes it usually a bad choice for small commercial use. Besides, it is somewhat inflexible.
> 
> Inflexible how, specifically?  Everything is somewhat inflexible.

Hm, what did i mean? ... Not very well suited to the fast changing world? It does not support extensions (for example acessibility etc) when they are added to OS. Nor does GTK in fact. Ok, i'm somewhat biased there. Oh, it has "slight" problems with inheritance, or rather that you cannot extend its classes, at least it would not allow as i learned it a while ago.

> As far as the Qt licenses go, Qt/Mac is either going GPL or it's already
> happened, and whereas Qt/Windows is non-free, it's not like no open
> source project has produced Windows binaries which are linked to it
> since you can (a) ask Trolltech personally since they're not ogres,
> and (b) there is a recent non-commercial (but still non-free) release
> which comes with a $30 book.  I think that's a small price to pay for
> the current easiest API to use.

Which makes it only viable for personal, GPLed and big commercial projects. Man, was it a grief with Kylix - exactly the same situation!

Do you think Qt is easier than FOX?

>>There is a object-oriented GTK wrapper: dui.sf.net
> 
> I would have nothing against Gtk if its widgets made even the slightest
> attempt to be convenient.  I don't see why I should have to manually add
> the copy, cut, paste commands to a context menu and set up a listener to
> pop up the context menu, on every single text input field I ever create.
> Of course I'm still learning Qt so for all I know it might be the same on
> that.  Although I know wxWindows doesn't have the problem, even if wxGTK
> does.  (The non-existence of wxQt is extremely frustrating as well.)

wxGTK does? :/

OK, i think DUI might be extended as compared to GTK in respect to that, but i think it is important to have a platform-independant widget set, which would also candidate for big improvements. SUN being behind it and so.

>>Work is being done on a pure D GUI toolkit based off IBM SWT.
> 
> What's the plan, take the worst toolkit from Java and port it to a new
> language?  If D (a language with garbage collection) is planning to take
> off, the last thing developers would want is an API where you're forced to
> manually deallocate every object.

Why is it worst for Java? Besides, D "port" is not a port, it would be a real D toolkit using all language feats optimally and being a living reference of how to solve common problems in D, which is not so obvious at all. It shall work better in D than in Java. wxWindows was another candidate for porting, but was discarded due to its C++ish ballast. And if even wxWindows was discarded, Qt would be even more probably, because of the licensing. Of course, noone ties your hands if you like to.

-eye