Sean Kelly wrote:
> <snip> For D to be taught in a university course I think it probably needs a book about it. </snip>
> 
> 
> Sean

I told my professor about D and he really liked the language comparison chart on digitalmars.com because it used the same words as his 'Principles of Programming Languages' course. He told me he might include D as one of the languages to compare for the next year.

Andrew Fedoniouk wrote:
[snip]
> And this is exactly the purpose AWT serves in Java world.
> Swing and SWT were built on top of AWT.
> AWT is really the egg.

Andrew,

It's been crystal clear for a (very) long time that you know absolutely zero about SWT. That's fine, but the FUD you insist on spreading about it is not (please reread some of your recent posts on this topic). You'd do the NG, and yourself, a big favour if you'd actually do some background on SWT first.

For example, arguably the biggest controversy regarding SWT is the fact that is does not garbage-collect resources (such as brushes). People kick and scream about this in Java-land, yet it matches D perfectly (since dtors are not guaranteed). This would be a fine soapbox for you perhaps.

SWT has /no/ design relationship with AWT. Zero. Instead, it was designed and written by the ex-SmallTalk team, partly in protest of the serious AWT (and subsequently Swing) design faults. You should perhaps read the history of it ~ quite fascinating actually, from a political perspective ~ there's a link in the dsource DWT forums from a long time ago (but, you wouldn't have seen that either).

You further make vacuous and wildly unjustified claims about it just not being feasible to translate SWT to D ~ if you've tried, and failed, then that's your problem. If you haven't even tried, then shame on you. I rather suspect the latter. In fact, if I personally have any involvment in a port of SWT, it will likely be limited to providing a mechanical translator.

Yes, I'm upset. Your shameful misinformation regarding SWT and a potential port to D is a notable catalyst. Contrary to your own public opinion, you clearly do not have superior experience or abilities over the entire SmallTalk group, nor the many capable enthusiasts here.

Now, I don't have a particular bent one way or another regarding GUI. My interests lie in leveraging the documentation, maturity, and functionality of existing technology. For that purpose, SWT is a viable and attractive solution. Please at least try to get your facts straight in future.

clayasaurus wrote:
> Sean Kelly wrote:
>> <snip> For D to be taught in a university course I think it probably needs a book about it. </snip>
> 
> I told my professor about D and he really liked the language comparison chart on digitalmars.com because it used the same words as his 'Principles of Programming Languages' course. He told me he might include D as one of the languages to compare for the next year.

Awesome :-)  My wife is taking a programming languages course right now as well and she's already mentioned D.  With any luck, it will get some attention there as well.


Sean

Andrew Fedoniouk wrote:
> 
> I don't understand where this "standard GUI" bright idea comes from.
> Even Java has no single toolkit: AWT and Swing, SWT plus 3 or 4 more.

Part of that is for historical reasons, as the first model didn't fly so they created a new one.

The advantage to me of having a "standard" toolset (GUI included) is that it allows me to write code that has a pretty reasonable chance of compiling and running with few or no changes on more than one platform.  It also makes it a bit less likely that support for these tools will be suddenly dropped a year later in favor of something new (Microsoft being the poster child for such behavior).  As maintenance takes time and money, it's nice to have some assurances.

But I agree that this isn't always practical, and even with software support guarantees there's no saying the underlying architecture won't change in a way that renders the design meaningless.  I think this is the problem that a slow-moving process like C/C++ standardization faces.

> (I've never seen real application using Swing, btw)
> In .NET situation is similar: Microsoft is dropping WinForms in favour
> of Avalon foundation now.

Trust Microsoft to deprecate an API before it's even been released.  I have a sneaking feeling, however, that the face of Windows will change significantly in the next few years.  They've bet the bank on the success of .NET/CLI.


Sean

In article <ds1j48$1eov$2@digitaldaemon.com>, Walter Bright says...
>
>Reminds me of an anecdote. Back in the 80's at a conference, I was on a discussion panel with representatives from Microsoft, Borland, Watcom, etc. The question was asked "do you have a version of your compiler for floppy disk only machines?" Each vendor by turn gave a detailed explanation of how you could user their compiler on a floppy only machine. Then it got to me. I said: "Sure we have a floppy version. It costs $200 extra and comes with a hard disk." That got a big laugh, and it was the end of that discussion. Not only that, nobody *ever* even brought up the subject again. It was just a dead issue.
>
>And that's how I feel about D on 16 bit machines. Sometimes it's just time to move on.
>
And how you feel about D on 64 bit machines? ;)

