• Mars (28/28) Oct 07 2006 Hello,
• Hasan Aljudy (8/49) Oct 07 2006 (I assume that by "widget set" you actually mean "gui library")
• Jeff (36/43) Oct 09 2006 I agree; I can understand that people want GUI libraries for D available...
• Don Clugston (13/35) Oct 09 2006 I agree, although I'd phrase it differently. It's not about taking a
• Walter Bright (10/22) Oct 09 2006 I agree, too. D is a multiparadigm language, and that's important for
• Kirk McDonald (7/8) Oct 09 2006 Sure it can! I've used plenty of faux-OOP C APIs (see also: the Python/C...
• Walter Bright (4/9) Oct 09 2006 True, but I did mean "can't" in the sense of "impractical" or "only if
• Mars (1/1) Oct 09 2006 Isn't that what the gtk people did?
• Josh Stern (4/5) Oct 09 2006 If you mean wrote an OO widget set in straight C, then "yes".
• =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= (6/9) Oct 10 2006 The current (wrapped) GUI toolkits take an OOP design (in C++), wrap it
• Josh Stern (9/16) Oct 09 2006 Just wanted to point out in case it wasn't clear that QtJava (and I thin...
• Josh Stern (34/80) Oct 09 2006 After the above, I was expecting to see some description below of what i...
• Jeff (55/133) Oct 10 2006 Before I reply, I should probably note that I didn't mean to come across...
• Josh Stern (37/141) Oct 10 2006 Sure. And before I read what you write below, let me clarify that
• Don Clugston (15/169) Oct 10 2006 This is interesting. Personally, I have never seen a GUI library that I
• Sean Kelly (3/7) Oct 10 2006 Definately.
• Josh Stern (54/76) Oct 10 2006 Can't comment on that without knowing which aspects of existing ones you
• Don Clugston (29/114) Oct 11 2006 and
• Bill Baxter (9/19) Oct 11 2006 I think in some ways, that's the layer that SDL targets.
• Fredrik Olsson (13/18) Oct 11 2006 I have two GUI libraries that I love:
• Georg Wrede (15/24) Oct 15 2006 Well, as I see it, a windowing toolkit may eve be written entirely in
• =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= (17/26) Oct 15 2006 Were there any takers on objectifying and templatizing a "D/Tk" ?
• =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= (20/24) Oct 08 2006 It used to be that much of the actual GUI still ran in Tcl, inside it...
• Mars (25/30) Oct 08 2006 Tk can be accessed both from Tcl (which is the usual thing to do) and
• =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= (9/21) Oct 08 2006 Ah, must confess I didn't look too hard either - thanks for the links!
• Mars (2/5) Oct 08 2006 Someone did a proof-of-concept implementation for C++/Tk, maybe you'll
• Mars (7/7) Oct 08 2006 I think this one is not a proof-of-concept implementation but the real d...
• =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= (19/25) Oct 09 2006 That looks more like some C++ hacks, to make it think that it is Tcl ?
• =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= (9/13) Oct 09 2006 Actually those callback things were kinda neat, with the parameters etc.
• Hasan Aljudy (4/5) Oct 08 2006 Really? Last time I checked, DWT was a /candidate/ for an official GUI;
• =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= (10/15) Oct 08 2006 Well, about the time that "digitalmars.D.dwt" newsgroup was founded ?
• Josh Stern (6/6) Oct 08 2006 Porting either PyQt (including its semi-automatic generation from
• =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= (7/13) Oct 09 2006 Besides being a somewhat hefty target to port (due to the sheer size),
• Josh Stern (17/32) Oct 09 2006 Porting Qt itself is both too much work and undesirable (because it woul...
• Josh Stern (15/22) Oct 09 2006 I was wrong about part of the above. The TrollTech commercial license
• =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= (22/37) Oct 10 2006 Actually this was what I meant, "make it accessible from D", not port.
• Josh Stern (46/89) Oct 10 2006 "Nice" is hard to argue with. I mean, running on an OS that had a nativ...
• =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= (30/64) Oct 10 2006 I was naively assuming that the library would eventually end up linking
• Josh Stern (32/71) Oct 10 2006 It depends what one means by system library:
• =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= (40/75) Oct 10 2006 What I was trying to say was that the toolkits I have been looking at
• Josh Stern (50/106) Oct 10 2006 Yes, because it is C based, using Gtk as an alternative to Win32 is a
• I.Lam (3/3) Oct 09 2006 According to my experience in TK/Python, TK is somehow ugly, and dated,

Mars <nospam null.void> writes:

Hello,

It seems many people is trying to give D a decent widget set without
much success. However I'm wondering why nobody has tried with Tk. It
seems to have all the features that would make it an ideal widget set for D:

Cross platform: Windows, Mac, Unix/X11

Native look and feel, native widgets, support for themes. Screenshots:

http://tktable.sourceforge.net/tile/screenshots/windowsxp.html
http://installbase.sourceforge.net/screenshots.shtml
http://hem.fyristorg.com/matben/examples/index.html
http://tkabber.jabber.ru/screenshots/0.9.6

Written in plain C, not C++
http://aspn.activestate.com/ASPN/docs/ActiveTcl/8.4/tcl/tk_9_contents.htm

Open source under an extremely permissive BSD license.

Complete, large number of widgets available.

Mature, well documented, several books available.
http://wiki.tcl.tk/

Several GUI builders available (no idea how well could they be 
integrated with D):
http://vtcl.sourceforge.net/ (free)
http://www.activestate.com/Products/ActiveTclProStudio/ (commercial)
others (?)

Actively developed. It's the default widget toolkit for Tcl and Python, 
and one of the best supported under Perl, which has two implementations, 
one that uses Tcl as a bridge (Tcl::Tk) and one that access the C API 
directly (Perl/Tk).

So... could Tk become D's GUI library of choice too? Or am I missing 
something?

More info: http://wiki.tcl.tk/477

Hasan Aljudy <hasan.aljudy gmail.com> writes:

(I assume that by "widget set" you actually mean "gui library")

I think a GUI for D should be written with D in mind from the start.
I didn't look at tk/tcl/whatever-it-is-called, but just when you say 
that it's written in C, this says to me it's not what D should adopt as 
an official gui library.

Having said that, I'm personally of the opinion that Harmonia is the GUI 
library that has the most potential.

Mars wrote:
 Hello,
 
 It seems many people is trying to give D a decent widget set without
 much success. However I'm wondering why nobody has tried with Tk. It
 seems to have all the features that would make it an ideal widget set 
 for D:
 
 Cross platform: Windows, Mac, Unix/X11
 
 Native look and feel, native widgets, support for themes. Screenshots:
 
 http://tktable.sourceforge.net/tile/screenshots/windowsxp.html
 http://installbase.sourceforge.net/screenshots.shtml
 http://hem.fyristorg.com/matben/examples/index.html
 http://tkabber.jabber.ru/screenshots/0.9.6
 
 Written in plain C, not C++
 http://aspn.activestate.com/ASPN/docs/ActiveTcl/8.4/tcl/tk_9_contents.htm
 
 Open source under an extremely permissive BSD license.
 
 Complete, large number of widgets available.
 
 Mature, well documented, several books available.
 http://wiki.tcl.tk/
 
 Several GUI builders available (no idea how well could they be 
 integrated with D):
 http://vtcl.sourceforge.net/ (free)
 http://www.activestate.com/Products/ActiveTclProStudio/ (commercial)
 others (?)
 
 Actively developed. It's the default widget toolkit for Tcl and Python, 
 and one of the best supported under Perl, which has two implementations, 
 one that uses Tcl as a bridge (Tcl::Tk) and one that access the C API 
 directly (Perl/Tk).
 
 So... could Tk become D's GUI library of choice too? Or am I missing 
 something?
 
 More info: http://wiki.tcl.tk/477

Jeff <psychobrat gmail.com> writes:

 I think a GUI for D should be written with D in mind from the start.
 I didn't look at tk/tcl/whatever-it-is-called, but just when you say 
 that it's written in C, this says to me it's not what D should adopt as 
 an official gui library.
 
 Having said that, I'm personally of the opinion that Harmonia is the GUI 
 library that has the most potential.

I agree; I can understand that people want GUI libraries for D available 
as soon as possible, and indeed there are people working on such 
projects (i.e. D bindings, ports and/or OO abstractions for existing 
toolkits). However, if we really want some thing /good/ and maintainable 
that can really take advantage of D's features, then starting from 
scratch seems like the best path to me.

Even if progress was to be fairly slow, surely I'm not the only one who 
would be enthused enough by such a project to maintain interest? 
Remember, this wouldn't rule out using other toolkits in the meantime, 
but could also provide us with a /really/ good one in the long run.

For anyone interested, the (utopian? <g>) vision I've had in my mind for 
some time of a fresh D windowing toolkit would be:

- Minimal use of native windows/widgets (only for top-level, and other 
cases where really needed?); a Swing-esque approach could be taken to 
native look and feel (making it "somebody else's job"); stops the 
responsibilities getting too tangled, and it seems to have worked pretty 
well for them.
- Well-defined basic components that everyone expects (all the buttons, 
menus, etc.) but also /eventually/ packages containing more complex 
components (e.g. pretty message dialogs with cleanly expandable "more 
info" sections, headers and footers; colour, date selection dialogs; 
etc.). Saving people from recreating common widgets (formatted text 
areas) could really set it apart from the rest, and people not working 
on the core architecture of the library could certainly lend a hand here.
- Developed along-side the D standard library which will no doubt (?) be 
getting a lot more attention once v1.0 of the D spec is out.
- It would be nice if it could take advantage of existing cross-platform 
libraries where possible (e.g. pango for advanced text rendering, etc.), 
but maybe not too practical?
- Drawing inspiration from Swing, SWT, GTK(gtkmm), QT and other 
toolkits, whilst noting what design traps can be avoided due to D's 
language features.
- The will to Do It Right, no matter how long it takes. We should be in 
this for the long haul.

Does anyone else think it would be worth it, or are most people content 
to try to tap into existing toolkits through D?

Don Clugston <dac nospam.com.au> writes:

Jeff wrote:
 I think a GUI for D should be written with D in mind from the start.
 I didn't look at tk/tcl/whatever-it-is-called, but just when you say 
 that it's written in C, this says to me it's not what D should adopt 
 as an official gui library.

 Having said that, I'm personally of the opinion that Harmonia is the 
 GUI library that has the most potential.

 
 I agree; I can understand that people want GUI libraries for D available 
 as soon as possible, and indeed there are people working on such 
 projects (i.e. D bindings, ports and/or OO abstractions for existing 
 toolkits). However, if we really want some thing /good/ and maintainable 
 that can really take advantage of D's features, then starting from 
 scratch seems like the best path to me.

 Even if progress was to be fairly slow, surely I'm not the only one who 
 would be enthused enough by such a project to maintain interest? 
 Remember, this wouldn't rule out using other toolkits in the meantime, 
 but could also provide us with a /really/ good one in the long run.

[snip]
 - The will to Do It Right, no matter how long it takes. We should be in 
 this for the long haul.

I agree, although I'd phrase it differently. It's not about taking a 
long time to do it, it's about spending most of your time on the 
fundamentals. It seems to me that the D language has progressed by 
spending a lot of time getting the basics right. It's like building an 
80-storey building -- for most of the construction time, it's just a 
really deep hole in the ground, and to onlookers it seems that nothing 
much is happening. Yet, once the foundations are in, the building can 
rise by 10 metres in a day. Look how quickly the D template system has 
developed. It was only possible because so much time was spent getting 
the basics right.

I think that a GUI library should be similar.

 Does anyone else think it would be worth it, or are most people content 
 to try to tap into existing toolkits through D?

Walter Bright <newshound digitalmars.com> writes:

Don Clugston wrote:
 I agree, although I'd phrase it differently. It's not about taking a 
 long time to do it, it's about spending most of your time on the 
 fundamentals. It seems to me that the D language has progressed by 
 spending a lot of time getting the basics right. It's like building an 
 80-storey building -- for most of the construction time, it's just a 
 really deep hole in the ground, and to onlookers it seems that nothing 
 much is happening. Yet, once the foundations are in, the building can 
 rise by 10 metres in a day. Look how quickly the D template system has 
 developed. It was only possible because so much time was spent getting 
 the basics right.
 
 I think that a GUI library should be similar.

I agree, too. D is a multiparadigm language, and that's important for 
library development because appealing designs shouldn't be shut out 
because they are impractical with D. For example, C++ can't do GUI 
toolkits that are based on gc. C++ can't do toolkits based on signals 
and slots (Trolltech had to write a C++ preprocessor to make that work). 
Java can't do template metaprogramming based designs. C can't do OOP 
based designs.

D can't do reflection based designs (at least for 1.0), but the rest 
should be feasible.

Kirk McDonald <kirklin.mcdonald gmail.com> writes:

Walter Bright wrote:
 C can't do OOP based designs.

Sure it can! I've used plenty of faux-OOP C APIs (see also: the Python/C 
API). It's just that it's usually annoying to use such things. :-)

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://pyd.dsource.org

