D - Qt D bindings?
- trejkaz xaoza.net (13/13) Apr 19 2004 I was wondering... Qt feels like the best API for writing GUI apps, but ...
- Ilya Minkov (12/28) Apr 20 2004 It was considered and then discarded, since Qt is GPL on Unix and
- Trejkaz Xaoza (23/33) Apr 20 2004 Inflexible how, specifically? Everything is somewhat inflexible.
- John Reimer (2/13) Apr 20 2004 Oh? The port is not necessarily a "pure" port ;-). It would be too
- Ilya Minkov (22/51) Apr 20 2004 Hm, what did i mean? ... Not very well suited to the fast changing
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
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
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.netI 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
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.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
Trejkaz Xaoza schrieb:In article <c638jr$2cpc$1 digitaldaemon.com>, Ilya Minkov says...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.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.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?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.There is a object-oriented GTK wrapper: dui.sf.netI 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.)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. -eyeWork 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.
Apr 20 2004