Craig Black wrote:

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

You can download opengl support from http://www.algonet.se/~afb/d/

Will post the wxc/glcanvas.cpp and wx/GLCanvas.d shortly, as well...
Note: you will also need a wx with OpenGL support, and OpenGL libs.

--anders

"Chris Miller" <chris@dprogramming.com> wrote in message news:op.s4edcoaqpo9bzi@moe...
> 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.

A good point. But, as you say, DWT won't prevent use of other gui toolkits. The D language and Phobos itself will not be dependent on DWT.

I am concerned, though, that having a lightweight standard GUI library will cast D as a lightweight, not serious, language.

I think DWT, and any other GUI option is an EXTREMELY valueable asset to the D programming language - don't get me wrong. I just think mirroring source is almost as bad of an idea as pushing a standard gui for D. DWT should improve on SWT - using the features of D, and than go beyond SWT and make DWT a gui toolkit - based on SWT, but taken to the next level. A level that is made more possible by using a system-level language with powerful features - such as D.

I hope to one day see the D programming language spread like wildfire - and realize that will only happen when companies use it. I know many of you wish very much you could use D at work, but your company would never go for it. If we want to progress, we need to ask ourselves "Why wouldn't my company use D?"

The answer to that question, is what needs to be fixed. If the answer really is, "Well, we could if it was easy make SWT code work for it", than lets lend a hand to DWT, but if it's something entirely different, lets figure out what it is, and work on that.

I love D, and will probably be a D programmer for life. I have allot of time invested in Terra, Titan, and Fusion, and hope to contribute to the community even more as time goes on - I would hate for D to never really spread, just because we missed the point.

Thanks,
Trevor Parscal

It's been a while since I evaluated different GUI libraries, but I found DFL to be the most usable, and it seems well supported and active.

However, I write that as a Windows developer, and not well informed on how cross-platform DFL is (or could be).

I've used native Win32-api, MFC, AWT, Swing, DFL, and wxWidgets. I've had less than positive experiences with wxWidgets.

I have doubts about trying to keep DWT up with SWT as SWT evolves. I suppose you can take a "snapshot" at a point in time, but from then on, they will diverge.

my 2¢ worth

In some way, I believe we want D to be widespread so quickly because we actually
want to use it for something big and important. It feels like we want things
right now. I mean, it's obvious that it took years for a community to build a
powerful toolkit such as GTK or wxWidgets, and even more time to get mainstream
acceptance. Why should it be different for us? I mean, even if we all decide to
go and port something already in use, it'll be a long time for it to get
acceptance out of the D community. One way or another, I think a long time will
pass before D is "everywhere". That means this is the right moment to take up a
big project. To start something new, something that shows why D is so powerful
and scales so well as the project gets bigger.
Now, I'm not saying a GUI is necessarily that Big Thing(tm) we need, but
scraping the idea because it'd be a lengthy task is not justifiable as this is
the right moment for such thing.
Nevertheless, I still believe that, when it comes to GUIs, going for something
in use is probably the best thing to do, so I'll support DWT, DUI and wxD.

>I am concerned, though, that having a lightweight standard GUI library will cast D as a lightweight, not serious, language.

I believe a GUI should not be directly incorporated into the standard library.
Although that's just my subjective way of seeing a standard library. Support for
independent projects is what seems to be best IMO.
As someone said before, supporting different projects and different ways of
taking up on this problem is what needs to be done. wxD, DWT, DUI, whatever.
Choice is attractive, and we can already offer that, even if it's not complete
;).


--Sebastián

Walter,

can we first define sort of requirements sheet for such thing as "D standard GUI library"?

Sidenote: My deepest respect to Shawn Liu for his tremendous effort to port
SWT.
DWT  is really something, but this message about principles rather than his
and some other library in particular.

First of all:

There are two types of approaches universal GUI toolkits are based on:
    a) wrappers of native OS widgets - AWT/SWT/DWT per se,
        MFC(at some extent), WTL, etc.
    b) OS agnostic toolkits implementing their own set of widgets:
        SWING, GTK, QT, FLTK, FoxToolkit, etc. (my Harmonia is also here)

It depends on the task you need to accomplish which one to choose.
Obviously toolkits from group A are too OS dependent - as a rule they have
very thick OS isolation layer and sometimes it is just impossible to make
a common denominator for different OSes. For example Mac and Win are
so distinct that it is almost impossible to make practical library (fast,
effective, compact)
natively working on both - different principles at all: event dispatching,
windowing,
resource architecture, etc.
Group B has its own pluses and minuses: it is best suitable for applications
which has their own UI standards - really look the same on different
platforms:
IDEs, games, things like Google's Picasa or Norton Antivirus - all that
types of applications.

Sidenote: The history of Swing / SWT wars in Java has simple origin:
   architectire of Java drawing is based on assumption that "memory
   is not a resource anymore and GC rocks" thus such things as
   <java>
   Dimension Component.getDimension() { return new Dimension(dimension); }
   </java>
   (immutability for dummies) are spreaded all over the code
    making GUI a "joy of GC".  Surely they got a problem in drawing, so SWT
    was born with the motto:  "If we cannot draw complex things fast then
    we will delegate this to OS"  Thus and so SWT far less OS
    independent than Swing.