Walter Bright <newshound digitalmars.com> writes:

Kirk McDonald wrote:
 Walter Bright wrote:
 C can't do OOP based designs.

 
 Sure it can! I've used plenty of faux-OOP C APIs (see also: the Python/C 
 API). It's just that it's usually annoying to use such things. :-)

True, but I did mean "can't" in the sense of "impractical" or "only if 
you're desperate". I don't think someone would want to design a gui 
toolkit around a desperate workaround <g>.

Mars <nospam null.void> writes:

Isn't that what the gtk people did?

Josh Stern <josh_usenet phadd.net> writes:

On Mon, 09 Oct 2006 18:30:48 -0500, Mars wrote:

 Isn't that what the gtk people did?

If you mean wrote an OO widget set in straight C, then "yes".
Also Xt/Xaw/Motif before them, among others.

If you meant derive something from Tk, then "no".

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:

Walter Bright wrote:

 True, but I did mean "can't" in the sense of "impractical" or "only if 
 you're desperate". I don't think someone would want to design a gui 
 toolkit around a desperate workaround <g>.

The current (wrapped) GUI toolkits take an OOP design (in C++), wrap it 
up in a faux-OOP C API and then mimics the original OOP design (in D)...
Not sure I would want to compare "desparate" and "workaround" parts ;-)

I *like* my current C APIs. They're simple. They work. "Good old rock".
--anders

Josh Stern <josh_usenet phadd.net> writes:

On Mon, 09 Oct 2006 14:43:46 -0700, Walter Bright wrote:

 D is a multiparadigm language, and that's important for 
 library development because appealing designs shouldn't be shut out 
 because they are impractical with D. For example, C++ can't do GUI 
 toolkits that are based on gc. C++ can't do toolkits based on signals 
 and slots (Trolltech had to write a C++ preprocessor to make that work). 
 Java can't do template metaprogramming based designs. C can't do OOP 
 based designs.

Just wanted to point out in case it wasn't clear that QtJava (and I think
PyQt) are GC'd in the normal way on the application side and allow
signals/slot use via different mechanisms which are then bridged to the
C++ library side. As written, QtJava uses weak references in a hash map to
auto-delete C++ roots when their corresponding Java objects get finalized,
but there are other ways that this could be done even without weak
reference support.  If D ultimately developed a native mechanism for
runtime signals/slots then it could be used instead and bridged.

Josh Stern <josh_usenet phadd.net> writes:

On Mon, 09 Oct 2006 17:57:22 +1000, Jeff wrote:

 I think a GUI for D should be written with D in mind from the start.
 I didn't look at tk/tcl/whatever-it-is-called, but just when you say 
 that it's written in C, this says to me it's not what D should adopt as 
 an official gui library.
 
 Having said that, I'm personally of the opinion that Harmonia is the GUI 
 library that has the most potential.

 
 I agree; I can understand that people want GUI libraries for D available 
 as soon as possible, and indeed there are people working on such 
 projects (i.e. D bindings, ports and/or OO abstractions for existing 
 toolkits). However, if we really want some thing /good/ and maintainable 
 that can really take advantage of D's features, then starting from 
 scratch seems like the best path to me.

After the above, I was expecting to see some description below of what it
means to "really take advantage of D's features" but I didn't find it, so
I'm really unsure.   It's clearly important for D that new application
code written in D should be able to sub-class objects/widgets in D and
have access to the full programming API, but if the bindings are done
correctly and the underlying widget set has good OO then it isn't
necessary for the underlying widget set to be written in D.  In
particular, PyQt and QtJava provide examples of this possibility.  So what
is the real idea?  


 Even if progress was to be fairly slow, surely I'm not the only one

who
 would be enthused enough by such a project to maintain interest?
 Remember, this wouldn't rule out using other toolkits in the meantime,
 but could also provide us with a /really/ good one in the long run.

What is meant by the long run depends on the target feature set.  Already
something like Tk or WxWindows or Qt has an incredible number of man-years
invested and new development continues.   That's not to say anything
negative about the educational and/or fun benefits of writing a new widget
lib from scratch so long as one is clear that the purpose if fun and/or
education.   But if the goal is a superior end product, especially if
achieving that goal is essential to the fun, then a lot more needs to be
said about how and why that might happen.


 For anyone interested, the (utopian? <g>) vision I've had in my mind for
 some time of a fresh D windowing toolkit would be:
 
 - Minimal use of native windows/widgets (only for top-level, and other
 cases where really needed?); a Swing-esque approach could be taken to
 native look and feel (making it "somebody else's job"); stops the
 responsibilities getting too tangled, and it seems to have worked pretty
 well for them.

Both Gtk and Qt have converged on methods to allow pluggable look and
feel.  If some aspect of their current ability in this category is
lacking, fixing it directly would be the straightest path.  Gnome and KDE
have parallel and increasingly interoperable methods for telling a set of
applications to conform to the same updated look and feel at runtime.

 - Well-defined basic components that everyone expects (all the buttons,
 menus, etc.) but also /eventually/ packages containing more complex
 components (e.g. pretty message dialogs with cleanly expandable "more
 info" sections, headers and footers; colour, date selection dialogs;
 etc.). Saving people from recreating common widgets (formatted text
 areas) could really set it apart from the rest, and people not working
 on the core architecture of the library could certainly lend a hand
 here.

This sounds like policy stuff ath the desktop (Gnome or KDE) level. 
Parallel questions to the above here is "What are the architectural
limitations of gtk ot Qt that you see as limiting what you want to do here?


 - Developed along-side the D standard library which will no doubt
 (?) be getting a lot more attention once v1.0 of the D spec is out. - It
 would be nice if it could take advantage of existing cross-platform
 libraries where possible (e.g. pango for advanced text rendering, etc.),
 but maybe not too practical?

Trying to specify a single "standard" GUI toolkit for D is probably not a
good idea.   Java had a lot more reason than D for trying to do this
(goals of sandbox security capability abd hyper-portability) and still
suffers a lot as a desktop tool because they got it wrong twice. 

 - Drawing inspiration from Swing, SWT, GTK(gtkmm), QT and other
 toolkits, whilst noting what design traps can be avoided due to D's
 language features.
 - The will to Do It Right, no matter how long it takes. We should be in
 this for the long haul.

What are the design traps you think D will allow you to avoid?

 Does anyone else think it would be worth it, or are most people content
 to try to tap into existing toolkits through D?

I'd like to understand the concrete ideas that justify the wording
"content".

Jeff <psychobrat gmail.com> writes:

Before I reply, I should probably note that I didn't mean to come across 
as if I were claiming any authority or expertise on UI toolkits in 
general, so I'm sorry if I did; my comments were mostly just my personal 
opinion from my limited experience.

Josh Stern wrote:

 I agree; I can understand that people want GUI libraries for D available 
 as soon as possible, and indeed there are people working on such 
 projects (i.e. D bindings, ports and/or OO abstractions for existing 
 toolkits). However, if we really want some thing /good/ and maintainable 
 that can really take advantage of D's features, then starting from 
 scratch seems like the best path to me.

 
 After the above, I was expecting to see some description below of what it
 means to "really take advantage of D's features" but I didn't find it, so
 I'm really unsure.   It's clearly important for D that new application
 code written in D should be able to sub-class objects/widgets in D and
 have access to the full programming API, but if the bindings are done
 correctly and the underlying widget set has good OO then it isn't
 necessary for the underlying widget set to be written in D.  In
 particular, PyQt and QtJava provide examples of this possibility.  So what
 is the real idea?  

By "really take advantage of D's features", I only meant that a faithful 
translation of an existing OO windowing toolkit wouldn't really have 
much room to play with D's features, since it would be expected to 
behave in an all but identical manner to the original (so why not just 
use the language in which it's already written?).

As far as D wrappers for existing toolkits are concerned, I'd be much 
more enthusiastic about these than attempts to translate (and keep 
up-to-date and clean), say, SWT. "DUI"/"DUIT" started looking like a 
pretty attractive idea once the decision was made to just focus on being 
a GTK wrapper (rather than using native controls on each target 
platform), and I guess I could be happy using a GTK wrapper now that it 
seems to work pretty well on Windows. I'm yet to see a QT application 
that doesn't look horribly ugly to me. I'm sure it's a quite capable 
toolkit, but it's hard to feel good about using it given that. (Once 
again, personal opinion only, there).

 Even if progress was to be fairly slow, surely I'm not the only one

 who
 would be enthused enough by such a project to maintain interest?
 Remember, this wouldn't rule out using other toolkits in the meantime,
 but could also provide us with a /really/ good one in the long run.

 
 What is meant by the long run depends on the target feature set.  Already
 something like Tk or WxWindows or Qt has an incredible number of man-years
 invested and new development continues.   That's not to say anything
 negative about the educational and/or fun benefits of writing a new widget
 lib from scratch so long as one is clear that the purpose if fun and/or
 education.   But if the goal is a superior end product, especially if
 achieving that goal is essential to the fun, then a lot more needs to be
 said about how and why that might happen.

