Walter Bright wrote:
> "pragma" <pragma_member@pathlink.com> wrote in message news:drujts$20j4$1@digitaldaemon.com...
> 
>>In a perfect world, Kris and Shawn would simply collaborate on getting an
>>automated translation to work, with the addition of a few hand-coded bits where
>>needed.  This would take advantage of the full field of experience between these
>>two gentlemen, and the end-result would be a single (and well-done) SWT port.
>>Maybe there's room for collaboration here; I'd like to think so.
> 
> 
> I think there is, too.
> 
> 
>>I've gone on the record before about this: I strongly feel that using as much
>>automation as is prudent (following the 80/20 rule) will help ensure the health
>>of a D SWT port.  This way, the library can more easily track changes in the
>>original codebase.  Such a nimble maintainence policy is *essential* to the
>>overarching goal here: leveraging SWT's niche.
> 
> 
> I also believe that given the huge size of SWT, relying on automation as much as possible is the most likely route to success. In other words, DWT should make no attempt to fix design problems in SWT, nor should it make an attempt to do things the D way rather than the Java way (other than the obvious like replacing java.lang.String with char[], etc.). It should just translate the code in as straightforward a manner as possible. There should be a 1:1 mapping between SWT source files and DWT files. 
> 
> 

How will that work 1:1 when D's module names cannot be == to class names?

How also will that work with dynamic class loading?  (I certainly hope SWT isn't doing such nastiness in a GUI...)

Just trying to keep people on their toes, as usual.. :)

In article <drumd3$21tu$1@digitaldaemon.com>, Walter Bright says...
>
>
>"pragma" <pragma_member@pathlink.com> wrote in message news:drujts$20j4$1@digitaldaemon.com...
>> In a perfect world, Kris and Shawn would simply collaborate on getting an
>> automated translation to work, with the addition of a few hand-coded bits
>> where
>> needed.  This would take advantage of the full field of experience between
>> these
>> two gentlemen, and the end-result would be a single (and well-done) SWT
>> port.
>> Maybe there's room for collaboration here; I'd like to think so.
>
>I think there is, too.
>
>> I've gone on the record before about this: I strongly feel that using as
>> much
>> automation as is prudent (following the 80/20 rule) will help ensure the
>> health
>> of a D SWT port.  This way, the library can more easily track changes in
>> the
>> original codebase.  Such a nimble maintainence policy is *essential* to
>> the
>> overarching goal here: leveraging SWT's niche.
>
>I also believe that given the huge size of SWT, relying on automation as much as possible is the most likely route to success. In other words, DWT should make no attempt to fix design problems in SWT, nor should it make an attempt to do things the D way rather than the Java way (other than the obvious like replacing java.lang.String with char[], etc.). It should just translate the code in as straightforward a manner as possible. There should be a 1:1 mapping between SWT source files and DWT files.
>

Isn't there also some GUI development Eclipse plugins for Java that could be ported too?

S. Chancellor wrote:
> Whoever you are, you can stop spoofing as Walter.
> 
> If on the other hand this isn't a joke, I think it's a wonderful idea.
> 
> -S.

ROTFL ! So true ! :D



-- 
Tomasz Stachowiak  /+ a.k.a. h3r3tic +/

James Dunne wrote:

