www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Could Tk be D's ideal widget set?

reply 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
Oct 07 2006
next sibling parent reply 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

Oct 07 2006
parent reply 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?
Oct 09 2006
next sibling parent reply 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?

Oct 09 2006
parent reply 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.
Oct 09 2006
next sibling parent reply 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
Oct 09 2006
parent reply 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>.
Oct 09 2006
next sibling parent reply Mars <nospam null.void> writes:
Isn't that what the gtk people did?
Oct 09 2006
parent 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".
Oct 09 2006
prev sibling parent =?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
Oct 10 2006
prev sibling parent 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.
Oct 09 2006
prev sibling parent reply 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

 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".
Oct 09 2006
parent reply 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

 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.
Oct 10 2006
next sibling parent reply 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



 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



 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).
Oct 10 2006
parent reply 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.

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?

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



 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.

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.

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



 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.

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.

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.


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?

"content".

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).
Oct 10 2006
next sibling parent 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
Oct 10 2006
prev sibling next sibling parent reply 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

 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.
Oct 10 2006
parent reply 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).

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

 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.
Oct 11 2006
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Don Clugston wrote:
 Josh Stern wrote:
 On Tue, 10 Oct 2006 18:52:49 +0200, Don Clugston wrote:

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
Oct 11 2006
prev sibling parent 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
Oct 11 2006
prev sibling parent reply 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.
Oct 15 2006
parent =?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)
Oct 15 2006
prev sibling next sibling parent reply =?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.
Oct 08 2006
next sibling parent reply 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.
Oct 08 2006
parent reply =?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
Oct 08 2006
parent reply 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/
Oct 08 2006
next sibling parent 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
Oct 08 2006
prev sibling parent reply =?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
Oct 09 2006
parent =?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
Oct 09 2006
prev sibling parent reply 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?
Oct 08 2006
parent =?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
Oct 08 2006
prev sibling next sibling parent reply 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.
Oct 08 2006
parent reply =?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
Oct 09 2006
parent reply 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.
Oct 09 2006
next sibling parent 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. ***************************************************************
Oct 09 2006
prev sibling parent reply =?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. (Java, or even C#, is actually easier to port to D - than what C++ is) 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. There is also a Qt# project: http://qtcsharp.sourceforge.net/ (GPL) (this one also used a Perl program to generate the initial C# files) 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
Oct 10 2006
parent reply 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. (Java, or even C#, is actually easier to port to D - than what C++ is)

"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.
 There is also a Qt# project: http://qtcsharp.sourceforge.net/

 (this one also used a Perl program to generate the initial C# files)

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

 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

 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.
Oct 10 2006
parent reply =?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. 
(Java, or even C#, is actually easier to port to D - than what C++ is)

"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
Oct 10 2006
parent reply 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. 
(Java, or even C#, is actually easier to port to D - than what C++ is)

"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.
Oct 10 2006
parent reply =?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
Oct 10 2006
parent 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

 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,

 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).
Oct 10 2006
prev sibling parent "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.
Oct 09 2006