--
UB

"kris" <fu@bar.org> wrote in message news:ds3257$2hp3$1@digitaldaemon.com...
> Andrew Fedoniouk wrote:
> [snip]
>> And this is exactly the purpose AWT serves in Java world.
>> Swing and SWT were built on top of AWT.
>> AWT is really the egg.
>
> Andrew,
>
> It's been crystal clear for a (very) long time that you know absolutely zero about SWT. That's fine, but the FUD you insist on spreading about it is not (please reread some of your recent posts on this topic). You'd do the NG, and yourself, a big favour if you'd actually do some background on SWT first.

:)  Mea culpa, this phrase:
"Swing and SWT were built on top of AWT." is not strictly valid in terms of
SWT. Indeed SWT is not built directly on top of AWT.

SWT and AWT use the same architecture.

In AWT there are two to types of UI Componet's : lightweight and
heavyweight.
Ligthweight is a windowless component and Heavyweight through peer has
HWND attached (on Windows).

Each button, editbox, combobox, etc. in AWT is a Heavyweight OS native
component - it has HWND. Peers for native controls implemented
as native code in awt.dll.

SWT uses heavyweight HWND based elements.
JNI (native) part of SWT is more thin than in AWT.
It contains universal WndProc implementation versus specific WinProcs in
AWT.
For each platform OS specific code implemented in Java in SWT.
In AWT OS specific code implemented inside AWT.dll only.
Java part of AWT stays the same for all platforms.

Swing: Swing is really built on top of AWT. JFrame and JDialog there
are the only heavyweight components.
So to create editable grid from editboxes is feasible there but
in SWT if you will try to create grid from HWND textboxes
you will get a problem - Dialogs have physical limitation on number
of children.

From the Class hierarchy perspective and architecture SWT and AWT are twin-brothers.

I would say SWT is built on top of (or using) AWT *ideology*.

Again, the only principal difference is in where OS specific code is
located - in JNI or in Java.
To add support of new OS widget in AWT you need to add code
in awt.dll and and in SWT you will do it in Java code.

SWT and AWT use the same event dispatching mechanism (in principle) and
pretty much close with drawing primitives.
class Graphics (AWT) vs. class GC (SWT) provide the same set of facilities
in principle.

SWT is a part of eclipse application framework (namespace org.eclipse.swt)
and I have never seen it being used alone outside of Eclipse.
Standalone version of SWT does exist but if anyone point finger
on application or project using it I would appreciate it a lot.

From D imlementation point of view there is no difference between AWT and SWT - all code is in D anyway.

>
> For example, arguably the biggest controversy regarding SWT is the fact that is does not garbage-collect resources (such as brushes). People kick and scream about this in Java-land, yet it matches D perfectly (since dtors are not guaranteed). This would be a fine soapbox for you perhaps.

SWT does not have a concept of Brush and Pen.
Creation of BRUSH and PEN in modern OSes is so lightweight
that you can create them each time when you need to use them.

Sidenote: Harmonia follows this path too. E.g.
void gx.Graphics.setPen(color c, int width, PenStyle style =
PenStyle.SOLID_INSIDE)
is just a function - no object creation involved.

Fonts are stored in static hash table and never deleted - the same path MS Office uses.

>
> SWT has /no/ design relationship with AWT. Zero. Instead, it was designed and written by the ex-SmallTalk team, partly in protest of the serious AWT (and subsequently Swing) design faults. You should perhaps read the history of it ~ quite fascinating actually, from a political perspective ~ there's a link in the dsource DWT forums from a long time ago (but, you wouldn't have seen that either).

Yep, as far as I remember I published links about these wars here too.

>
> You further make vacuous and wildly unjustified claims about it just not being feasible to translate SWT to D ~ if you've tried, and failed, then that's your problem. If you haven't even tried, then shame on you. I rather suspect the latter. In fact, if I personally have any involvment in a port of SWT, it will likely be limited to providing a mechanical translator.

Didn't tried to port it as it has not too much sense (for me personally)
as 1) it uses foreign concepts for D.
2) I am pretty fine to work with pure Win32 API if I need to use HWND.
3) See below.

>
> Yes, I'm upset. Your shameful misinformation regarding SWT and a potential port to D is a notable catalyst. Contrary to your own public opinion, you clearly do not have superior experience or abilities over the entire SmallTalk group, nor the many capable enthusiasts here.

