www.digitalmars.com         C & C++   DMDScript  

D - Qt D bindings?

reply trejkaz xaoza.net writes:
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."
Apr 19 2004
parent reply Ilya Minkov <minkov cs.tum.edu> writes:
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."
Apr 20 2004
parent reply Trejkaz Xaoza <trejkaz xaoza.net> writes:
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
Apr 20 2004
next sibling parent John Reimer <jjreimer telus.net> writes:
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.
Apr 20 2004
prev sibling parent Ilya Minkov <minkov cs.tum.edu> writes:
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
Apr 20 2004