I don't have a full answer to that given my total lack of experience 
writing windowing toolkits... but if proven concepts could be taken from 
multiple other toolkits rather than trying to clone one exactly, we 
wouldn't need to be playing catch up to the original, could try to 
simplify some things by making use of D's delegates, templates, S&S 
mechanism (if that goes ahead), etc. Ideally it would be nice to have 
something usable that was competitive with existing toolkits, but even 
this didn't happen, I wouldn't consider the venture a complete waste.

 For anyone interested, the (utopian? <g>) vision I've had in my mind for
 some time of a fresh D windowing toolkit would be:

 - Minimal use of native windows/widgets (only for top-level, and other
 cases where really needed?); a Swing-esque approach could be taken to
 native look and feel (making it "somebody else's job"); stops the
 responsibilities getting too tangled, and it seems to have worked pretty
 well for them.

 
 Both Gtk and Qt have converged on methods to allow pluggable look and
 feel.  If some aspect of their current ability in this category is
 lacking, fixing it directly would be the straightest path.  Gnome and KDE
 have parallel and increasingly interoperable methods for telling a set of
 applications to conform to the same updated look and feel at runtime.

I don't disagree. I'm just saying what I'd like if the decision were 
already made to write a new toolkit in D; not trying to justify such a 
decision.

 - Well-defined basic components that everyone expects (all the buttons,
 menus, etc.) but also /eventually/ packages containing more complex
 components (e.g. pretty message dialogs with cleanly expandable "more
 info" sections, headers and footers; colour, date selection dialogs;
 etc.). Saving people from recreating common widgets (formatted text
 areas) could really set it apart from the rest, and people not working
 on the core architecture of the library could certainly lend a hand
 here.

 
 This sounds like policy stuff ath the desktop (Gnome or KDE) level. 
 Parallel questions to the above here is "What are the architectural
 limitations of gtk ot Qt that you see as limiting what you want to do here?

This is just part of a vague wish list. The idea of having lots of more 
advanced pre-built components standard really appeals to me. For 
example, I'd often want to present an error message to the user with 
some advanced information available that would not normally be desired. 
To keep it clean, it would be good to have an expandable section. If 
this kind of dialog was available stock, then users of the toolkit would 
be more likely to take advantage of them than if they had to write it 
themselves.

As for architectural limitations... none that I can imagine (see above).

 - Developed along-side the D standard library which will no doubt
 (?) be getting a lot more attention once v1.0 of the D spec is out. - It
 would be nice if it could take advantage of existing cross-platform
 libraries where possible (e.g. pango for advanced text rendering, etc.),
 but maybe not too practical?

 
 Trying to specify a single "standard" GUI toolkit for D is probably not a
 good idea.   Java had a lot more reason than D for trying to do this
 (goals of sandbox security capability abd hyper-portability) and still
 suffers a lot as a desktop tool because they got it wrong twice. 

Sorry, I didn't mean to imply that it should be a standard GUI toolkit 
for D. By that I just meant that it would be worth waiting to see where 
the D standard library ends up going (rather than being too eager to 
start developing a new toolkit now) to so it and v1.0 of the D spec 
could be taken advantage of, rather than potentially duplicating a lot 
of more general functionality, or failing to utilise features that may 
be added to the spec before v1.0.

 - Drawing inspiration from Swing, SWT, GTK(gtkmm), QT and other
 toolkits, whilst noting what design traps can be avoided due to D's
 language features.
 - The will to Do It Right, no matter how long it takes. We should be in
 this for the long haul.

 
 What are the design traps you think D will allow you to avoid?

Example: over-complicating relatively common tasks, such as hooking up 
signals and slots. Even if the S&S mechanisms that were being discussed 
a while back don't find their way into the language, wouldn't D's 
delegates help to simplify S&S somewhat anyway?

 Does anyone else think it would be worth it, or are most people content
 to try to tap into existing toolkits through D?

 
 I'd like to understand the concrete ideas that justify the wording
 "content".

That comes only from my personal dissatisfaction with a lot of the 
toolkits that are available for which D wrappers could be made (yet 
appreciation of many of their features, and of toolkits for which D 
wrappers could /not/ be made). I was wondering if anyone else felt the same.

Josh Stern <josh_usenet phadd.net> writes:

On Tue, 10 Oct 2006 21:21:43 +1000, Jeff wrote:

 Before I reply, I should probably note that I didn't mean to come across 
 as if I were claiming any authority or expertise on UI toolkits in 
 general, so I'm sorry if I did; my comments were mostly just my personal 
 opinion from my limited experience.

Sure.  And before I read what you write below, let me clarify that
whatever comments I made about writing a new GUI toolkit being a
tremendous amount of work would apply equally even if you were the
greatest GUI toolkit writer on the planet.   Let's assum for argument sake
that you are...


 Josh Stern wrote:
 
 I agree; I can understand that people want GUI libraries for D
 available as soon as possible, and indeed there are people working on
 such projects (i.e. D bindings, ports and/or OO abstractions for
 existing toolkits). However, if we really want some thing /good/ and
 maintainable that can really take advantage of D's features, then
 starting from scratch seems like the best path to me.

 
 After the above, I was expecting to see some description below of what
 it means to "really take advantage of D's features" but I didn't find
 it, so I'm really unsure.   It's clearly important for D that new
 application code written in D should be able to sub-class
 objects/widgets in D and have access to the full programming API, but
 if the bindings are done correctly and the underlying widget set has
 good OO then it isn't necessary for the underlying widget set to be
 written in D.  In particular, PyQt and QtJava provide examples of this
 possibility.  So what is the real idea?

 
 By "really take advantage of D's features", I only meant that a faithful
 translation of an existing OO windowing toolkit wouldn't really have
 much room to play with D's features, since it would be expected to
 behave in an all but identical manner to the original (so why not just
 use the language in which it's already written?).

I'm still not following what limitations you are talking about.   Can you
clarify with an example or two?  

 As far as D wrappers for existing toolkits are concerned, I'd be much
 more enthusiastic about these than attempts to translate (and keep
 up-to-date and clean), say, SWT. "DUI"/"DUIT" started looking like a
 pretty attractive idea once the decision was made to just focus on being
 a GTK wrapper (rather than using native controls on each target
 platform), and I guess I could be happy using a GTK wrapper now that it
 seems to work pretty well on Windows. I'm yet to see a QT application
 that doesn't look horribly ugly to me. I'm sure it's a quite capable
 toolkit, but it's hard to feel good about using it given that. (Once
 again, personal opinion only, there).

Personally I like the look of KDE (all Qt apps) better than Gnome (all
Gtk apps), but I know that lots of other people feel the opposite - it
seems like close to a 50-50 split on this.  Fortunately they are both
moving close to being able to give the same look and feel as the other, so
it probably doesn't make sense to base the choice for a new API on looks.


 Even if progress was to be fairly slow, surely I'm not the



only one
 who
 would be enthused enough by such a project to maintain interest?
 Remember, this wouldn't rule out using other toolkits in the meantime,
 but could also provide us with a /really/ good one in the long run.

 
 What is meant by the long run depends on the target feature set.
 Already something like Tk or WxWindows or Qt has an incredible number
 of man-years invested and new development continues.   That's not to
 say anything negative about the educational and/or fun benefits of
 writing a new widget lib from scratch so long as one is clear that the
 purpose if fun and/or education.   But if the goal is a superior end
 product, especially if achieving that goal is essential to the fun,
 then a lot more needs to be said about how and why that might happen.

 
 I don't have a full answer to that given my total lack of experience
 writing windowing toolkits... but if proven concepts could be taken from
 multiple other toolkits rather than trying to clone one exactly, we
 wouldn't need to be playing catch up to the original, could try to
 simplify some things by making use of D's delegates, templates, S&S
 mechanism (if that goes ahead), etc. 

See my remarks at the top.  I'll elaborate very briefy on two cases:

Case 1 - totally from scratch in all respects - an *incredible* amount of
work that is mostly language neutral.

Case 2 - start from an existing codebase and port/translate as you go -
still a huge amount of work, you may inherit some license restrictions,
and you may inherit a lot of design decisions while introducing new bugs. 
Is it really worth it?

Ideally it would be nice to have
 something usable that was competitive with existing toolkits, but even
 this didn't happen, I wouldn't consider the venture a complete waste.

Right, it would  be fun and educational.   Just be clear in the
beginning if that is okay as a goal.


 For anyone interested, the (utopian? <g>) vision I've had in



my mind
 for some time of a fresh D windowing toolkit would be:

 - Minimal use of native windows/widgets (only for top-level, and other
 cases where really needed?); a Swing-esque approach could be taken to
 native look and feel (making it "somebody else's job"); stops the
 responsibilities getting too tangled, and it seems to have worked
 pretty well for them.

 
 Both Gtk and Qt have converged on methods to allow pluggable look and
 feel.  If some aspect of their current ability in this category is
 lacking, fixing it directly would be the straightest path.  Gnome and
 KDE have parallel and increasingly interoperable methods for telling a
 set of applications to conform to the same updated look and feel at
 runtime.

 
 I don't disagree. I'm just saying what I'd like if the decision were
 already made to write a new toolkit in D; not trying to justify such a
 decision.

Okay.  As an aside on this topic -  there are many people who advocate
the opposite wrt to achieving native OS look and feel.   I believe that
WxWindows is a leading advocate of the opposite approach where one tries
for native look and feel by re-using native widgets wherever possible.



 
 - Drawing inspiration from Swing, SWT, GTK(gtkmm), QT and other
 toolkits, whilst noting what design traps can be avoided due to D's
 language features.
 - The will to Do It Right, no matter how long it takes. We should be
 in this for the long haul.

 
 What are the design traps you think D will allow you to avoid?

 
 Example: over-complicating relatively common tasks, such as hooking up
 signals and slots. Even if the S&S mechanisms that were being discussed
 a while back don't find their way into the language, wouldn't D's
 delegates help to simplify S&S somewhat anyway?

They help mainly in the library code (that app developers normally don't
see).  Java style weak references would help more if they somehow found a
way of sneaking into D :)

 Does anyone else think it would be worth it, or are most people
 content to try to tap into existing toolkits through D?

 
 I'd like to understand the concrete ideas that justify the wording
 "content".

 
 That comes only from my personal dissatisfaction with a lot of the
 toolkits that are available for which D wrappers could be made (yet
 appreciation of many of their features, and of toolkits for which D
 wrappers could /not/ be made). I was wondering if anyone else felt the
 same.

Every lib has some limitations.   But its worthwhile to think carefully
about which limitations that bother you are based on lib decisions you
don't like, which are based on missing features that could be added, and
which are based on the application language (which can  be changed with
bindings).

Don Clugston <dac nospam.com.au> writes:

