kris wrote:

>>> [...], but Java readily lends itself to mechanical conversion.
>>>
>> Where can I find the translator?
> 
> I'm afraid you can't right now. [...]

> 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.

Another abandoned codebase can be found at:
http://www.dsource.org/projects/molt/

It uses a patched Jikes to convert Java into
XML (!), and then does XSL to turn it into D.

Not that it ever worked too good, but anyway.
--anders

In article <dru9id$1qdc$1@digitaldaemon.com>, Walter Bright says... [...]
> Thoughts?

I sincerely think it won't work, at least as it is.

I think I'm a GUI expert, since I used OWL, MFC, VCL, AWT and Swing, along with
hand-written GUIs for DOS (using graphics primitives) and Windows (using the
Windows API).
I've also designed and written a multi platform GUI library, working on Unix(es)
(based on Motif) and on Windows (using the win32 API).

I try to enumerate the problems I see, in no particular order:

1 - SWT is based, in my opinion, on the wrong idea: every port has its own
implementation. OK, the public interface is the same for all platforms, but
there is not _a_ SWT, there are _many_ SWTs, one for each system it supports.
Each SWT is completely built-up from scratch, very little code base is in
common. Bugs will show in one platform and not in the others. Making a new port
wuold mean making a new SWT from scratch. For more info see:
http://www.eclipse.org/articles/Article-SWT-Design-1/SWT-Design-1.html
and
http://en.wikipedia.org/wiki/Standard_Widget_Toolkit
(see point 4 in the "Criticisms" chapter).

2 - Being the source base in Java will always be a problem, the codebase can be changed by the original maintainers without thinking the whole source should be translatable to D, thus making it short untranslatable. Applying a patch could mean modifying the Java-to-D translator, even heavily. Based on my experience, I think that this won't happen: the two bases will soon fork, and "bye bye SWT".

3 - SWT is not commnly used, nor widely known to developers. Apart from Eclipse and its plugins, very few Java programmers know and use SWT. Most Java programmers use Swing and AWT, few use SWT and other GUI libraries.

Problem number 1 is not solvable, apart from choosing a different library (i.e.
Swing).
Problem number 2 is solvable in one way only: compiling directly Java into
object code and link it with your D program. It's something GCC could do, but I
don't know if it is an easy task or a difficult task.
Problem number 3 means that one the main advantage of using SWT goes away, since
it will give a short user base to start with.

Anyways, having one standard GUI library is better than having none. Maybe having _two_ standard libraries won't hurt (Java has AWT and Swing, and it doesn't hurt).

Ciao
---
http://www.mariottini.net/roberto/

May I suggest developing a bindings and/or wrappers for QT? Although I have never really developed any code with QT, it is regarded as a truly professional framework for developing multiplatform GUIs. It is also meant to work on embedded systems, on which it is known as QTopia. Check it out: www.trolltech.com The only real downside is that it's meant for C++ developers, so doing something in the fashion of wxD may be necessary.

--Sebastián

On Thu, 02 Feb 2006 19:53:26 -0500, Walter Bright <newshound@digitalmars.com> 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/
>

Wouldn't it be better using a more minimalist GUI library (MinWin?)? That way it'd be a hell of a lot easier to support standard D on more platforms, and even obscure platforms. e.g. D kernel/OS projects.

Just because DWT is the best candidate now doesn't mean it's the best for std D.

Having a minimal standard one may still encourage people to make their own GUI libs that use the standard one as a base. Some lightweight ones, some heavyweight ones, some feature-full, some special case, etc. Having this DWT beast in the standard may make things worse: discourage people from making other GUI libs since most people will only want to use this fully featured standard one, which means people who want alternative ones (e.g. a lightweight one) will not have any available to them. Maybe this paragraph is too dramatic, but it has some merit.

Sebastián E. Peyrott wrote:
> May I suggest developing a bindings and/or wrappers for QT? Although I have never really developed any code with QT, it is regarded as a truly professional framework for developing multiplatform GUIs. It is also meant to work on embedded systems, on which it is known as QTopia. Check it out: www.trolltech.com The only real downside is that it's meant for C++ developers, so doing something in the fashion of wxD may be necessary.

There are severe licensing issues with Qt. It's *not* free for commercial development.