> How also will that work with dynamic class loading?  (I certainly hope SWT isn't doing such nastiness in a GUI...)

I can vouch that it doesn't do anything like that

Walter Bright wrote:
> First, let me start off by saying my knowledge about GUI's and their design tradeoffs is nearly nonexistent. But the D community is small, and so in the selection of a GUI one criterion stands out above all others: LEVERAGE. With a long enough lever, one person can move a mountain. So it's not about the mountain with the best view, it's about the mountain with an adequate view and the longest lever on it.
[snip]
> I believe that DWT is the best chance for D to get a comprehensive, portable, top quality GUI given our limited resources. It's already there for Windows. It's time we jumped on the bandwagon and give it the momentum it needs. Thoughts? 

I completely agree.  I would applaud an official pronouncement to this effect. It's worried me that there are so many D GUI projects, most of which haven't got very far. United we stand and divided we fall.

Glad to hear about this and the "translator".

For a long run solution, an automation is the best choice. Port such a big project all by hand is a heavy burden. And the maintenance is also a big problem.

And a java to D translator will be very useful for other java stuff, since there are many requirements to port other java projects to D. Currently, I am focusing on the "JFace" and "Draw2D" from Eclipse. JFace is a high level wrapper of SWT. It is more suitable for auto conversion since it is platform independent. Draw2D is an excellent drawing tool as well as a light weight system. It will help to make drawing simply. And it also makes a GUI Builder simply. Draw2D is based on SWT and seems platform independent.

It's not possible for us to port those all by hand. A translator is appreciated.


The auto converted SWT to D and the current win32 port of DWT can be merged together, or make a copy available. Since the public APIs of SWT is identical even for the different platforms, the DWT user should not worry about which release to use.



"Kris" <fu@bar.com> says:drummm$226n$1@digitaldaemon.com...
> "pragma" <pragma_member@pathlink.com> wrote ...
>
> I don't think Walter was suggesting we redo DWT-Wiin32? Rather, I suspect he meant a translation tool may provide a jump-start on the GTK and OS-X versions? If, at some future point, Shawn finds himself wallowing in update-hell, then it may be appropriate to consider options at that time?
>
> However, there's more to it than that. I thought JJR made a wonderfully honest and succinct post over at dsource.org (in the DWT forum), regarding the problems of being a sole-developer on a project of this magnitude. This is hopefully where the community can help?
>
> That "translator" is a hack of wondrous proportions, Brad. Hasn't changed much. I did use it the other weekend to port another of Doug Lea's uber-vorks, and it helped enormously. But it's not a panacea ~ just handles all the grunt work (I recall it made around 22,000 changes to the SWT codebase of ~450 files). There's a second-pass needed to handle codebase-specific changes, but Java readily lends itself to mechanical conversion.
> 

> 
> That "translator" is a hack of wondrous proportions, Brad. Hasn't changed much. I did use it the other weekend to port another of Doug Lea's uber-vorks, and it helped enormously. But it's not a panacea ~ just handles all the grunt work (I recall it made around 22,000 changes to the SWT codebase of ~450 files). There's a second-pass needed to handle codebase-specific changes, but Java readily lends itself to mechanical conversion.
> 
Where can I find the translator?

Zz

Walter Bright wrote:

> Everyone agrees that D needs a standard gui. I think it's time to put all the wood behind one arrow, to borrow some Microsoft-speak.

Sounds good that D has a favorite platform and a favorite GUI toolkit,
but wxD isn't going anywhere either. I think it could be a very good
*alternative*, just as GDC is a good alternative/complement to DMD...


Let me fill in what we *already* have for wxD, when compared with DWT.
(see also http://www.prowiki.org/wiki4d/wiki.cgi?AvailableGuiLibraries)

> DWT is a port of SWT, http://www.eclipse.org/swt/. Here's the dsource forum link: http://www.dsource.org/forums/viewtopic.php?t=1169 and the dsource project link: http://www.dsource.org/projects/dwt/

wxD are bindings for wxWidgets, http://www.wxwidgets.org.
The SF project link for it is http://wxd.sourceforge.net/

> SWT seems to have the longest lever:
> 
> 1) It's written in Java, which is the easiest code to translate to D besides C, perhaps even easier (no macros <g>). Furthermore, Kris has written a tool to automate some of the translation. Automated translation from C++ is essentially impossible.

wxWidgets is written in C++, so there are *no* plans of porting that...
The class hierarchy is ported over from C#, which isn't too bad either.

> 2) Ports of SWT exist for all the platforms we care about. If new GUI platforms of significance emerge, it's likely that the Eclipse org will do an SWT port to it, that we can then leverage for D.

wxWidgets *and* wxD exists for at least Windows, Linux and Macintosh.
Other platforms that have GDC and wxWidgets support are possible too.

> 3) The SWT license allows us to use it for D.

The wxWidgets license also allows that, even allows for static linking.
(unlike other projects using LGPL, such as SDL, which require dynamic)

http://www.wxwidgets.org/licence3.txt

> 4) SWT is part of Eclipse, meaning it has heavy industry support and so is, in many ways, already a standard and is unlikely to go away.

wxWidgets has been used for 12 years, so I don't think it'll disappear.
(See "Who uses wxWidgets?" at http://www.wxwidgets.org/whouses.htm)

> 5) Conversion of SWT to DWT can maintain the original design and layout nearly intact. This is big implications - such as DWT can also leverage the books, documentation, and tutorials already written for SWT.

wxD has been converted from wx.NET, so we can use the documentation for that. The actual wx classes and how you use them is very similar to C++.

http://wxnet.sourceforge.net/docs.html (C#)
http://www.wxwidgets.org/docs.htm (C++)

> 6) Shawn Liu, in an incredible one man effort, has produced DWT for Windows. He's proven it will work for D.

Bero did most of the heavy lifting for wxD, porting the C# classes over.
(and adopting the C++ wrappers to use D strings instead of std::string)

> 7) DWT for Mac OS X is being worked on by Carlos, and for Linux by JJR. (These two efforts can certainly use a hand from any volunteers!)