Josh Stern wrote:
 On Tue, 10 Oct 2006 21:21:43 +1000, Jeff wrote:
 
 Before I reply, I should probably note that I didn't mean to come across 
 as if I were claiming any authority or expertise on UI toolkits in 
 general, so I'm sorry if I did; my comments were mostly just my personal 
 opinion from my limited experience.

 
 Sure.  And before I read what you write below, let me clarify that
 whatever comments I made about writing a new GUI toolkit being a
 tremendous amount of work would apply equally even if you were the
 greatest GUI toolkit writer on the planet.   Let's assum for argument sake
 that you are...
 
 
 Josh Stern wrote:

 I agree; I can understand that people want GUI libraries for D
 available as soon as possible, and indeed there are people working on
 such projects (i.e. D bindings, ports and/or OO abstractions for
 existing toolkits). However, if we really want some thing /good/ and
 maintainable that can really take advantage of D's features, then
 starting from scratch seems like the best path to me.

 After the above, I was expecting to see some description below of what
 it means to "really take advantage of D's features" but I didn't find
 it, so I'm really unsure.   It's clearly important for D that new
 application code written in D should be able to sub-class
 objects/widgets in D and have access to the full programming API, but
 if the bindings are done correctly and the underlying widget set has
 good OO then it isn't necessary for the underlying widget set to be
 written in D.  In particular, PyQt and QtJava provide examples of this
 possibility.  So what is the real idea?

 By "really take advantage of D's features", I only meant that a faithful
 translation of an existing OO windowing toolkit wouldn't really have
 much room to play with D's features, since it would be expected to
 behave in an all but identical manner to the original (so why not just
 use the language in which it's already written?).

 
 I'm still not following what limitations you are talking about.   Can you
 clarify with an example or two?  
 
 As far as D wrappers for existing toolkits are concerned, I'd be much
 more enthusiastic about these than attempts to translate (and keep
 up-to-date and clean), say, SWT. "DUI"/"DUIT" started looking like a
 pretty attractive idea once the decision was made to just focus on being
 a GTK wrapper (rather than using native controls on each target
 platform), and I guess I could be happy using a GTK wrapper now that it
 seems to work pretty well on Windows. I'm yet to see a QT application
 that doesn't look horribly ugly to me. I'm sure it's a quite capable
 toolkit, but it's hard to feel good about using it given that. (Once
 again, personal opinion only, there).

 
 Personally I like the look of KDE (all Qt apps) better than Gnome (all
 Gtk apps), but I know that lots of other people feel the opposite - it
 seems like close to a 50-50 split on this.  Fortunately they are both
 moving close to being able to give the same look and feel as the other, so
 it probably doesn't make sense to base the choice for a new API on looks.
 
 
 Even if progress was to be fairly slow, surely I'm not the



 only one
 who
 would be enthused enough by such a project to maintain interest?
 Remember, this wouldn't rule out using other toolkits in the meantime,
 but could also provide us with a /really/ good one in the long run.

 What is meant by the long run depends on the target feature set.
 Already something like Tk or WxWindows or Qt has an incredible number
 of man-years invested and new development continues.   That's not to
 say anything negative about the educational and/or fun benefits of
 writing a new widget lib from scratch so long as one is clear that the
 purpose if fun and/or education.   But if the goal is a superior end
 product, especially if achieving that goal is essential to the fun,
 then a lot more needs to be said about how and why that might happen.

 I don't have a full answer to that given my total lack of experience
 writing windowing toolkits... but if proven concepts could be taken from
 multiple other toolkits rather than trying to clone one exactly, we
 wouldn't need to be playing catch up to the original, could try to
 simplify some things by making use of D's delegates, templates, S&S
 mechanism (if that goes ahead), etc. 

 
 See my remarks at the top.  I'll elaborate very briefy on two cases:
 
 Case 1 - totally from scratch in all respects - an *incredible* amount of
 work that is mostly language neutral.
 
 Case 2 - start from an existing codebase and port/translate as you go -
 still a huge amount of work, you may inherit some license restrictions,
 and you may inherit a lot of design decisions while introducing new bugs. 
 Is it really worth it?
 
 Ideally it would be nice to have
 something usable that was competitive with existing toolkits, but even
 this didn't happen, I wouldn't consider the venture a complete waste.

 
 Right, it would  be fun and educational.   Just be clear in the
 beginning if that is okay as a goal.
 
 
 For anyone interested, the (utopian? <g>) vision I've had in



 my mind
 for some time of a fresh D windowing toolkit would be:

 - Minimal use of native windows/widgets (only for top-level, and other
 cases where really needed?); a Swing-esque approach could be taken to
 native look and feel (making it "somebody else's job"); stops the
 responsibilities getting too tangled, and it seems to have worked
 pretty well for them.

 Both Gtk and Qt have converged on methods to allow pluggable look and
 feel.  If some aspect of their current ability in this category is
 lacking, fixing it directly would be the straightest path.  Gnome and
 KDE have parallel and increasingly interoperable methods for telling a
 set of applications to conform to the same updated look and feel at
 runtime.

 I don't disagree. I'm just saying what I'd like if the decision were
 already made to write a new toolkit in D; not trying to justify such a
 decision.

 
 Okay.  As an aside on this topic -  there are many people who advocate
 the opposite wrt to achieving native OS look and feel.   I believe that
 WxWindows is a leading advocate of the opposite approach where one tries
 for native look and feel by re-using native widgets wherever possible.
 
 
 
  
 - Drawing inspiration from Swing, SWT, GTK(gtkmm), QT and other
 toolkits, whilst noting what design traps can be avoided due to D's
 language features.
 - The will to Do It Right, no matter how long it takes. We should be
 in this for the long haul.

 What are the design traps you think D will allow you to avoid?

 Example: over-complicating relatively common tasks, such as hooking up
 signals and slots. Even if the S&S mechanisms that were being discussed
 a while back don't find their way into the language, wouldn't D's
 delegates help to simplify S&S somewhat anyway?

 
 They help mainly in the library code (that app developers normally don't
 see).  Java style weak references would help more if they somehow found a
 way of sneaking into D :)
 
 Does anyone else think it would be worth it, or are most people
 content to try to tap into existing toolkits through D?

 I'd like to understand the concrete ideas that justify the wording
 "content".

 That comes only from my personal dissatisfaction with a lot of the
 toolkits that are available for which D wrappers could be made (yet
 appreciation of many of their features, and of toolkits for which D
 wrappers could /not/ be made). I was wondering if anyone else felt the
 same.

 
 Every lib has some limitations.   But its worthwhile to think carefully
 about which limitations that bother you are based on lib decisions you
 don't like, which are based on missing features that could be added, and
 which are based on the application language (which can  be changed with
 bindings).

This is interesting. Personally, I have never seen a GUI library that I 
didn't think was dreadful in some way. And there are so many of them! 
Why? It could be that it's an intrinsically difficult or practically 
unsolvable problem. In which case any D GUI would be bound to the same fate.

However, it's also possible that it is the language -- I'm inclined to 
think that's true for C++ GUIs. For example, the preprocessor in Qt is 
disgusting, but a D binding would avoid that. It could be that my 
revulsion to some of those libraries is just a result of C++ failings. 
However, I do think that the language limitations show through the 
library, and a wrapper doesn't really hide that.

(ie, many lib decisions were made because of the application language).

Which would imply that you get better results wrapping lower level 
libraries than high level ones. (Example: you can easily wrap the 
Windows C API, and make something much better).

Sean Kelly <sean f4.ca> writes:

Don Clugston wrote:
 
 Which would imply that you get better results wrapping lower level 
 libraries than high level ones. (Example: you can easily wrap the 
 Windows C API, and make something much better).

Definately.


Sean

Josh Stern <josh_usenet phadd.net> writes:

On Tue, 10 Oct 2006 18:52:49 +0200, Don Clugston wrote:

 Josh Stern wrote:

 Every lib has some limitations.   But its worthwhile to think carefully
 about which limitations that bother you are based on lib decisions you
 don't like, which are based on missing features that could be added, and
 which are based on the application language (which can  be changed with
 bindings).

 
 This is interesting. Personally, I have never seen a GUI library that I 
 didn't think was dreadful in some way. And there are so many of them! 
 Why? It could be that it's an intrinsically difficult or practically 
 unsolvable problem. In which case any D GUI would be bound to the same fate.

Can't comment on that without knowing which aspects of existing ones you
find the most undesirable.

 However, it's also possible that it is the language -- I'm inclined to
 think that's true for C++ GUIs. For example, the preprocessor in Qt is
 disgusting, but a D binding would avoid that. 

Perhaps.  Let's take this pre-processor issue as one example and see how
far it can be broken down.   First, let's list which aspects of Qt's use
of the moc pre-processor might be considered objectionable:

1) dislike for *any* pre-processor use because they aren't supported well
by one's favorite source code debugger - this could be classified as
either a language issue, a personal philosophy, or a tool limitation.

2) dislike for use of a non-standard pre-processor - classify this as
mainly a language issue because cpp is particularly sucky, but the
pre-processor or the language itself could be better in many ways and
still not support the same level of source code convenience as moc (yes,
there is build inconvenience, but I get to that in another bullet
point).  In D one could replace part of what moc does with mixins, but not
all of it.  To get all of it mixins would have to be extended with the
capability to use alias arguments in more textual ways and also need to
get access to some of their parsing context (e.g. surrounding class name).

3) build inconvenience - extra step in builds and extra object files need
to be dealt with in the build description process and take some small
extra time to run as well - seems like a devel environment/hardware speed
issue.   I believe that there are various setups for automating the build
stuff.

4) unfamiliarity of generated source (e.g. when doing deep debugging) - I
guess this could be the same issue for mixins;   one has to decide if the
convenience achieved justifies this.

5) methodological choice - the question came up a lot about why they
didn't use templates, and the answer was that template support was too
non-portable when Qt was written and also that Qt's slots/signals provide
different dynamic run-time functionality than what one would get with
templates.

All of the above boil down to the question of whether the functionality
gained was worth the inconveniences and whether there was some better way
to get the same functionality.   Answers in C++ are not obvious to me.  If
one has the capability to design a new programming language around the
desired functionality, then the story is different, but that also comes
with its own disadvantags (e.g. inconvenience using existing libraries,
fewer familiar programmers, etc.).


It could be that my
 revulsion to some of those libraries is just a result of C++ failings.
 However, I do think that the language limitations show through the
 library, and a wrapper doesn't really hide that.

How so?
 
 (ie, many lib decisions were made because of the application language).

Which ones negatively impact you in important ways as a user?   Again it
is useful to distinguish between the methods that were used to get to a
particular functionality and interface (which you might do differently if
you were writing it for the first time, but which don't affect you once it
is written), and the choices that make the interface less useful to you.  
It's definitely true that adding a bindings layer gives one the capability
to change some but not all aspects of the interface.


 Which would imply that you get

better results wrapping lower level
 libraries than high level ones. (Example: you can easily wrap the
 Windows C API, and make something much better).

I'm not following you here.  Much better than what?  Did you mean a better
interface than the Win32 API or a better GUI toolkit on top of Win32?

Anyway, I think I disagree with the "imply" part in the sense that
whatever one can do theoretically starting from scratch is a different
question than what one can do starting from reality with some X hours to
spend over some time period Y.

