October 09, 2006
> 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?
October 09, 2006
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.


October 09, 2006
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
October 09, 2006
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?

October 09, 2006
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".

October 09, 2006
> 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
October 09, 2006
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
October 09, 2006
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.
October 09, 2006
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
October 09, 2006
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.