I've added wxD support for Mac OS X and for Linux/GTK+, and *all* GNU platforms... (all you need is to add some configurations, and rebuild)

> 8) DWT is written in D, not as a shell around some other language, so it helps validate D as a real language.

wxD is just being written as a shell/wrapper, half in C++ and half in D.
There is nothing inherently wrong with using existing libraries, right ?

> I believe that DWT is the best chance for D to get a comprehensive, portable, top quality GUI given our limited resources. It's already there for Windows. It's time we jumped on the bandwagon and give it the momentum it needs. Thoughts? 

Meanwhile; before the comprehensive, portable, top quality GUI arrives,
one can use wxD (and wxWidgets) and help us sort out the final wxD bugs.

It's already working tolerably on Windows, Linux and Macintosh.
(currently being tested on Windows XP, Linux/GTK+ and Mac OS X)

See http://wxd.sourceforge.net/#screenshots for "Minimal" sample

--anders


PS. OpenGL support is 99% done, and coming in the next wxD version.
    (basically it was just missing since it was harder to do in C#)

    HTML support is already included, in the current wxD release.
    http://wxd.sourceforge.net/HtmlHelp.png (using native renderer)

Totally agree! DWT is absolutely great.


Walter Bright wrote:
> Everyone agrees that D needs a standard gui. I think it's time to put all the wood behind one arrow, to borrow some Microsoft-speak.
> 
> DWT is a port of SWT, http://www.eclipse.org/swt/. Here's the dsource forum link: http://www.dsource.org/forums/viewtopic.php?t=1169 and the dsource project link: http://www.dsource.org/projects/dwt/
> 
> First, let me start off by saying my knowledge about GUI's and their design tradeoffs is nearly nonexistent. But the D community is small, and so in the selection of a GUI one criterion stands out above all others: LEVERAGE. With a long enough lever, one person can move a mountain. So it's not about the mountain with the best view, it's about the mountain with an adequate view and the longest lever on it.
> 
> SWT seems to have the longest lever:
> 
> 1) It's written in Java, which is the easiest code to translate to D besides C, perhaps even easier (no macros <g>). Furthermore, Kris has written a tool to automate some of the translation. Automated translation from C++ is essentially impossible.
> 
> 2) Ports of SWT exist for all the platforms we care about. If new GUI platforms of significance emerge, it's likely that the Eclipse org will do an SWT port to it, that we can then leverage for D.
> 
> 3) The SWT license allows us to use it for D.
> 
> 4) SWT is part of Eclipse, meaning it has heavy industry support and so is, in many ways, already a standard and is unlikely to go away.
> 
> 5) Conversion of SWT to DWT can maintain the original design and layout nearly intact. This is big implications - such as DWT can also leverage the books, documentation, and tutorials already written for SWT.
> 
> 6) Shawn Liu, in an incredible one man effort, has produced DWT for Windows. He's proven it will work for D.
> 
> 7) DWT for Mac OS X is being worked on by Carlos, and for Linux by JJR. (These two efforts can certainly use a hand from any volunteers!)
> 
> 8) DWT is written in D, not as a shell around some other language, so it helps validate D as a real language.
> 
> I believe that DWT is the best chance for D to get a comprehensive, portable, top quality GUI given our limited resources. It's already there for Windows. It's time we jumped on the bandwagon and give it the momentum it needs. Thoughts? 
> 
> 

ZZ wrote:
>>
>> That "translator" is a hack of wondrous proportions, Brad. Hasn't changed much. I did use it the other weekend to port another of Doug Lea's uber-vorks, and it helped enormously. But it's not a panacea ~ just handles all the grunt work (I recall it made around 22,000 changes to the SWT codebase of ~450 files). There's a second-pass needed to handle codebase-specific changes, but Java readily lends itself to mechanical conversion.
>>
> Where can I find the translator?
> 
> Zz

I'm afraid you can't right now. It's not packaged in any form suitable for redistribution, and it is not turn-key. Was originally written explicitly for converting SWT (last April or May I think?), but there's an intermediate/simpler front-end (J2D) that might perhaps be used for almost any Java if you accept some occasional known artifacts (it will sometimes add an import for a module that's not actually used in the code, and there's certain extensive array-inits that it fails to format correctly. It catches most C-style casts, but there are one or two edge cases that slip through, or are mistaken).

The truth is, the whole effort was abandoned right after Shawn got stuck into DWT ~ I saw no point in a duplication of effort, and already had enough on my plate at the time. Shawn and I discussed it back then, and it was clear he was going to be successful without the help of that tool.

So while it can happily work on further ports of SWT, it wasn't constructed or considered for external usage at all ~ way too much of a hack! A couple of months back, I did seriously consider building another one using a much more robust approach ~ but haven't found the time.