Don Clugston <dac nospam.com.au> writes:

Josh Stern wrote:
 On Tue, 10 Oct 2006 18:52:49 +0200, Don Clugston wrote:
 
 Josh Stern wrote:

 
 Every lib has some limitations.   But its worthwhile to think carefully
 about which limitations that bother you are based on lib decisions you
 don't like, which are based on missing features that could be added, and
 which are based on the application language (which can  be changed with
 bindings).

 This is interesting. Personally, I have never seen a GUI library that I 
 didn't think was dreadful in some way. And there are so many of them! 
 Why? It could be that it's an intrinsically difficult or practically 
 unsolvable problem. In which case any D GUI would be bound to the same fate.

 
 Can't comment on that without knowing which aspects of existing ones you
 find the most undesirable.
 
 However, it's also possible that it is the language -- I'm inclined to
 think that's true for C++ GUIs. For example, the preprocessor in Qt is
 disgusting, but a D binding would avoid that. 

 
 Perhaps.  Let's take this pre-processor issue as one example and see how
 far it can be broken down.   First, let's list which aspects of Qt's use
 of the moc pre-processor might be considered objectionable:
 
 1) dislike for *any* pre-processor use because they aren't supported well
 by one's favorite source code debugger - this could be classified as
 either a language issue, a personal philosophy, or a tool limitation.
 
 2) dislike for use of a non-standard pre-processor - classify this as
 mainly a language issue because cpp is particularly sucky, but the
 pre-processor or the language itself could be better in many ways and
 still not support the same level of source code convenience as moc (yes,
 there is build inconvenience, but I get to that in another bullet
 point).  In D one could replace part of what moc does with mixins, but not
 all of it.  To get all of it mixins would have to be extended with the
 capability to use alias arguments in more textual ways and also need to
 get access to some of their parsing context (e.g. surrounding class name).
 
 3) build inconvenience - extra step in builds and extra object files need
 to be dealt with in the build description process and take some small
 extra time to run as well - seems like a devel environment/hardware speed
 issue.   I believe that there are various setups for automating the build
 stuff.
 
 4) unfamiliarity of generated source (e.g. when doing deep debugging) - I
 guess this could be the same issue for mixins;   one has to decide if the
 convenience achieved justifies this.
 
 5) methodological choice - the question came up a lot about why they
 didn't use templates, and the answer was that template support was too
 non-portable when Qt was written and also that Qt's slots/signals provide
 different dynamic run-time functionality than what one would get with
 templates.


and
6) unnatural - fits poorly with any other library in the language.

 
 All of the above boil down to the question of whether the functionality
 gained was worth the inconveniences and whether there was some better way
 to get the same functionality.   Answers in C++ are not obvious to me.


I don't disagree with that. This is why I said, maybe it's an unsolvable 
problem.

 If
 one has the capability to design a new programming language around the
 desired functionality, then the story is different, but that also comes
 with its own disadvantags (e.g. inconvenience using existing libraries,
 fewer familiar programmers, etc.).
 
 It could be that my
 revulsion to some of those libraries is just a result of C++ failings.
 However, I do think that the language limitations show through the
 library, and a wrapper doesn't really hide that.

 
 How so?
  
 (ie, many lib decisions were made because of the application language).

 
 Which ones negatively impact you in important ways as a user? 

Things like:
* Why do I have to put this in a class? Why can't I just use a free 
function? (typical for GUIs that originated in Java).
* In a C++ GUI, you can usually tell that the original language didn't 
have delegates.

The biggest problem, I think, is that GUI libraries tend to interfere 
too much with app structure.

 Which would imply that you get

 better results wrapping lower level
 libraries than high level ones. (Example: you can easily wrap the
 Windows C API, and make something much better).

 
 I'm not following you here.  Much better than what?  Did you mean a better
 interface than the Win32 API or a better GUI toolkit on top of Win32?

I mean a simpler interface than raw API calls, taking out lots of 
repetitive code. Eg, a simple OO wrapper that puts the HWNDs in a class, 
so you can remove lots of 'hwnd's. The benefit is obvious (the code size 
decreases). But when you wrap a high-level framework, you have a lot 
less freedom.

 Anyway, I think I disagree with the "imply" part in the sense that
 whatever one can do theoretically starting from scratch is a different
 question than what one can do starting from reality with some X hours to
 spend over some time period Y.

That's certainly true. But there's also the problem of getting a 
consensus on those X hours. How can you convince everyone to work on the 
same thing? It just seems to be really difficult. I worked on the 
Windows API headers because I knew that no matter which framework was 
used, it would still be useful.

The thing that really drives me nuts is that there are *so many* GUI 
libraries for Windows and Linux, and they are all ultimately using the 
same hardware! I just think it's so ridiculous. If you look in the 
coding of any of those frameworks, you find that huge chunks of them are 
the same. And so I wonder if there is some intermediate level at which 
you can create widgets (or at least parts of them) that would work 
regardless of what GUI framework was ultimately used.

Bill Baxter <dnewsgroup billbaxter.com> writes:

Don Clugston wrote:
 Josh Stern wrote:
 On Tue, 10 Oct 2006 18:52:49 +0200, Don Clugston wrote:

 The thing that really drives me nuts is that there are *so many* GUI 
 libraries for Windows and Linux, and they are all ultimately using the 
 same hardware! I just think it's so ridiculous. If you look in the 
 coding of any of those frameworks, you find that huge chunks of them are 
 the same. And so I wonder if there is some intermediate level at which 
 you can create widgets (or at least parts of them) that would work 
 regardless of what GUI framework was ultimately used.

I think in some ways, that's the layer that SDL targets.

I think part of the reason there's not more reuse may just be 
aesthetics.  You have to be really picky to decide you'd rather reinvent 
the GUI wheel than use one of the dozen or so existing solutions, many 
of which have tens of thousands of man-hours already invested in them. 
So it's not surprising that the person who wants to write their own GUI 
cares about every little detail right down to the low level.

--bb

Fredrik Olsson <peylow gmail.com> writes:

Don Clugston skrev:
<snip>
 This is interesting. Personally, I have never seen a GUI library that I 
 didn't think was dreadful in some way. And there are so many of them! 
 Why? It could be that it's an intrinsically difficult or practically 
 unsolvable problem. In which case any D GUI would be bound to the same 
 fate.

I have two GUI libraries that I love:

Cocoa and VCL.

Cocoa takes advantage of Obj-C, and VCL takes advantage of Object 
Pascal. What they both have in common is that they work with the 
underlying language, not against it, or using some side-show freaky 
tricks. Both also have the actual layout of the UI separated from the code.

I think a combination of Walter's suggestion for a mixin solution of 
signals and slots, combined with informal interfaces for delegates and 
data providers would be terrific. Sort of a blend of the best parts of 
Cocoa, VCL, and Qt could be made.


// Fredrik Olsson

Georg Wrede <georg.wrede nospam.org> writes:

Jeff wrote:
 Before I reply, I should probably note that I didn't mean to come across 
 as if I were claiming any authority or expertise on UI toolkits in 
 general, so I'm sorry if I did; my comments were mostly just my personal 
 opinion from my limited experience.