Second:

Java code as a source...
I really don't want to start this fire again but:
1) "D is not Java" "D is not C++" (C) Walter Bright.
    Not in notation, not in runtime/VM model, not in architecture.
    So as we have "Automated translation from C++ is essentially
impossible." in the
    same essential way we can say "Automated translation from Java is
impossible."
    (Doing Harmonia I personally find that porting code from C++ and Java is
     a task of the same complexity - to be precise - not complex at all,
     just requires "new D thinking" )
2) Automatic translation Java to D... I beleive such tool is just not
    practically feasible to be honest.
3) Having port of SWT always means dependency from it.
    I beleive that conceptually DWT is a fork - after some point it
    will go its own way. This is a reality and I don't see nothing criminal
in that.
    Just don't even think that you can take project A from Java and do
    automatic upgrades of D side each time than they will do something new.

Third:

Traditionally any GUI toolkit is a test case of  OOP features of particular
language. I beleive that OOP in D is way superior and handy than what Java
and C++ offer now. I think that "D standard GUI library" if it will exist
shall use full
potential of D from ground up rather than try to inherit OOP workarounds
from
Java and C++. Think about delegates at least.
"D standard GUI library" shall be a hymn of D and not a rehash of some other
song
but in different language.

And the last.
Here is my vision of what "D standard GUI library" should be:

It should be not a single entity but following three:

1) Standard D Graphics package (SDG) - this is really could be made in
uniform fashion -
all GUI OSes has concept of Surface or Graphics and have primitives like
draw text, draw line etc. Support of Image (and different formats) is also
here.
(If we will have only this then it will benefit a lot - different frameworks
can share
 at least drawing code).

2) Standard Application Framework, SAF (uses SDG)
These should use MinWin (Ben Hinkle) approach  -
minimalistic application framework (events, winmain, menu, OS integration)
allowing to build application with native look-n-feel for underlying
platform.
This framework deals with native OS windows and knows about them and
probably shall exists in three versions: for Win32, Mac, GTK
Nothing from rocket science here please: pure window creation and
handling of native OS events in human readable manner.

3) Standard "X".... I don't know of how to name this but something like
Harmonia
or its part: system of OS independent (windowless) widgets + html engine.
This Standard "X" shall also use SDG and shall allow to be
embedabble into SAF (as a component living in some window)
Also this Standard "X" shall allow to build pure OS independent
applications (using only top level Window frames from SAF).

Having all these will give D flexibility in various GUI approaches and demonstrate the power of D .

Andrew Fedoniouk.
http://terrainformatica.com




"Walter Bright" <newshound@digitalmars.com> wrote in message news:dru9id$1qdc$1@digitaldaemon.com...
> 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?
> 

Anders F Björklund wrote:
> Craig Black wrote:
> 
>> Great work!  Thanks so much for your contributions. I'm looking forward to OpenGL support.  Maybe I can actually start using D now!
> 
> You can download opengl support from http://www.algonet.se/~afb/d/
> 
> Will post the wxc/glcanvas.cpp and wx/GLCanvas.d shortly, as well...
> Note: you will also need a wx with OpenGL support, and OpenGL libs.
> 
> --anders

This is GREAT news. Cross platform gaming anyone?

Kyle Furlong wrote:

>> Will post the wxc/glcanvas.cpp and wx/GLCanvas.d shortly, as well...
>> Note: you will also need a wx with OpenGL support, and OpenGL libs.
> 
> This is GREAT news. Cross platform gaming anyone?

Actually SDL would be better for making games, but they work together.
(depending on the game of course, some games are more like applications)

SDL works fine with D too, so there are no problems in that aspect...
One of my own projects is a gaming library, so it has been tested.

--anders

If I understand you correctly, you are suggesting creating cross-platform solutions for components that will be useful to any GUI framework.  Once these components are in place (perhaps in a standard library), the task of creating the the GUI framework becomes less overwhelming.  It is the logical first step.  Is this a correct assessment of what you are proposing?

-Craig

"Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:ds0i3b$pgs$1@digitaldaemon.com...
> Walter,
>
> can we first define sort of requirements sheet for such thing as "D standard GUI library"?
>
> Sidenote: My deepest respect to Shawn Liu for his tremendous effort to
> port SWT.
> DWT  is really something, but this message about principles rather than
> his
> and some other library in particular.
>
> First of all:
>
> There are two types of approaches universal GUI toolkits are based on:
>    a) wrappers of native OS widgets - AWT/SWT/DWT per se,
>        MFC(at some extent), WTL, etc.
>    b) OS agnostic toolkits implementing their own set of widgets:
>        SWING, GTK, QT, FLTK, FoxToolkit, etc. (my Harmonia is also here)
>
> It depends on the task you need to accomplish which one to choose.
> Obviously toolkits from group A are too OS dependent - as a rule they have
> very thick OS isolation layer and sometimes it is just impossible to make
> a common denominator for different OSes. For example Mac and Win are
> so distinct that it is almost impossible to make practical library (fast,
> effective, compact)
> natively working on both - different principles at all: event dispatching,
> windowing,
> resource architecture, etc.
> Group B has its own pluses and minuses: it is best suitable for
> applications
> which has their own UI standards - really look the same on different
> platforms:
> IDEs, games, things like Google's Picasa or Norton Antivirus - all that
> types of applications.
>
> Sidenote: The history of Swing / SWT wars in Java has simple origin:
>   architectire of Java drawing is based on assumption that "memory
>   is not a resource anymore and GC rocks" thus such things as
>   <java>
>   Dimension Component.getDimension() { return new Dimension(dimension); }
>   </java>
>   (immutability for dummies) are spreaded all over the code
>    making GUI a "joy of GC".  Surely they got a problem in drawing, so SWT
>    was born with the motto:  "If we cannot draw complex things fast then
>    we will delegate this to OS"  Thus and so SWT far less OS
>    independent than Swing.
>
> Second:
>
> Java code as a source...
> I really don't want to start this fire again but:
> 1) "D is not Java" "D is not C++" (C) Walter Bright.
>    Not in notation, not in runtime/VM model, not in architecture.
>    So as we have "Automated translation from C++ is essentially
> impossible." in the
>    same essential way we can say "Automated translation from Java is
> impossible."
>    (Doing Harmonia I personally find that porting code from C++ and Java
> is
>     a task of the same complexity - to be precise - not complex at all,
>     just requires "new D thinking" )
> 2) Automatic translation Java to D... I beleive such tool is just not
>    practically feasible to be honest.
> 3) Having port of SWT always means dependency from it.
>    I beleive that conceptually DWT is a fork - after some point it
>    will go its own way. This is a reality and I don't see nothing criminal
> in that.
>    Just don't even think that you can take project A from Java and do
>    automatic upgrades of D side each time than they will do something new.
>
> Third:
>
> Traditionally any GUI toolkit is a test case of  OOP features of
> particular
> language. I beleive that OOP in D is way superior and handy than what Java
> and C++ offer now. I think that "D standard GUI library" if it will exist
> shall use full
> potential of D from ground up rather than try to inherit OOP workarounds
> from
> Java and C++. Think about delegates at least.
> "D standard GUI library" shall be a hymn of D and not a rehash of some
> other song
> but in different language.
>
> And the last.
> Here is my vision of what "D standard GUI library" should be:
>
> It should be not a single entity but following three:
>
> 1) Standard D Graphics package (SDG) - this is really could be made in
> uniform fashion -
> all GUI OSes has concept of Surface or Graphics and have primitives like
> draw text, draw line etc. Support of Image (and different formats) is also
> here.
> (If we will have only this then it will benefit a lot - different
> frameworks can share
> at least drawing code).
>
> 2) Standard Application Framework, SAF (uses SDG)
> These should use MinWin (Ben Hinkle) approach  -
> minimalistic application framework (events, winmain, menu, OS integration)
> allowing to build application with native look-n-feel for underlying
> platform.
> This framework deals with native OS windows and knows about them and
> probably shall exists in three versions: for Win32, Mac, GTK
> Nothing from rocket science here please: pure window creation and
> handling of native OS events in human readable manner.
>
> 3) Standard "X".... I don't know of how to name this but something like
> Harmonia
> or its part: system of OS independent (windowless) widgets + html engine.
> This Standard "X" shall also use SDG and shall allow to be
> embedabble into SAF (as a component living in some window)
> Also this Standard "X" shall allow to build pure OS independent
> applications (using only top level Window frames from SAF).
>
> Having all these will give D flexibility in various GUI approaches and demonstrate the power of D .
>
> Andrew Fedoniouk.
> http://terrainformatica.com
>
>
>
>
> "Walter Bright" <newshound@digitalmars.com> wrote in message news:dru9id$1qdc$1@digitaldaemon.com...
>> 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?
>>
>
> 

Andrew Fedoniouk wrote:
> <snip>
> 
> Third:
> 
> Traditionally any GUI toolkit is a test case of  OOP features of particular
> language. I beleive that OOP in D is way superior and handy than what Java
> and C++ offer now. I think that "D standard GUI library" if it will exist shall use full
> potential of D from ground up rather than try to inherit OOP workarounds from
> Java and C++. Think about delegates at least.
> "D standard GUI library" shall be a hymn of D and not a rehash of some other song
> but in different language.
> 

What a beautiful way to put it. I agree.

> <snip>
> Andrew Fedoniouk.
> http://terrainformatica.com
> 

As long as we are critiquing DWT...

1. No Ares support
2. Java-like coding style = YUCK!

But as we all know it is a very useful tool, so maybe the PRACTICAL thing is to support it officially.