In article <drvjic$2npk$1@digitaldaemon.com>, Don Clugston says...
>
>Sebastián E. Peyrott wrote:
>> May I suggest developing a bindings and/or wrappers for QT? Although I have never really developed any code with QT, it is regarded as a truly professional framework for developing multiplatform GUIs. It is also meant to work on embedded systems, on which it is known as QTopia. Check it out: www.trolltech.com The only real downside is that it's meant for C++ developers, so doing something in the fashion of wxD may be necessary.
>
>There are severe licensing issues with Qt. It's *not* free for commercial development.

Crap, that's right. My free/open-source-based mind always forgets that support for commercial apps is needed...

In any case, I believe the way to go here is to implement entirely in D a well
kown specification (a la DWT). That would allow us to get other languages out of
the equation, the problem is that that specification must be well known in order
to attract users, and open, to allow commercial and open apps to be developed on
it. SWT is still not that known outside the world of Java, so that's the main
problem here.
Would a BSD-like licence like the one from the Enlightenment project be a
problem for commercial adoption of a library? They have developed their own
libraries and widget sets that are über-fast and portable. We should explore all
possibilities before spearheading into a project that is so important for the
adoption of D.

Don Clugston wrote:
> 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.
> 

Thinking pink? =P  I agree.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/MU/S d-pu s:+ a-->? C++++$ UL+++ P--- L+++ !E W-- N++ o? K? w--- O M--@ V? PS PE Y+ PGP- t+ 5 X+ !R tv-->!tv b- DI++(+) D++ G e++>e h>--->++ r+++ y+++
------END GEEK CODE BLOCK------

James Dunne

Yes, Eclipse uses the GEF ( graphical editing framework :
http://www.eclipse.org/gef/ ) for their VEP (
visual editor project : http://www.eclipse.org/vep/WebContent/main.php) ,
which develps guis for swing / swt / whatever_you_want.

However I've been trying to use it ( with no guidance mind you ) out of the box , and its a bit difficult to get working for me.  I am trying opening a blank file with 'Open with visual editor' as per instructions but it always just comes up blank , only the example seems to work with SWT for me.

Any big eclipse users ?  Im doing something wrong ?

Charlie




"Dave" <Dave_member@pathlink.com> wrote in message news:drut3p$26hq$1@digitaldaemon.com...
> 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?
>
>

Sebastián E. Peyrott wrote:

> In article <drvjic$2npk$1@digitaldaemon.com>, Don Clugston says...
>>
>>Sebastián E. Peyrott wrote:
>>> May I suggest developing a bindings and/or wrappers for QT? Although I
>>> have never really developed any code with QT, it is regarded as a truly
>>> professional framework for developing multiplatform GUIs. It is also
>>> meant to work on embedded systems, on which it is known as QTopia. Check
>>> it out: www.trolltech.com
>>> The only real downside is that it's meant for C++ developers, so doing
>>> something in the fashion of wxD may be necessary.
>>
>>There are severe licensing issues with Qt. It's *not* free for commercial development.
> 
> Crap, that's right. My free/open-source-based mind always forgets that support for commercial apps is needed...
> 
> In any case, I believe the way to go here is to implement entirely in D a
> well kown specification (a la DWT). That would allow us to get other
> languages out of the equation, the problem is that that specification must
> be well known in order to attract users, and open, to allow commercial and
> open apps to be developed on it. SWT is still not that known outside the
> world of Java, so that's the main problem here.
> Would a BSD-like licence like the one from the Enlightenment project be a
> problem for commercial adoption of a library? They have developed their
> own libraries and widget sets that are über-fast and portable. We should
> explore all possibilities before spearheading into a project that is so
> important for the adoption of D.

I agree with you about would have been _best_, but this has already been explored for a long, long time. The D community just don't currently have the manpower to create such a large library from the bottom. Also, it seems most of us want different things from our GUI-libraries, thus the flurry of smaller libraries, DFL, SWDF, MinWin and DIG, then we have Terra and Harmonia as interesting techdemos, and for the larger efforts (all based on existing stuff), we have DWT and wxD (and the one I miss most, DUI (gtk-wrapper)). (Sorry if I forgot anyone ;) The large portable libraries of today (except possibly SWT), all was started back when such kits were a novel idea (and Qt was a business opportunity to be taken), which means they have been in development for over 10 years with large teams. Even KDE, based on Qt, turns 10 this year.

Just my two øre.

Lars Ivar Igesund

Great work!  Thanks so much for your contributions. I'm looking forward to OpenGL support.  Maybe I can actually start using D now!

-Craig