Happens to us all, so no problem. :-)

 By "really take advantage of D's features", I only meant that a faithful 
 translation of an existing OO windowing toolkit wouldn't really have 
 much room to play with D's features, since it would be expected to 
 behave in an all but identical manner to the original (so why not just 
 use the language in which it's already written?).

Well, as I see it, a windowing toolkit may eve be written entirely in 
assembler, for example. But the only important things are:

  - it's about time we actually got one
  - leveraging existing work saves us from reinventing it all
  - how smoothly it can be _used_ from D

I don't think it's all that important that the toolkit itself is written 
in D, other than a matter of pride. What we need is a toolkit that could 
be used "right now", and that practically excludes doing it from 
scratch. (Heck, by D 2.0 we might have one, but now's not the time.)

The most important thing now is to get something that has an easy to use 
Programmer Interface. Only this would cause a lot of GUI programs in D 
to be written, and thus lots more visibility for D in areas and with 
people we're not reaching right now.

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:

Georg Wrede wrote:

 I don't think it's all that important that the toolkit itself is written 
 in D, other than a matter of pride. What we need is a toolkit that could 
 be used "right now", and that practically excludes doing it from 
 scratch. (Heck, by D 2.0 we might have one, but now's not the time.)
 
 The most important thing now is to get something that has an easy to use 
 Programmer Interface. Only this would cause a lot of GUI programs in D 
 to be written, and thus lots more visibility for D in areas and with 
 people we're not reaching right now.

Were there any takers on objectifying and templatizing a "D/Tk" ?

We have "C/Tk" now, and would like to have "C++/Tk" ported over...

http://www.algonet.se/~afb/d/tkhelloworld.d ("C/Tk")
vs.
http://cpptk.sourceforge.net/examples/ex1.html ("C++/Tk")

I ported the C headers over, but I'm not very good with C++/Boost.

Tcl/Tk:
http://www.tcl.tk/man/tcl8.4/TclLib/contents.htm
http://www.tcl.tk/man/tcl8.4/TkLib/contents.htm

C++/Tk:
http://cpptk.sourceforge.net/doc.html
http://cpptk.cvs.sourceforge.net/cpptk/

This would be a good test: http://cpptk.sf.net/examples/ex6.html

--anders

PS. I think the wxWidgets toolkit has a simple API too.
     (At least it's ready to use, and has documentation)

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:

Mars wrote:

 It seems many people is trying to give D a decent widget set without
 much success. However I'm wondering why nobody has tried with Tk.

It used to be that much of the actual GUI still ran in Tcl, inside it...
Normally when I think of Tcl/Tk, I think of those horrible gray boxes.

I think it is more stand-alone these days, and it also seems prettier ?
Didn't see any high-level widgets like HTML or OpenGL containers, but.

 So... could Tk become D's GUI library of choice too? Or am I missing 
 something?

An initial implementation, perhaps ?

Porting tcl.h/tk.h and a "Hello World" over to D, would be nice start.
(I think using embedded Tcl would be the simplest way to get started...)

http://www.algonet.se/~afb/d/tkhelloworld.c

This is what it looks like on Mac OS X, linking to Tcl/Tk frameworks:
(I used the "Wishkit" binary distribution, using libs would work too)

http://www.algonet.se/~afb/d/tkhelloworld.png


You could of course internalize the Tcl code into D (or Python or Perl),
but it would still look pretty similar from a high-level usage aspect...

http://www.algonet.se/~afb/d/tkhelloworld.py
http://www.algonet.se/~afb/d/tkhelloworld.pl


I prefer wx over tk myself, but having a little choice never hurts* ?
And as for the offical DMD library, that is already chosen to be DWT.

--anders

* Python also does both of tkInter and wxPython, for example.

Mars <nospam null.void> writes:

 It used to be that much of the actual GUI still ran in Tcl, inside it...

Tk can be accessed both from Tcl (which is the usual thing to do) and 
from C, the canonical example of the latter being Perl/Tk. Embedding Tcl 
in another language is no big issue, Tcl is no more and no less than an 
ordinary C library. Embedding Tcl is not different than, for example, 
embedding SQL in a program written in D (or C++ or Java or whatever.)

The developers of Python, Ruby and Scheme have chosen the "let's link 
against the tcl library" route, but, as already noticed, it is also 
possible to call the C routines directly.


 I think it is more stand-alone these days, and it also seems prettier ?

Yes both seem true, and the upcoming v8.5 is focused on making it look 
even better. See the roadmap at http://wiki.tcl.tk/12753

Tk + The Tile rendering engine uses native widgets in Windows (including 
support for XP themes) and Mac OS X, the X11 version draws its own 
widgets in raw xlib following the Motif style, or a new, somewhat 
improved, look. There is also a project called TileQt that uses Qt as a 
backend, see 
http://www.ellogon.org/petasis/index.php?option=com_content&task=view&id=24&Itemid=40

 Didn't see any high-level widgets like HTML or OpenGL containers, but.

tkhtml: http://tkhtml.tcl.tk/
tcl3d: http://www.tcl3d.org/

I think the only reason these are not included as part of Tk itself is 
to keep the library lean and mean. There are several libraries of 
third-party widgets available for Tk, see http://wiki.tcl.tk/2352

 An initial implementation, perhaps ?

I'm just getting started with D and Tcl, this is a tad ambitious for me 
right now.

 And as for the offical DMD library, that is already chosen to be DWT. 

 From what I've been reading its development has halted... Java/D 
developers seem to be scarcer than C/D ones.

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:

Mars wrote:

 Didn't see any high-level widgets like HTML or OpenGL containers, but.

 
 tkhtml: http://tkhtml.tcl.tk/
 tcl3d: http://www.tcl3d.org/
 
 I think the only reason these are not included as part of Tk itself is 
 to keep the library lean and mean. There are several libraries of 
 third-party widgets available for Tk, see http://wiki.tcl.tk/2352

Ah, must confess I didn't look too hard either - thanks for the links!

This doesn't look very much like the Tcl/Tk that grandfather used to do.
And 8.4 (Tcl/Tk) even comes pre-installed on Mac OS X 10.4 these days...

http://tcltkaqua.sourceforge.net/tiger

 An initial implementation, perhaps ?

 
 I'm just getting started with D and Tcl, this is a tad ambitious for me 
 right now.

What I meant was that you probably need a proof-of-concept for D/Tk ?

I'll run the Tcl and Tk through my gc2d script, see how that works...
But all those custom macros (_ANSI_ARGS_, etc) might need some lovin'.

--anders

Mars <nospam null.void> writes:

 What I meant was that you probably need a proof-of-concept for D/Tk ? 
 I'll run the Tcl and Tk through my gc2d script, see how that works...
 But all those custom macros (_ANSI_ARGS_, etc) might need some lovin'. 

Someone did a proof-of-concept implementation for C++/Tk, maybe you'll 
find it useful: http://cpptk.sourceforge.net/

Mars <nospam null.void> writes:

I think this one is not a proof-of-concept implementation but the real deal.

"As its core, KWWidgets is an object-oriented C++ layer on top of the 
Tcl/Tk UI toolkit. It uses the same coding framework and guidelines as 
VTK. It can interact and co-exist with Tcl/Tk directly from C++, 
allowing you to load or execute Tcl modules directly from a C++ 
application."

http://www.kwwidgets.org/Wiki/KWWidgets

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:

Mars wrote:

 What I meant was that you probably need a proof-of-concept for D/Tk ? 
 I'll run the Tcl and Tk through my gc2d script, see how that works...
 But all those custom macros (_ANSI_ARGS_, etc) might need some lovin'. 

 
 Someone did a proof-of-concept implementation for C++/Tk, maybe you'll 
 find it useful: http://cpptk.sourceforge.net/

That looks more like some C++ hacks, to make it think that it is Tcl ?

I was just doing a quick-and-dirty translation of the Tcl and Tk libs,
somewhat surprised that Tk needed X11 headers but otherwise not too bad.

See http://www.algonet.se/~afb/d/tkhelloworld.d

tcl/tcl.d
tcl/tclDecls.d
tcl/tclPlatDecls.d

tk/tk.d
tk/tkDecls.d
tk/tkPlatDecls.d
tk/tkIntXlibDecls.d
tk/X11/X.d
tk/X11/Xlib.d
tk/X11/Xutil.d

Will post to my D bindings page, when cleaned up...
(I used Apple's bundled Tcl.framework/Tk.framework)

But I don't think I will play with tk more than that.

--anders

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:

 That looks more like some C++ hacks, to make it think that it is Tcl ?
 
 I was just doing a quick-and-dirty translation of the Tcl and Tk libs,
 somewhat surprised that Tk needed X11 headers but otherwise not too bad.

Actually those callback things were kinda neat, with the parameters etc.
(some tech details at http://cpptk.sourceforge.net/doc.html#looseends)

If anyone wants to continue with those or other "D/Tk" object wrappers,
I put the D tcl/tk lib code up at: http://www.algonet.se/~afb/d/TK.zip

You will need Tcl/Tk 8.4, get it from http://www.tcl.tk/software/tcltk/
(on Mac OS X 10.4, you can just link with: -framework Tcl -framework Tk)

Now back to the regularly scheduled programming. (that would be wxD :-))
The D wrappers are under the same licensing terms as Tcl/Tk itself, BTW.
--anders

Hasan Aljudy <hasan.aljudy gmail.com> writes:

Anders F Björklund wrote:
 And as for the offical DMD library, that is already chosen to be DWT.

Really? Last time I checked, DWT was a /candidate/ for an official GUI; 
if that has changed, can you point me to the post that announced DWT as 
/the/ official GUI library?

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:

Hasan Aljudy wrote:

 And as for the offical DMD library, that is already chosen to be DWT.

 
 Really? Last time I checked, DWT was a /candidate/ for an official GUI; 
 if that has changed, can you point me to the post that announced DWT as 
 /the/ official GUI library?

Well, about the time that "digitalmars.D.dwt" newsgroup was founded ?
Something about DM putting all the wood behind one arrow, or something.

But neither tk nor wx are really candidates for a GUI written *in* D,
they are more about libraries that are usable *from* D. A difference.

Both DWT and FLTK were actual ports, rather than just simple wrappers.
And I think both of them ran into the "missing system headers" issue ?

i.e. in order to use the system headers, you need to convert these over
to D first (as D import modules), before you can actually use them...

--anders

Josh Stern <josh_usenet phadd.net> writes:

Porting either PyQt (including its semi-automatic generation from
Qt headers using he using gcc-xml) or QtJava (including its semi-automatic
generation using a Perl hack called Kalyptus) from either Python or Java
to D seems like a particularly sensible approach to me.   Object
orientation is definitely a good idea for widget sets and Qt itself is
object-oriented, full featured, cross platform, and well documented.

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:

Josh Stern wrote:

 Porting either PyQt (including its semi-automatic generation from
 Qt headers using he using gcc-xml) or QtJava (including its semi-automatic
 generation using a Perl hack called Kalyptus) from either Python or Java
 to D seems like a particularly sensible approach to me.   Object
 orientation is definitely a good idea for widget sets and Qt itself is
 object-oriented, full featured, cross platform, and well documented.

Besides being a somewhat hefty target to port (due to the sheer size),
I think the biggest objection to the Qt libraries was the GPL license.
(I know that it is dual-licensed, and that there is a Commercial Ed. -
but the licensing fees for that is quite huge for any hobby developer)

But if you want to port Qt over to D, then by all means go for it! :-)

--anders

Josh Stern <josh_usenet phadd.net> writes:

On Mon, 09 Oct 2006 23:32:01 +0200, Anders F Björklund wrote:

 Josh Stern wrote:
 
 Porting either PyQt (including its semi-automatic generation from
 Qt headers using he using gcc-xml) or QtJava (including its semi-automatic
 generation using a Perl hack called Kalyptus) from either Python or Java
 to D seems like a particularly sensible approach to me.   Object
 orientation is definitely a good idea for widget sets and Qt itself is
 object-oriented, full featured, cross platform, and well documented.

 
 Besides being a somewhat hefty target to port (due to the sheer size),
 I think the biggest objection to the Qt libraries was the GPL license.
 (I know that it is dual-licensed, and that there is a Commercial Ed. -
 but the licensing fees for that is quite huge for any hobby developer)
 
 But if you want to port Qt over to D, then by all means go for it! :-)

Porting Qt itself is both too much work and undesirable (because it would
be a fork).  What I discussed a few posts back was porting the PyQt or
QtJava bindings for Qt (which link with the regular Qt libraries).   These
are both a) much, much smaller, and b) 90-95% auto-generated from Qt
headers, so a lot of the work would be just modifying the generator
programs and then adding support code - they are both designed to be
readily updated to future Qt release.  The biggest hurdle
I can see would be figuring out the best naming and documentation
convention for dealing with the situations where Qt makes use of more
member function overloading than what D allows.  

The Qt commercial licensing fee is only relevant if one needs to
distribute a closed source app outside of your organization.  Offhand I
can't think who it is really a problem for other than impoverished
shareware writers.  At the point at which most proprietary applications
are reading to be distributed, the tradeoff of a developer license fee for
professional support is a good one.

Josh Stern <josh_usenet phadd.net> writes:

On Mon, 09 Oct 2006 17:01:44 -0500, Josh Stern wrote:


 
 The Qt commercial licensing fee is only relevant if one needs to
 distribute a closed source app outside of your organization.  Offhand I
 can't think who it is really a problem for other than impoverished
 shareware writers.  At the point at which most proprietary applications
 are reading to be distributed, the tradeoff of a developer license fee for
 professional support is a good one.

I was wrong about part of the above.   The TrollTech commercial license
incluedes, the following text, which basically means you have to decide
up front whether to use commercial or GPL licensing.

***********************************************************************
You must purchase a Qt Commercial License from Trolltech or from any of 
its authorized resellers before you start developing proprietary software.
The Commercial license does not allow the incorporation of code developed
with the Open Source Edition of Qt into a proprietary product.

For desktop applications, there are no royalties, runtime licenses, or 
other additional costs.

The license is sold on a per-developer basis and assigned to an
individual. It may be transferred, but only every six months and within
the same organization. 

***************************************************************

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:

Josh Stern wrote:

But if you want to port Qt over to D, then by all means go for it! :-)

 
 Porting Qt itself is both too much work and undesirable (because it would
 be a fork).  What I discussed a few posts back was porting the PyQt or
 QtJava bindings for Qt (which link with the regular Qt libraries).

Actually this was what I meant, "make it accessible from D", not port.

I mean, having a library written in D is still a nice future goal and I 
think the current DWT is not a bad choice for such a big porting effort. 


But in the meantime, being able to use the standard GUI libraries from D 
would be nice as it is currently an advantage that C++ or even Java has. 
And D wrappers for Qt are missing AFAIK, we "only" have them for GTK+...