Again I am not against someone in particular or against DWT -
it is an excellent project really as SWT per se.
It's just that its concept (being ported from Java as is) is too far from
be a "D window toolkit". It is still Java.
GC in D is not so cheap as in Java. Memory usage pattern shall be
different for sure - Java compacts heap!
D has structures and delete at least. RAII also here.

If you need to create some apllication now and quickly (fire-n-forget)
- go ahead with DWT - it will do job for you.
But for big projects I would think first - at some point of complexity
you will be trapped by Java legacy.
And further evolution of DWT is shady for me to be honest.

>
> Now, I don't have a particular bent one way or another regarding GUI. My interests lie in leveraging the documentation, maturity, and functionality of existing technology. For that purpose, SWT is a viable and attractive solution. Please at least try to get your facts straight in future.

Yep, and you perfectly right. For you personally and at given moment of time
DWT (or DFL or MinWin) is the way to go.
But think first of how you will create something like this:
http://bink.nu/photos/news_article_images/images/10621/500x360.aspx

We (at least myself) here were speaking more about evolution and perspective as "D satndard GUI" implies look in the future too.

Andrew Fedoniouk.
http://terrainformatica.com

"Sean Kelly" <sean@f4.ca> wrote in message news:ds37rt$2ld1$1@digitaldaemon.com...
> Andrew Fedoniouk wrote:
>>
>> I don't understand where this "standard GUI" bright idea comes from. Even Java has no single toolkit: AWT and Swing, SWT plus 3 or 4 more.
>
> Part of that is for historical reasons, as the first model didn't fly so they created a new one.
>
> The advantage to me of having a "standard" toolset (GUI included) is that it allows me to write code that has a pretty reasonable chance of compiling and running with few or no changes on more than one platform. It also makes it a bit less likely that support for these tools will be suddenly dropped a year later in favor of something new (Microsoft being the poster child for such behavior).  As maintenance takes time and money, it's nice to have some assurances.

Let's take a look on (for example) task of creating vector graphic editor:
Like xara[.com] 90% of code deals with graphics only, UI and communication
with OS is pretty much nothing. To port something like this on e.g. Mac
means of porting these 10%. Pure multy OS code in GUI is a myth.
In any case you need to use OS specific stuff if you want your
application to be a good desktop citizen.
Another task: IDE - it may not follow OS UI guidlines - it is even better
if it will look exactly the same on different platforms. This
is different type of UI.
Another type of application: mmm... let's say evernote[.com]
as you may see it uses its own UI at all. But it has a lot of
code under the hood dealing with OS and specific technologies.
E.g. COM and XPCOM for IE/FF/Outlook integration.
So for this type of application multi-platformity of GUI is
10% of the whole task of making port for Mac.

Speaking about reuse of UI code on different platforms
I would consider declarative UI more than anything else.
E.g. if two OS specific frameworks will have same
HTML engine ported then I can define all my stuff
as just HTML and will use HTML event handlers
"as is" there. This will solve at least problems
of dealing with various dialogs or input forms.

Back to business:

UI code reusability is practically feasible if
your GUI foundation consist of modules:

Module Graphics
Module HTML (or something XML based) +
   lightweight OS agnostic widget set.
Module Cocoa Application Framework.
Module Win32 Application Framework.
etc.

But again these are pretty much independent
modules.

E.g, Standard Graphics can be used also in server environments without any UI at all.


>
> But I agree that this isn't always practical, and even with software support guarantees there's no saying the underlying architecture won't change in a way that renders the design meaningless.  I think this is the problem that a slow-moving process like C/C++ standardization faces.
>
>> (I've never seen real application using Swing, btw)
>> In .NET situation is similar: Microsoft is dropping WinForms in favour
>> of Avalon foundation now.
>
> Trust Microsoft to deprecate an API before it's even been released.  I have a sneaking feeling, however, that the face of Windows will change significantly in the next few years.  They've bet the bank on the success of .NET/CLI.

Do you remember 2 years or so ago eiphoria about "next Windows GUI will be in .NET"? And where are they now? Rolled back to native code in Vista. GC/CLI is a good thing for some tasks but not for massive use in GUI.

Andrew.

"U.Baumanis" <U.Baumanis_member@pathlink.com> wrote in message news:ds3id5$2sns$1@digitaldaemon.com...
> In article <ds1j48$1eov$2@digitaldaemon.com>, Walter Bright says...
>>And that's how I feel about D on 16 bit machines. Sometimes it's just time to move on.
>>
> And how you feel about D on 64 bit machines? ;)