A *big* advantage of using the C++ Qt is that it can use system headers.

 These
 are both a) much, much smaller, and b) 90-95% auto-generated from Qt
 headers, so a lot of the work would be just modifying the generator
 programs and then adding support code - they are both designed to be
 readily updated to future Qt release.  The biggest hurdle
 I can see would be figuring out the best naming and documentation
 convention for dealing with the situations where Qt makes use of more
 member function overloading than what D allows.  

The QtJava files look similar to how the current wxD bindings work, 
while PyQt seems to use a more SWIG-like (.sip) automated approach...

I'm not sure which approach would work best for QtD/QDt, but we're 
moving towards the second method in wxD as it is more maintainable.




Doing a proof-of-concept spike would probably show which approach would 
work better for the D bindings/wrappers, maybe even try both of them ?

 The Qt commercial licensing fee is only relevant if one needs to
 distribute a closed source app outside of your organization. 

Or use any "open source" license other than the GPL, for instance.
I don't have a problem with GPL at all, but LGPL is easier to use.

But I do think that the Community Ed. and Commercial Ed. are two 
separate Qt products, so they would be more like forks in practice.

--anders

Josh Stern <josh_usenet phadd.net> writes:

On Tue, 10 Oct 2006 09:17:33 +0200, Anders F Björklund wrote:

 Josh Stern wrote:
 
But if you want to port Qt over to D, then by all means go for it! :-)

 
 Porting Qt itself is both too much work and undesirable (because it would
 be a fork).  What I discussed a few posts back was porting the PyQt or
 QtJava bindings for Qt (which link with the regular Qt libraries).

 
 Actually this was what I meant, "make it accessible from D", not port.
 
 I mean, having a library written in D is still a nice future goal and I 
 think the current DWT is not a bad choice for such a big porting effort. 


"Nice" is hard to argue with.  I mean, running on an OS that had a native
D API might also be "nice" (in the way LISP machines were nice for LISP). 
But saying that therefore trying to write a new OS, or at least a new
libc, in D is the right way to go is whole different kettle of fish.
Clearly writing a state of the art GUI lib from scratch is not nearly as
hard as writing a state of the art OS and drivers from scratch and the
issue of incompatibility with existing GUI libs is not nearly as important
(though not totally irrelevant), but its still an incredible amount of
work.  One really needs to think hard about whether the manpower resources
are available to do that and whether the ultimate payoff justifies it.

 But in the meantime, being able to use the standard GUI libraries from D 
 would be nice as it is currently an advantage that C++ or even Java has. 
 And D wrappers for Qt are missing AFAIK, we "only" have them for GTK+...
 
 A *big* advantage of using the C++ Qt is that it can use system headers.

I missed your last point above...compared to what?  

 These
 are both a) much, much smaller, and b) 90-95% auto-generated from Qt
 headers, so a lot of the work would be just modifying the generator
 programs and then adding support code - they are both designed to be
 readily updated to future Qt release.  The biggest hurdle
 I can see would be figuring out the best naming and documentation
 convention for dealing with the situations where Qt makes use of more
 member function overloading than what D allows.  

 
 The QtJava files look similar to how the current wxD bindings work, 
 while PyQt seems to use a more SWIG-like (.sip) automated approach...
 
 I'm not sure which approach would work best for QtD/QDt, but we're 
 moving towards the second method in wxD as it is more maintainable.

QtJava looks more elegant to me personally (and Trolltech seems to like
it too as they have now turned it into an actual product of theirs called
QtJambi).   But I hesitated to state a preference because I believe QtPy
has been more widely used and because the issue of Java's closer C++
compatibility wrt function overloading will be one extra issue to overcome
(whereas QtPy takes the approach of more often using strings explicitly 
(e.g. for signals) to name the C++ binding target.

Most of the people working in this area seem to say that they started out
with the idea that using Swig would be the way to go and then discovered
that it was hard to maintain.   I'm not sure how much of that is still
true now that Swig is a lot more mature.   But talking about Swig gets us
to three different header parsers as a starting point:  gcc-xml (PyQt),
Swig, and Kalyptus (QtJava).   QtJambi probably has its own
specialized parser that would be updated by TrollTech, but I haven't had a
chance to look at that.




(GPL)


Yes, the Kalyptus tool that generates QtJava also generates Objective-C
and there are QtRuby bindings that take a slightly different approach as
well.   At one time there was a hand-generated QtPerl, but that
was obviously something that ran into difficulties being updated to each
new Qt release so I'm not sure about its current status.


 Doing a proof-of-concept spike would probably show which approach

would
 work better for the D bindings/wrappers, maybe even try both of them ?

Yes, or at least look carefully at all the existing methods.

 The Qt commercial licensing fee is only relevant if one needs to
 distribute a closed source app outside of your organization.

 
 Or use any "open source" license other than the GPL, for instance. I
 don't have a problem with GPL at all, but LGPL is easier to use.

Agreed.  It' worth pointing out that the restrictive parts of GPL apply
only to the act of program distribution and there is an exception for
linkage against system components - that is components that are
distributed with the OS platform.   So GPL doesn't affect internal
projects that stay internal to an organization and Qt is moving close to
being a system component on on Linux, at least.

 But I do think that the Community Ed. and

Commercial Ed. are two
 separate Qt products, so they would be more like forks in practice.

I guess you mean the code that one develops using each. Right?  That seems
to be TrollTech's idea.   I wonder whether people have ever tried to
negotiate back payments to grandfather code that started developing with
the open source product and what TrollTech's response was.

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:

Josh Stern wrote:

I mean, having a library written in D is still a nice future goal and I 
think the current DWT is not a bad choice for such a big porting effort. 


 
 "Nice" is hard to argue with.  I mean, running on an OS that had a native
 D API might also be "nice" (in the way LISP machines were nice for LISP). 
 But saying that therefore trying to write a new OS, or at least a new
 libc, in D is the right way to go is whole different kettle of fish.

I was naively assuming that the library would eventually end up linking 
to system libraries, and that those were the main ones involved here...
But maybe Qt and GTK+ are more like actual system libraries (at least on 
Linux) than graphical toolkits, though ? (i.e. comparable to Win32 etc.)

But if the "other library" (wx or tk or similar) only wraps the system 
libraries, then it feels like losing one wrapper layer could be a goal ?

 Clearly writing a state of the art GUI lib from scratch is not nearly as
 hard as writing a state of the art OS and drivers from scratch and the
 issue of incompatibility with existing GUI libs is not nearly as important
 (though not totally irrelevant), but its still an incredible amount of
 work.  One really needs to think hard about whether the manpower resources
 are available to do that and whether the ultimate payoff justifies it.

I don't think so myself. I guess the people that are behind DWT did.
(then again I wasn't ever aiming for the state-of-the-art, either...)

I still think something smaller in ambition, like MinWin or FLTK 1.x, 
would be nice to have around as an example of "all-D" GUI libraries ?

But porting all of the bigger libraries ? Does sound a bit expensive.
And as an old Mac user, I don't like the dual platform solutions much.

A *big* advantage of using the C++ Qt is that it can use system headers.

 
 I missed your last point above...compared to what?  

Sorry, compared to a native port to D - which can't read C/C++ headers.
(without first converting said headers to "D import modules" that is,
something that is proving to be a lot of work for say Win32 or Carbon)

In wxD, all those pesky system libraries are only accessed by C/C++.
The D library code only needs to talk to the exported "C" functions,
so there is no need for access to all the system headers by D code.

 Most of the people working in this area seem to say that they started out
 with the idea that using Swig would be the way to go and then discovered
 that it was hard to maintain.   I'm not sure how much of that is still
 true now that Swig is a lot more mature.   But talking about Swig gets us
 to three different header parsers as a starting point:  gcc-xml (PyQt),
 Swig, and Kalyptus (QtJava).   QtJambi probably has its own
 specialized parser that would be updated by TrollTech, but I haven't had a
 chance to look at that.

A slight problem for D bindings is that SWIG support for D isn't 
finished either, but there are others - like the bcd.gen project ?

We're holding SWIG as a "future goal" for wxD (and also for wx.NET),
and continue to work on the Perl/hand-generated classes meanwhile...

 Yes, the Kalyptus tool that generates QtJava also generates Objective-C
 and there are QtRuby bindings that take a slightly different approach as
 well.   At one time there was a hand-generated QtPerl, but that
 was obviously something that ran into difficulties being updated to each
 new Qt release so I'm not sure about its current status.

Cool, I wasn't really aware of all the details - thanks for the info.
(I've only played with the Trolltech Qt examples, not used it anything)

 I guess you mean the code that one develops using each. Right?  That seems
 to be TrollTech's idea.   I wonder whether people have ever tried to
 negotiate back payments to grandfather code that started developing with
 the open source product and what TrollTech's response was.

As far as licensing goes, the two Qt editions are not interchangeable.
So even if they do share a common "code base" (I'm assuming here that
they are more or less identical), they're more like forks of that base ?
But I don't really know (nor care to) what the code differences are...

--anders

Josh Stern <josh_usenet phadd.net> writes:

On Tue, 10 Oct 2006 16:22:41 +0200, Anders F Björklund wrote:

 Josh Stern wrote:
 
I mean, having a library written in D is still a nice future goal and I 
think the current DWT is not a bad choice for such a big porting effort. 


 
 "Nice" is hard to argue with.  I mean, running on an OS that had a native
 D API might also be "nice" (in the way LISP machines were nice for LISP). 
 But saying that therefore trying to write a new OS, or at least a new
 libc, in D is the right way to go is whole different kettle of fish.

 
 I was naively assuming that the library would eventually end up linking 
 to system libraries, and that those were the main ones involved here...
 But maybe Qt and GTK+ are more like actual system libraries (at least on 
 Linux) than graphical toolkits, though ? (i.e. comparable to Win32 etc.)

It depends what one means by system library:

1) Lowest stable API  - No, there are other layers below Qt and GTK+
that are API stable (libc/POSIX, X11, etc.), even across other Unix
flavors.

2) Lowest level technically or legally possible - No.

3) Provide basic GUI - Yes.  X11 and related libs don't provide standard
widgets that anybody uses today and only provide drawing primitives (like
lines and boxes), and don't determine look and feel policy.   On Linux,
look and feel policy is set by KDE and Gnome at an even higher layer.

4) Distributed with the OS and/or installed by Default - Depends, on the
specific Linux distro, but this is increasingly true for both.

5) Part of a Linux Desktop standard - Yes, getting there.  See
http://refspecs.freestandards.org/lsb.shtml




 I still think something smaller in ambition, like MinWin or FLTK 1.x, 
 would be nice to have around as an example of "all-D" GUI libraries ?

More examples of complex D libs of every type would be valuable.

A *big* advantage of using the C++ Qt is that it can use system headers.

 
 I missed your last point above...compared to what?  

 
 Sorry, compared to a native port to D - which can't read C/C++ headers.
 (without first converting said headers to "D import modules" that is,
 something that is proving to be a lot of work for say Win32 or Carbon)

Okay, but making decent D bindings for the system headers on
platforms X,Y,Z is an order of magnitude easier than making a good GUI lib
from scratch for all those platforms, so I don't think *that* is a big
consideration (contrast that with the idea Walter put somewhere on his
site that ideally GC should  be  part of the OS).

 Most of the people working in this area seem to say that they started out
 with the idea that using Swig would be the way to go and then discovered
 that it was hard to maintain.   I'm not sure how much of that is still
 true now that Swig is a lot more mature.   But talking about Swig gets us
 to three different header parsers as a starting point:  gcc-xml (PyQt),
 Swig, and Kalyptus (QtJava).   QtJambi probably has its own
 specialized parser that would be updated by TrollTech, but I haven't had a
 chance to look at that.

 
 A slight problem for D bindings is that SWIG support for D isn't 
 finished either, but there are others - like the bcd.gen project ?

Again.  Beefing up D in Swig is a much smaller project than a new GUI. 
But the issue remains for the Swig approach that the Swig interface files
need to be individually updated to track API changes in the underlying lib.


 As far as licensing goes, the two Qt editions are not interchangeable.
 So even if they do share a common "code base" (I'm assuming here that
 they are more or less identical),

Yes, they are explicitly the same code base.  In fact PyQt has a
commercial distribution and they tell people on their web site that end
users can use either the free or commercial Qt to dynamically link against
at runtime.

 they're more like forks of that base ?
 But I don't really know (nor care to) what the code differences are...

The "fork" idea is only about the restrictions TrollTech puts on the
commercial license "version" to help them have a viable business model. 
The commercial version is explicitly the same code but using a different
license.

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:

Josh Stern wrote:

But maybe Qt and GTK+ are more like actual system libraries (at least on 
Linux) than graphical toolkits, though ? (i.e. comparable to Win32 etc.)

 
 It depends what one means by system library:
 
 1) Lowest stable API  - No, there are other layers below Qt and GTK+
 that are API stable (libc/POSIX, X11, etc.), even across other Unix
 flavors.
 
 2) Lowest level technically or legally possible - No.

What I was trying to say was that the toolkits I have been looking at
are targetting GTK+ as a "platform" in the same way as Win32 or MacOS.
So it's been more about GTK+ as the system library, than about porting
or using GTK+ on another platform - even if that would have worked too.
So even if GTK+ is cross-platform, it is treated as just another OS lib.
(I think that this goes for Qt as well, but I don't know all about it...
Not sure if there is a wxQt port, but otherwise that could be similar ?)

This has worked well for me, the Linux version uses the "native" widgets
in the same theme as the rest of the desktop - and so does Win and Mac.

 3) Provide basic GUI - Yes.  X11 and related libs don't provide standard
 widgets that anybody uses today and only provide drawing primitives (like
 lines and boxes), and don't determine look and feel policy.   On Linux,
 look and feel policy is set by KDE and Gnome at an even higher layer.

For wx we have "wxX11" which uses the "Universal" (lightweight) widgets 
that provides a (limited) highlevel interface for such platforms. Maybe 
not so interesting for "raw" X11, but it also works for embedded so...

But for the full featured version, then having GTK2 is my requirement.

 4) Distributed with the OS and/or installed by Default - Depends, on the
 specific Linux distro, but this is increasingly true for both.
 
 5) Part of a Linux Desktop standard - Yes, getting there.  See
 http://refspecs.freestandards.org/lsb.shtml

The two distributions I have in mind, Fedora Core 5 and Ubuntu Dapper,
both use GNOME as their default desktop - so GTK2 is my target there.

Both offer KDE and Qt as well, and integrated both in the distribution 
and as per standards and projects you are referring to - a good thing.
So requiring either GTK+ (2+) or Qt (4+) is not a problem, I think...

For now I've chosen GTK+, maybe Qt would have been closer if I used KDE.
I understand that just like Swing it doesn't really use native widgets,
but that they have hidden that fact well by providing a look-and-feel ?

I still think something smaller in ambition, like MinWin or FLTK 1.x, 
would be nice to have around as an example of "all-D" GUI libraries ?

 
 More examples of complex D libs of every type would be valuable.

Sure, I wouldn't mind at all seeing for instance DWT finished either...
Just that those two were the ones in D that I looked more at (for GUI).

 Okay, but making decent D bindings for the system headers on
 platforms X,Y,Z is an order of magnitude easier than making a good GUI lib
 from scratch for all those platforms, so I don't think *that* is a big
 consideration (contrast that with the idea Walter put somewhere on his
 site that ideally GC should  be  part of the OS).

Yeah, until we can have it fully automated (maybe with a patch or two)
it's mostly a question of plain old boredom and restrictive licensing.
At least for the Win32 and MacOS headers, it's tedious to translate for
potential troubles with legal issues with any redistribution thereof.
(but "WindowsAPI" and "CarbonHeaders" projects are doing those two OS)

For things like GUI libraries, it's usually enough to "port as needed".
(i.e. just adding extern(C) statements for all system functions needed)

 Again.  Beefing up D in Swig is a much smaller project than a new GUI. 
 But the issue remains for the Swig approach that the Swig interface files
 need to be individually updated to track API changes in the underlying lib.

Yeah, it's no more of an obstacle than what the missing OS headers are.
It's just that these little things tends to add up, as they take time ?

But the SWIG approach is probably better in the long run anyway, since
it's at least easier to adapt to API changes than having to edit code ?

 The "fork" idea is only about the restrictions TrollTech puts on the
 commercial license "version" to help them have a viable business model. 
 The commercial version is explicitly the same code but using a different
 license.

Okay, but from their info it looks like you must decide before using it.
The dual licensing model is not uncommon, and much better than closed...

And licensing is just one of the reasons I am sticking with wxWidgets.
 From what I saw of Qt4 when I tested it briefly, it looked great to use.

--anders

Josh Stern <josh_usenet phadd.net> writes:

On Tue, 10 Oct 2006 21:08:12 +0200, Anders F Björklund wrote:

 Josh Stern wrote:
 
But maybe Qt and GTK+ are more like actual system libraries (at least on 
Linux) than graphical toolkits, though ? (i.e. comparable to Win32 etc.)

 
 It depends what one means by system library:
 
 1) Lowest stable API  - No, there are other layers below Qt and GTK+
 that are API stable (libc/POSIX, X11, etc.), even across other Unix
 flavors.
 
 2) Lowest level technically or legally possible - No.

 
 What I was trying to say was that the toolkits I have been looking at
 are targetting GTK+ as a "platform" in the same way as Win32 or MacOS.
 So it's been more about GTK+ as the system library, than about porting
 or using GTK+ on another platform - even if that would have worked too.
 So even if GTK+ is cross-platform, it is treated as just another OS lib.
 (I think that this goes for Qt as well, but I don't know all about it...
 Not sure if there is a wxQt port, but otherwise that could be similar ?)

Yes, because it is C based, using Gtk as an alternative to Win32 is a
little more similar in the code than using Qt as an alternative to Win32
would be.  Also, I believe that historically the first Unix version of
WxWindows used Motif, and that was OO C as well, so Gtk was already
conceptually close to their previous versions.

 This has worked well for me, the Linux version uses the

"native" widgets
 in the same theme as the rest of the desktop - and so does Win and Mac.
 
 3) Provide basic GUI - Yes.  X11 and related libs don't provide
 standard widgets that anybody uses today and only provide drawing
 primitives (like lines and boxes), and don't determine look and feel
 policy.   On Linux, look and feel policy is set by KDE and Gnome at an
 even higher layer.

 
 For wx we have "wxX11" which uses the "Universal" (lightweight) widgets
 that provides a (limited) highlevel interface for such platforms. Maybe
 not so interesting for "raw" X11, but it also works for embedded so...

I don't think that raw X11 is that good for embedded since there are few
embedded X servers.  There is actually an embedded version of Qt that is
based on a frame buffer rather than an X11 model - it was used by Sharp
for instance in some of their products.   I'm not competent to discuss
the market share merits of different current approaches to embedded
semi-portability (including Micro-Java), but I would guess that PalmOS and
WinCE are important targets if that is the goal, and I'm not aware of
anything GUI toolkits that do a good job with both of these and the
regular desktop.


 either GTK+ (2+) or Qt (4+) is not a problem, I think...
 
 For now I've chosen GTK+, maybe Qt would have been closer if I used KDE.
 I understand that just like Swing it doesn't really use native widgets,
 but that they have hidden that fact well by providing a look-and-feel ?

Because Linux GUI apps can come from so many sources, it's very debatable
to say what if anything the "native look and feel" means on Linux at the
present time (at one stage it meant the Motif look on most Unix, but that
was never standard on Linux and definitely uncommon today).  Both KDE and
Gnome offer systems for run-time configuration of fonts, colors, rendering
plugins, etc. in all currently running Gnome or KDE apps.   They have also
talked to each other about standard to let non-toolkit apps participate in
this process and to shared DND for things other than text.  The place to
look at the current theoretical status of those standards is here:
http://freedesktop.org/wiki/
http://portland.freedesktop.org/wiki/

On X11, the window manager that is running decorates the outside of
windows.   So, say, if I am running KDE as my desktop environment (with
the Kwin window manager) and a version of Firefox that is built against
Gtk, then when I update my desktop window manager decorates, it affects
the colors of the borders of the Firefox window but not inside the app.
Similarly I can change the default text font for all running KDE
applications but I can only change the header font from KDE for the text
above the border of Firefox and need to go into Firefox itself to
configure the fonts it uses for web pages. The stuff above would like to
make all of that happen together even for apps built on different
toolkits.   I'm not one the people who thinks this is a very important
issue.   


 Again.  Beefing up D in Swig is a much smaller project than a new GUI.
 But the issue remains for the Swig approach that the Swig interface
 files need to be individually updated to track API changes in the
 underlying lib.

 
 Yeah, it's no more of an obstacle than what the missing OS headers are.
 It's just that these little things tends to add up, as they take time ?

It's only more of an obstacle if you expect the GUI toolkit headers to
change more often (or if they are much larger) and you want to track those
changes - i.e. easily update to Qt5 if and when it comes out.

 But the SWIG approach is probably better in the long run anyway,

since
 it's at least easier to adapt to API changes than having to edit code ?

Editing interface files is editing code.   But if you have parsing code
and auto-generation from the rep of just what is parsed, then that is more
automated.


 The "fork" idea is only about the restrictions TrollTech puts on the
 commercial license "version" to help them have a viable business model.
 The commercial version is explicitly the same code but using a
 different license.

 
 Okay, but from their info it looks like you must decide before using it.
 The dual licensing model is not uncommon, and much better than closed...
 
 And licensing is just one of the reasons I am sticking with wxWidgets.
  From what I saw of Qt4 when I tested it briefly, it looked great to
  use.

Hopefully WxWindows can eventually take advantage of the gtk
pluggable rendering engines to allow whatever look and feel the user wants
(at least as far as that is supported by a set of plugins).

"I.Lam" <No None.Com> writes:

According to my experience in TK/Python, TK is somehow ugly, and dated,
though the tile theme seems OK. And DWT is my most prefered, but is lacking
in port for other platforms except Win.