That's where things are going.

> I  have a sneaking feeling, however, that the face of Windows will change significantly in the next few years.  They've bet the bank on the success of .NET/CLI.

Yes and I think that was a mistake , its like they're not listening to developers at all.  It seems they're trying to _force_ us into using their technologies by making it the only available option ( C++/CLI looks god awful to me , and C# is a 'too verbose' unportable java )

Microsoft has tried to be everything but a software company , and I for one am looking forward to whats next ( hopefully google OS !).



"Sean Kelly" <sean@f4.ca> wrote in message news:ds37rt$2ld1$1@digitaldaemon.com...
> Andrew Fedoniouk wrote:
> >
> > I don't understand where this "standard GUI" bright idea comes from. Even Java has no single toolkit: AWT and Swing, SWT plus 3 or 4 more.
>
> Part of that is for historical reasons, as the first model didn't fly so they created a new one.
>
> The advantage to me of having a "standard" toolset (GUI included) is
> that it allows me to write code that has a pretty reasonable chance of
> compiling and running with few or no changes on more than one platform.
>   It also makes it a bit less likely that support for these tools will
> be suddenly dropped a year later in favor of something new (Microsoft
> being the poster child for such behavior).  As maintenance takes time
> and money, it's nice to have some assurances.
>
> But I agree that this isn't always practical, and even with software support guarantees there's no saying the underlying architecture won't change in a way that renders the design meaningless.  I think this is the problem that a slow-moving process like C/C++ standardization faces.
>
> > (I've never seen real application using Swing, btw)
> > In .NET situation is similar: Microsoft is dropping WinForms in favour
> > of Avalon foundation now.
>
> Trust Microsoft to deprecate an API before it's even been released.  I have a sneaking feeling, however, that the face of Windows will change significantly in the next few years.  They've bet the bank on the success of .NET/CLI.
>
>
> Sean

> SWT is a part of eclipse application framework (namespace org.eclipse.swt)
> and I have never seen it being used alone outside of Eclipse.
> Standalone version of SWT does exist but if anyone point finger
> on application or project using it I would appreciate it a lot.

Broad statements like this are just asking for trouble :).

http://www.rssowl.org/
http://azureus.sourceforge.net/
http://panoptesmgmt.sourceforge.net/
http://sancho-gui.sourceforge.net/

And there are quite alot of books about it as well.

http://www.amazon.com/exec/obidos/search-handle-url/ref=br_ss_hs/103-0362120 -4087815?platform=gurupa&url=index%3Dstripbooks%3Arelevance-above%26dispatch %3Dsearch%26results-process%3Dbin&field-keywords=swt&Go.x=8&Go.y=8

I think your greatly underestimating SWT.

Out of curiousity, what is your ideal GUI toolkit ?




"Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:ds3j6u$2th3$1@digitaldaemon.com...
>
> "kris" <fu@bar.org> wrote in message
news:ds3257$2hp3$1@digitaldaemon.com...
> > Andrew Fedoniouk wrote:
> > [snip]
> >> And this is exactly the purpose AWT serves in Java world.
> >> Swing and SWT were built on top of AWT.
> >> AWT is really the egg.
> >
> > Andrew,
> >
> > It's been crystal clear for a (very) long time that you know absolutely zero about SWT. That's fine, but the FUD you insist on spreading about
it
> > is not (please reread some of your recent posts on this topic). You'd do the NG, and yourself, a big favour if you'd actually do some background
on
> > SWT first.
>
> :)  Mea culpa, this phrase:
> "Swing and SWT were built on top of AWT." is not strictly valid in terms
of
> SWT. Indeed SWT is not built directly on top of AWT.
>
> SWT and AWT use the same architecture.
>
> In AWT there are two to types of UI Componet's : lightweight and
> heavyweight.
> Ligthweight is a windowless component and Heavyweight through peer has
> HWND attached (on Windows).
>
> Each button, editbox, combobox, etc. in AWT is a Heavyweight OS native
> component - it has HWND. Peers for native controls implemented
> as native code in awt.dll.
>
> SWT uses heavyweight HWND based elements.
> JNI (native) part of SWT is more thin than in AWT.
> It contains universal WndProc implementation versus specific WinProcs in
> AWT.
> For each platform OS specific code implemented in Java in SWT.
> In AWT OS specific code implemented inside AWT.dll only.
> Java part of AWT stays the same for all platforms.
>
> Swing: Swing is really built on top of AWT. JFrame and JDialog there
> are the only heavyweight components.
> So to create editable grid from editboxes is feasible there but
> in SWT if you will try to create grid from HWND textboxes
> you will get a problem - Dialogs have physical limitation on number
> of children.
>
> From the Class hierarchy perspective and architecture SWT and AWT are twin-brothers.
>
> I would say SWT is built on top of (or using) AWT *ideology*.
>
> Again, the only principal difference is in where OS specific code is
> located - in JNI or in Java.
> To add support of new OS widget in AWT you need to add code
> in awt.dll and and in SWT you will do it in Java code.
>
> SWT and AWT use the same event dispatching mechanism (in principle) and
> pretty much close with drawing primitives.
> class Graphics (AWT) vs. class GC (SWT) provide the same set of facilities
> in principle.
>
> SWT is a part of eclipse application framework (namespace org.eclipse.swt)
> and I have never seen it being used alone outside of Eclipse.
> Standalone version of SWT does exist but if anyone point finger
> on application or project using it I would appreciate it a lot.
>
> From D imlementation point of view there is no difference between AWT and SWT - all code is in D anyway.
>
> >
> > For example, arguably the biggest controversy regarding SWT is the fact that is does not garbage-collect resources (such as brushes). People
kick
> > and scream about this in Java-land, yet it matches D perfectly (since dtors are not guaranteed). This would be a fine soapbox for you perhaps.
>
> SWT does not have a concept of Brush and Pen.
> Creation of BRUSH and PEN in modern OSes is so lightweight
> that you can create them each time when you need to use them.
>
> Sidenote: Harmonia follows this path too. E.g.
> void gx.Graphics.setPen(color c, int width, PenStyle style =
> PenStyle.SOLID_INSIDE)
> is just a function - no object creation involved.
>
> Fonts are stored in static hash table and never deleted - the same path MS Office uses.
>
> >
> > SWT has /no/ design relationship with AWT. Zero. Instead, it was
designed
> > and written by the ex-SmallTalk team, partly in protest of the serious
AWT
> > (and subsequently Swing) design faults. You should perhaps read the history of it ~ quite fascinating actually, from a political perspective
~
> > there's a link in the dsource DWT forums from a long time ago (but, you wouldn't have seen that either).
>
> Yep, as far as I remember I published links about these wars here too.
>
> >
> > You further make vacuous and wildly unjustified claims about it just not being feasible to translate SWT to D ~ if you've tried, and failed, then that's your problem. If you haven't even tried, then shame on you. I rather suspect the latter. In fact, if I personally have any involvment
in
> > a port of SWT, it will likely be limited to providing a mechanical translator.
>
> Didn't tried to port it as it has not too much sense (for me personally)
> as 1) it uses foreign concepts for D.
> 2) I am pretty fine to work with pure Win32 API if I need to use HWND.
> 3) See below.
>
> >
> > Yes, I'm upset. Your shameful misinformation regarding SWT and a
potential
> > port to D is a notable catalyst. Contrary to your own public opinion,
you
> > clearly do not have superior experience or abilities over the entire SmallTalk group, nor the many capable enthusiasts here.
>
> Again I am not against someone in particular or against DWT -
> it is an excellent project really as SWT per se.
> It's just that its concept (being ported from Java as is) is too far from
> be a "D window toolkit". It is still Java.
> GC in D is not so cheap as in Java. Memory usage pattern shall be
> different for sure - Java compacts heap!
> D has structures and delete at least. RAII also here.
>
> If you need to create some apllication now and quickly (fire-n-forget)
> - go ahead with DWT - it will do job for you.
> But for big projects I would think first - at some point of complexity
> you will be trapped by Java legacy.
> And further evolution of DWT is shady for me to be honest.
>
> >
> > Now, I don't have a particular bent one way or another regarding GUI. My interests lie in leveraging the documentation, maturity, and
functionality
> > of existing technology. For that purpose, SWT is a viable and attractive solution. Please at least try to get your facts straight in future.
>
> Yep, and you perfectly right. For you personally and at given moment of
time
> DWT (or DFL or MinWin) is the way to go.
> But think first of how you will create something like this:
> http://bink.nu/photos/news_article_images/images/10621/500x360.aspx
>
> We (at least myself) here were speaking more about evolution and
perspective
> as "D satndard GUI" implies look in the future too.
>
> Andrew Fedoniouk.
> http://terrainformatica.com
>
>
>
>