www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DWT - standard D gui?

reply "Walter Bright" <newshound digitalmars.com> writes:
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?
Feb 02 2006
next sibling parent Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:

 
 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'm not much of a GUI person either, but I agree with your assessment.


Sean
Feb 02 2006
prev sibling next sibling parent reply "Kris" <fu bar.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote:


 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?


Yes:

* This is surely a good thing in the long run.

* It's refreshing (for me) to see some direction being touted.

* FWIW, here's what the executive-director of the Eclipse Foundation said 
about porting last summer:

<snip>
My view of the licensing issue is pretty simple. A port to another language 
would be a derivative work, and must therefore be licensed under the EPL. 
Assuming that this is acceptable to you, I don't see an issue."

AFAIK, there is no restriction on using "SWT" as an acronym
</snip>


(the EPL is an open license)
Feb 02 2006
parent reply Dave <Dave_member pathlink.com> writes:
In article <drubut$1rs8$1 digitaldaemon.com>, Kris says...

"Walter Bright" <newshound digitalmars.com> wrote:


 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?


Yes:

* This is surely a good thing in the long run.

* It's refreshing (for me) to see some direction being touted.

* FWIW, here's what the executive-director of the Eclipse Foundation said 
about porting last summer:

<snip>
My view of the licensing issue is pretty simple. A port to another language 
would be a derivative work, and must therefore be licensed under the EPL. 
Assuming that this is acceptable to you, I don't see an issue."

AFAIK, there is no restriction on using "SWT" as an acronym
</snip>


(the EPL is an open license)


I looked at the EPL, but it seems predicated toward applications (like Eclipse)
and not libraries (like S/DWT), so it wasn't clear to me what the EPL means to
me as a potential 'closed source' developer who may use DWT to develop an app.

Can you (or anyone) enlighten me on this?

Thanks,

- Dave
Feb 02 2006
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Dave" <Dave_member pathlink.com> wrote in message 
news:druo2h$2366$1 digitaldaemon.com...

 I looked at the EPL, but it seems predicated toward applications (like 
 Eclipse)
 and not libraries (like S/DWT), so it wasn't clear to me what the EPL 
 means to
 me as a potential 'closed source' developer who may use DWT to develop an 
 app.

 Can you (or anyone) enlighten me on this?


Here's the FAQ on the EPL: http://www.eclipse.org/legal/eplfaq.php
Feb 02 2006
parent reply Dave <Dave_member pathlink.com> writes:
In article <drupf1$24at$1 digitaldaemon.com>, Walter Bright says...

"Dave" <Dave_member pathlink.com> wrote in message 
news:druo2h$2366$1 digitaldaemon.com...

 I looked at the EPL, but it seems predicated toward applications (like 
 Eclipse)
 and not libraries (like S/DWT), so it wasn't clear to me what the EPL 
 means to
 me as a potential 'closed source' developer who may use DWT to develop an 
 app.

 Can you (or anyone) enlighten me on this?


Here's the FAQ on the EPL: http://www.eclipse.org/legal/eplfaq.php 


I'm still stumped as to how exactly the EPL would apply to using D/SWT in
proprietary projects, so I sent away to the Eclipse folks for an answer. Some of
the answers in the FAQ seem potentially ambiguous to me - instead of summarizing
what the license actually says on a matter, they refer back to the license! They
do make it clear what you can and can't do with Eclipse and Plugin source code,
but not with something like SWT.

If I ever get a solid reply from them I'll summarize it here.

- Dave
Feb 03 2006
parent Marco <Marco_member pathlink.com> writes:
In article <ds18hc$18sm$1 digitaldaemon.com>, Dave says...

I'm still stumped as to how exactly the EPL would apply to using D/SWT in
proprietary projects, so I sent away to the Eclipse folks for an answer. Some of
the answers in the FAQ seem potentially ambiguous to me - instead of summarizing
what the license actually says on a matter, they refer back to the license! They
do make it clear what you can and can't do with Eclipse and Plugin source code,
but not with something like SWT.


IBM-Rational and boat load of others are selling Eclipse based products (not
just plug-ins) and they don't have to give anyone their value-adding code. It is
not the GPL.
Feb 10 2006
prev sibling next sibling parent reply Brad Anderson <brad dsource.dot.org> writes:
Walter Bright wrote:

[snip]


 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.


[snip]


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


[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? 



tool and make 'SWT in D' or do we use Shawn's hand-translated code and 
make 'DWT' or do we have both (for a little while, at least)?  I haven't 
heard much about Kris's tool recently, and efforts are underway to 
extend DWT's platforms, so I'm not sure myself, just curious.

It would seem to me the translation tool makes a bunch of sense, because 
of the effort involved when SWT 4.6 comes out and we've only begun to 
hand-port DWT from SWT 3.8...

Oh bony-white assed one?  How's the translator looking?

Other than that issue, I'm happy to see some direction (from someone of 
influence) as well, and couldn't agree more with the OP.

BA
Feb 02 2006
parent reply pragma <pragma_member pathlink.com> writes:
In article <drui05$1vfu$1 digitaldaemon.com>, Brad Anderson says...

Walter Bright wrote:

[snip]


 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.


[snip]


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


[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? 



tool and make 'SWT in D' or do we use Shawn's hand-translated code and 
make 'DWT' or do we have both (for a little while, at least)?  I haven't 
heard much about Kris's tool recently, and efforts are underway to 
extend DWT's platforms, so I'm not sure myself, just curious.

It would seem to me the translation tool makes a bunch of sense, because 
of the effort involved when SWT 4.6 comes out and we've only begun to 
hand-port DWT from SWT 3.8...


Not to be redundant, but here's my $0.02:

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


Oh bony-white assed one?  How's the translator looking?


Careful.  After that last thread, the last thing I'd want to do is poke him in
the eye. ;)


Other than that issue, I'm happy to see some direction (from someone of 
influence) as well, and couldn't agree more with the OP.


Seconded.

- Eric Anderton at yahoo
Feb 02 2006
next sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"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.
Feb 02 2006
next sibling parent reply James Dunne <james.jdunne gmail.com> writes:
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.. :)
Feb 02 2006
parent kris <fu bar.org> writes:
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
Feb 02 2006
prev sibling parent reply Dave <Dave_member pathlink.com> writes:
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?
Feb 02 2006
parent "Charles" <noone nowhere.com> writes:
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?
Feb 03 2006
prev sibling parent reply "Kris" <fu bar.com> writes:
"pragma" <pragma_member pathlink.com> wrote ...


tool and make 'SWT in D' or do we use Shawn's hand-translated code and
make 'DWT' or do we have both (for a little while, at least)?  I haven't
heard much about Kris's tool recently, and efforts are underway to
extend DWT's platforms, so I'm not sure myself, just curious.

It would seem to me the translation tool makes a bunch of sense, because
of the effort involved when SWT 4.6 comes out and we've only begun to
hand-port DWT from SWT 3.8...




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?



 Not to be redundant, but here's my $0.02:

 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 that would be great. Shawn and I had discussed it ages ago, but he 
was already on his way. Once you start doing a manual-translation, you 
generally don't feel like starting over.



 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.


Aye. However, it's not necessary to track SWT on a release by release basis. 
I know you're not saying that, but it's just a related point worth noting?



Oh bony-white assed one?  How's the translator looking?


 Careful.  After that last thread, the last thing I'd want to do is poke 
 him in
 the eye. ;)


Heh heh :)

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.



Other than that issue, I'm happy to see some direction (from someone of
influence) as well, and couldn't agree more with the OP.


 Seconded.


And third'd
Feb 02 2006
next sibling parent "Shawn Liu" <shawn666.liu gmail.com> writes:
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.
Feb 03 2006
prev sibling parent reply ZZ <ZZ zz.com> writes:
 
 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
Feb 03 2006
parent reply kris <fu bar.org> writes:
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.
Feb 03 2006
next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
Feb 03 2006
prev sibling parent Marco <Marco_member pathlink.com> writes:
In article <drv9kc$2er2$1 digitaldaemon.com>, kris says...

 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.


Maybe you could publish what you did so others could volunteer to work on it.
I'm sure that there is considerable interest in a Java to D translator.

Is it written in D?
Feb 10 2006
prev sibling next sibling parent reply S. Chancellor <dnewsgr mephit.kicks-ass.org> writes:
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.


On 2006-02-02 16:53:26 -0800, "Walter Bright" <newshound digitalmars.com> said:


 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?
Feb 02 2006
parent Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
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 +/
Feb 02 2006
prev sibling next sibling parent reply Don Clugston <dac nospam.com.au> writes:
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.
Feb 02 2006
parent James Dunne <james.jdunne gmail.com> writes:
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
Feb 03 2006
prev sibling next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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...



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



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


     HTML support is already included, in the current wxD release.
     http://wxd.sourceforge.net/HtmlHelp.png (using native renderer)
Feb 03 2006
parent reply "Craig Black" <cblack ara.com> writes:
Great work!  Thanks so much for your contributions. I'm looking forward to 
OpenGL support.  Maybe I can actually start using D now!

-Craig
Feb 03 2006
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
Feb 03 2006
next sibling parent reply Kyle Furlong <kylefurlong gmail.com> writes:
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?
Feb 03 2006
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
Feb 03 2006
parent reply nick <nick.atamas gmail.com> writes:
Anders F Björklund wrote:

 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


Really? Is it something with which I can help? I have OpenGL and SDL 
experience (http://nick.aelfgar.com/).
Feb 06 2006
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
nick wrote:


 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.


 
 Really? Is it something with which I can help? I have OpenGL and SDL 
 experience (http://nick.aelfgar.com/).


Did you mean with integration to wxWidgets / wxD ? (of OpenGL and SDL)

wxGLCanvas should be all done, just working on wxD 0.04 packaging now.

SDL integration is something like: http://code.technoplaza.net/wx-sdl/


Or with testing the OpenGL and SDL wrappers for D, that I did earlier ?

http://www.algonet.se/~afb/d/

OpenGL 1.2.1 the SGI version plus GLUT, updated SDL 1.2.9 is in the CVS

--anders


PS. The gaming library was http://sourceforge.net/projects/spriteworldx/
     It is using C/C++, so anything involving D is just my local testing.
Feb 06 2006
prev sibling parent reply Mike Parker <aldacron71 yahoo.com> writes:
Kyle Furlong wrote:

 
 This is GREAT news. Cross platform gaming anyone?


Cross-platform game tools, perhaps. wxWidgets for games (or DWT for that 
matter) falls into the realm of overkill.
Feb 03 2006
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Mike Parker wrote:


 This is GREAT news. Cross platform gaming anyone?


 
 Cross-platform game tools, perhaps. wxWidgets for games (or DWT for that 
 matter) falls into the realm of overkill.


Again, that depends on how you define what a game really *is* ?

For making something like an arcade game, you're probably right.


But I would think that this program in the wx "demos" fits:

http://www.wxwidgets.org/apps/forty/forty.htm

--anders
Feb 04 2006
prev sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
 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.


For the terminally curious, I posted the source code at:
http://wxd.sourceforge.net/glcanvas.cpp    (goes in "wxc")
http://wxd.sourceforge.net/GLCanvas.d      (goes in "wx")

You have to modify the Makefiles, and add the wx_gl and GL libs.
It will all be packaged up neatly in wxD 0.04, not to worry...

Have to look up where the OpenGL libraries are, for DMC/DMD.

--anders
Feb 06 2006
prev sibling next sibling parent bobef <bobef lessequal.com> writes:
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?
Feb 03 2006
prev sibling next sibling parent reply Roberto Mariottini <Roberto_member pathlink.com> writes:
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/
Feb 03 2006
parent reply Sebastián E. Peyrott <as7cf yahoo.com> writes:
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
Feb 03 2006
next sibling parent reply Don Clugston <dac nospam.com.au> writes:
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.
Feb 03 2006
parent reply Sebastián E. Peyrott <as7cf yahoo.com> writes:
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.
Feb 03 2006
parent Lars Ivar Igesund <larsivar igesund.net> writes:
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
Feb 03 2006
prev sibling parent reply Trevor Parscal <Trevor_member pathlink.com> writes:
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
Feb 03 2006
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Trevor Parscal" <Trevor_member pathlink.com> wrote in message 
news:ds0b3u$jbs$1 digitaldaemon.com...

 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.


I don't think there is one point - the blocking items for people are 
different. Some seem to be blocked by templates, others by regex, others by 
recls (hi Matthew!), others by gui, others by there's no D book, etc. We 
just have to keep bashing away at this.
Feb 03 2006
parent Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Walter Bright wrote:

 
 I don't think there is one point - the blocking items for people are 
 different. Some seem to be blocked by templates, others by regex, others by 
 recls (hi Matthew!), others by gui, others by there's no D book, etc. We 
 just have to keep bashing away at this. 
 
 


You forgot 'full-featured IDE'. :P


-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to 
be... unnatural."
Feb 06 2006
prev sibling next sibling parent reply "Chris Miller" <chris dprogramming.com> writes:
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.
Feb 03 2006
next sibling parent "Walter Bright" <newshound digitalmars.com> writes:
"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.
Feb 03 2006
prev sibling parent reply "Lynn Allan" <l_d_allan adelphia.net> writes:
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
Feb 03 2006
parent reply Sebastián E. Peyrott <as7cf yahoo.com> writes:
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
Feb 03 2006
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Sebastián E. Peyrott" <as7cf yahoo.com> wrote in message 
news:ds0h70$o63$1 digitaldaemon.com...

 I believe a GUI should not be directly incorporated into the standard 
 library.


It won't be part of phobos, it'll have its own prefix.


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


Choice is attractive, and endosing DWT will not prevent other gui libraries 
from being used in any way. However, having a default gui that comes with 
the language can be very compelling for users. After all, that's why 
languages come with libraries <g>. Sometimes too many options can be a 
detriment, peoples' eyes glaze over and they just move off and use something 
else where the path is more clear.

That seems to happen a lot whenever someone mentions on a n.g. "what gui do 
I use with C++?"
Feb 03 2006
parent reply nick <nick.atamas gmail.com> writes:
Walter Bright wrote:

 Choice is attractive, and endosing DWT will not prevent other gui libraries 
 from being used in any way. However, having a default gui that comes with 
 the language can be very compelling for users....<SNIP>


Two points.

O N E - Choosing the right toolkit
- - - - - - - - - - - - - - - - - -
If users can choose, then the toolkit you select for D as the default is 
going to send a message more than anything else.

I should caution you against DWT/SWT. In addition to reasons outlined by 
Roberto Mariottini SWT will be viewed by many people as a "bad move for 
D", because SWT is a large toolkit that has severe issues. This will 
create a negative image of stagnation and other negative characteristics 
associated with SWT. JFace is even more problematic.

However, if you choose a small, clean toolkit that is rock solid and 
REALLY easy to grasp (the TinyXML of GUI toolkits) you will create a 
positive image: "we have solid code and the future is looking bright". 
There are enthusiasts and open source audience to attract. This GUI 
toolkit may later grow or be replaced (change is inevitable). The key is 
to let people pick up the GUI and run with it (maybe not very far, but 
right away).

T W O - Let's Be systematic
- - - - - - - - - - - - - -
Choosing the right toolkit is a critical decision. I urge you to 
approach it in an systematic manner.

I think that one of the newsgroup readers should be tasked with creating 
an overview of all candidate GUI toolkits for D and otherwise. 
Preferably, someone with GUI experience. Then individuals who consider 
themselves GUI experts can weigh in additional info and suggestions. I 
would be glad to take up this task and welcome any help (I have some gui 
experience). Let us take a week to a week and a half to gather all the 
facts. Then, let's select several candidates, and decide what the cons 
and pros of each are. Only them can we make a proper decision.
Feb 06 2006
next sibling parent Kyle Furlong <kylefurlong gmail.com> writes:
nick wrote:

 Walter Bright wrote:

 Choice is attractive, and endosing DWT will not prevent other gui 
 libraries from being used in any way. However, having a default gui 
 that comes with the language can be very compelling for users....<SNIP>


 
 Two points.
 
 O N E - Choosing the right toolkit
 - - - - - - - - - - - - - - - - - -
 If users can choose, then the toolkit you select for D as the default is 
 going to send a message more than anything else.
 
 I should caution you against DWT/SWT. In addition to reasons outlined by 
 Roberto Mariottini SWT will be viewed by many people as a "bad move for 
 D", because SWT is a large toolkit that has severe issues. This will 
 create a negative image of stagnation and other negative characteristics 
 associated with SWT. JFace is even more problematic.
 
 However, if you choose a small, clean toolkit that is rock solid and 
 REALLY easy to grasp (the TinyXML of GUI toolkits) you will create a 
 positive image: "we have solid code and the future is looking bright". 
 There are enthusiasts and open source audience to attract. This GUI 
 toolkit may later grow or be replaced (change is inevitable). The key is 
 to let people pick up the GUI and run with it (maybe not very far, but 
 right away).
 
 T W O - Let's Be systematic
 - - - - - - - - - - - - - -
 Choosing the right toolkit is a critical decision. I urge you to 
 approach it in an systematic manner.
 
 I think that one of the newsgroup readers should be tasked with creating 
 an overview of all candidate GUI toolkits for D and otherwise. 
 Preferably, someone with GUI experience. Then individuals who consider 
 themselves GUI experts can weigh in additional info and suggestions. I 
 would be glad to take up this task and welcome any help (I have some gui 
 experience). Let us take a week to a week and a half to gather all the 
 facts. Then, let's select several candidates, and decide what the cons 
 and pros of each are. Only them can we make a proper decision.


One of the most lucid posts of the thread. I heartily agree with both 1 and 2.
Feb 06 2006
prev sibling next sibling parent reply Don Clugston <dac nospam.com.au> writes:
nick wrote:

 Walter Bright wrote:
 

 Choice is attractive, and endosing DWT will not prevent other gui 
 libraries from being used in any way. However, having a default gui 
 that comes with the language can be very compelling for users....<SNIP>


 
 
 Two points.
 
 O N E - Choosing the right toolkit
 - - - - - - - - - - - - - - - - - -
 If users can choose, then the toolkit you select for D as the default is 
 going to send a message more than anything else.
 
 I should caution you against DWT/SWT. In addition to reasons outlined by 
 Roberto Mariottini SWT will be viewed by many people as a "bad move for 
 D", because SWT is a large toolkit that has severe issues. This will 
 create a negative image of stagnation and other negative characteristics 
 associated with SWT. JFace is even more problematic.
 
 However, if you choose a small, clean toolkit that is rock solid and 
 REALLY easy to grasp (the TinyXML of GUI toolkits) you will create a 
 positive image: "we have solid code and the future is looking bright". 
 There are enthusiasts and open source audience to attract. This GUI 
 toolkit may later grow or be replaced (change is inevitable). The key is 
 to let people pick up the GUI and run with it (maybe not very far, but 
 right away).
 
 T W O - Let's Be systematic
 - - - - - - - - - - - - - -
 Choosing the right toolkit is a critical decision. I urge you to 
 approach it in an systematic manner.
 
 I think that one of the newsgroup readers should be tasked with creating 
 an overview of all candidate GUI toolkits for D and otherwise. 
 Preferably, someone with GUI experience. Then individuals who consider 
 themselves GUI experts can weigh in additional info and suggestions. I 
 would be glad to take up this task and welcome any help (I have some gui 
 experience). Let us take a week to a week and a half to gather all the 
 facts. Then, let's select several candidates, and decide what the cons 
 and pros of each are. Only them can we make a proper decision.


I agree with both points, and I think that a survey would be extremely 
valuable for the future.
But does such a "small, clean toolkit" exist?
Feb 06 2006
parent reply Micke <dronten gmail.com> writes:
 O N E - Choosing the right toolkit
 - - - - - - - - - - - - - - - - - -
 If users can choose, then the toolkit you select for D as the default is 
 going to send a message more than anything else.
 
 I should caution you against DWT/SWT. In addition to reasons outlined by 
 Roberto Mariottini SWT will be viewed by many people as a "bad move for 
 D", because SWT is a large toolkit that has severe issues. This will 
 create a negative image of stagnation and other negative characteristics 
 associated with SWT. JFace is even more problematic.
 
 However, if you choose a small, clean toolkit that is rock solid and 
 REALLY easy to grasp (the TinyXML of GUI toolkits) you will create a 
 positive image: "we have solid code and the future is looking bright". 
 There are enthusiasts and open source audience to attract. This GUI 
 toolkit may later grow or be replaced (change is inevitable). The key is 
 to let people pick up the GUI and run with it (maybe not very far, but 
 right away).




Some thoughts on cross platform gui toolkits.

QT
To create an gui on QT which you have to do an C wrapper around C++ code
is to much. And QT is huge, both in source and binary size.

SWT
Different backends for it as I understand it.
Mucho problemas to keep that in sync and time consuming.
And it's huge, at least for linux, if it is using gtk.

GTK
It's written in c, easy to use.
There should be a OSX version out there somewhere.
I have written a thin oo layer on top of it in a short time while learning
D. So some dedicated people short do that in no time and if it's working
on one platform it should work on the other platforms as well.
But it is huge and it's not one of the fastest gui library.

All these above are huge, you must ship tons of dll's instead of one small
exe for your new great D program.

FLTK
fltk is very small library in C++, but not the best looking toolkit and 
it lacks some features a powerful toolkit should have. But its great for
static linking, even ns linux.
One idea might be to do a one time fork of the source. Convert all the
backend source from C++ to D, which should be "easy" as they use only C
calls for interacting with win32/xwindows/osx. Then convert all the
widgets from C++ to D while fixing the shortcomings of fltk. Like layout
management and callback/events stuff and use a better D like syntax.


/Micke
Feb 07 2006
next sibling parent Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Micke wrote:

 GTK
 It's written in c, easy to use.
 There should be a OSX version out there somewhere.
 I have written a thin oo layer on top of it in a short time while learning
 D. So some dedicated people short do that in no time and if it's working
 on one platform it should work on the other platforms as well.
 But it is huge and it's not one of the fastest gui library.


This link might interest you: http://dui.sourceforge.net/


-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M 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-- b DI- D+ G e>+++ h>++ !r !y
------END GEEK CODE BLOCK------

Tomasz Stachowiak  /+ a.k.a. h3r3tic +/
Feb 07 2006
prev sibling next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Micke wrote:


 Some thoughts on cross platform gui toolkits.


[...]

 GTK
 It's written in c, easy to use.
 There should be a OSX version out there somewhere.


GTK+ is great, but the Mac OS X support is "behind"...
(the Windows support for it is much more up-to-date)

http://gtk-osx.sourceforge.net/ is still at GTK 1.x,
and I'm not sure how the new GTK 2.x is coming along ?

See http://developer.imendio.com/wiki/Gtk_Mac_OS_X
(works with X11 too, but that doesn't really count)

And it looks pretty alien, even when it does work...
(i.e. both theme and file dialogs are "different")



 I have written a thin oo layer on top of it in a short time while learning
 D. So some dedicated people short do that in no time and if it's working
 on one platform it should work on the other platforms as well.


There is the "difference between theory and practice" aspect.


 But it is huge and it's not one of the fastest gui library.


It's good for Linux. Just not "optimal" for Windows/Mac OS X.

--anders

PS. wxD uses wxGTK on Linux...
Feb 07 2006
prev sibling parent reply nick <nick.atamas gmail.com> writes:
Micke wrote:

 Some thoughts on cross platform gui toolkits.
 
 <SNIP>
 
 /Micke


Thanks for the input, Micke.

Here is a listing of GUI toolkits(it's been around for a while); it 
isn't up to date, but you should get people started.

http://www.geocities.com/SiliconValley/Vista/7184/guitool.html

P.S. Should we, maybe start a new thread? This one is getting kind of long.
Feb 07 2006
parent Micke <dronten gmail.com> writes:
 
 Thanks for the input, Micke.
 
 Here is a listing of GUI toolkits(it's been around for a while); it 
 isn't up to date, but you should get people started.
 
 http://www.geocities.com/SiliconValley/Vista/7184/guitool.html
 
 P.S. Should we, maybe start a new thread? This one is getting kind of long.


Yeah, I have followed that list for a few years now.
Unfortunately there is a shortage of mature portable C libraries that are
maintained.
GTK works, but the api and complexity sucks (my opinion).
But as mono is using it, it should have a somewhat bright future after all.
Feb 07 2006
prev sibling next sibling parent reply "Charles" <noone nowhere.com> writes:
 because SWT is a large toolkit that has severe issues.


What issues ?




"nick" <nick.atamas gmail.com> wrote in message
news:ds7542$2fvm$1 digitaldaemon.com...

 Walter Bright wrote:

 Choice is attractive, and endosing DWT will not prevent other gui




libraries

 from being used in any way. However, having a default gui that comes




with

 the language can be very compelling for users....<SNIP>


 Two points.

 O N E - Choosing the right toolkit
 - - - - - - - - - - - - - - - - - -
 If users can choose, then the toolkit you select for D as the default is
 going to send a message more than anything else.

 I should caution you against DWT/SWT. In addition to reasons outlined by
 Roberto Mariottini SWT will be viewed by many people as a "bad move for
 D", because SWT is a large toolkit that has severe issues. This will
 create a negative image of stagnation and other negative characteristics
 associated with SWT. JFace is even more problematic.

 However, if you choose a small, clean toolkit that is rock solid and
 REALLY easy to grasp (the TinyXML of GUI toolkits) you will create a
 positive image: "we have solid code and the future is looking bright".
 There are enthusiasts and open source audience to attract. This GUI
 toolkit may later grow or be replaced (change is inevitable). The key is
 to let people pick up the GUI and run with it (maybe not very far, but
 right away).

 T W O - Let's Be systematic
 - - - - - - - - - - - - - -
 Choosing the right toolkit is a critical decision. I urge you to
 approach it in an systematic manner.

 I think that one of the newsgroup readers should be tasked with creating
 an overview of all candidate GUI toolkits for D and otherwise.
 Preferably, someone with GUI experience. Then individuals who consider
 themselves GUI experts can weigh in additional info and suggestions. I
 would be glad to take up this task and welcome any help (I have some gui
 experience). Let us take a week to a week and a half to gather all the
 facts. Then, let's select several candidates, and decide what the cons
 and pros of each are. Only them can we make a proper decision.
Feb 06 2006
next sibling parent reply nick <nick.atamas gmail.com> writes:
Charles wrote:

 because SWT is a large toolkit that has severe issues.


 
 What issues ?


(Brief reply, gotta go to work)

There are many if you google for them. In short, their class hierarchy 
is poorly designed. Since that's what we'd be borrowing from them, I 
view that as a pretty bad move.

Also, the various SWT implementations don't always work well. Finally, 
since the core of SWT is in C, you can make it crass REALLY bad. Running 
a while(1) System.out.print("."); in an SWT thread can cause a BSOD on 
windows.

The SWT layout engine isn't bad, but it isn't fantastic either.
.
.
.
But this is just me rambling. These sort of issues need to be itemized 
and presented in an organized fashion.
Feb 06 2006
parent "Kris" <fu bar.com> writes:
"nick" <nick.atamas gmail.com> wrote ...

 There are many if you google for them. In short, their class hierarchy is 
 poorly designed. Since that's what we'd be borrowing from them, I view 
 that as a pretty bad move.


That's a bit nebulous, Nick. Can you be specific as to exactly what is so 
bad?



 Also, the various SWT implementations don't always work well.


Really? Can you be just a bit more specific?



Finally, since the core of SWT is in C, you can make it crass REALLY bad.


The core of SWT is written in C? Are you quite, quite sure?



 The SWT layout engine isn't bad, but it isn't fantastic either.


I see. Perhaps you could qualify that also? The statement just seems a bit, 
empty?



 But this is just me rambling. These sort of issues need to be itemized and 
 presented in an organized fashion.


Yes, they should. It seems you have a strong opinion on the matter and, 
judging by the above assertions, would appear to be /very/ knowledgable 
about SWT. It would be helpful if you could back up your points with 
concrete evidence and examples.
Feb 06 2006
prev sibling parent reply nick <nick.atamas gmail.com> writes:
Oh, and: http://www.hacknot.info/hacknot/action/showEntry?eid=74

those issues too.
Feb 06 2006
next sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"nick" <nick.atamas gmail.com> wrote in message 
news:ds7un0$6va$1 digitaldaemon.com...

 Oh, and: http://www.hacknot.info/hacknot/action/showEntry?eid=74

 those issues too.


Thanks for the pointer. One issue stood out for me - that Swing is 7 years 
ahead of SWT. This reiterates my belief that if D tries to develop our own 
gui, it will take 10 years. We don't have 10 years to do it. An existing one 
has to be used.
Feb 06 2006
parent reply Roberto Mariottini <Roberto_member pathlink.com> writes:
In article <ds88k3$fho$1 digitaldaemon.com>, Walter Bright says...

One issue stood out for me - that Swing is 7 years 
ahead of SWT. This reiterates my belief that if D tries to develop our own 
gui, it will take 10 years. We don't have 10 years to do it. An existing one 
has to be used. 


So starting from Swing you'll be 7 years ahead ;-)

I've had another idea: let's get both. Don't get me wrong: they are already-made
libraries, the task to port them can be made once for each.

The fact is that Swing is completely software made: this permits its high
portability. To port Swing you need only a few system-dependent objects:

- a set of Graphics drawing primitives
- a set of Font primitives
- the two root widget Window and Frame

Nearly all the rest is embedded in Swing itself.
I think DWT can be a perfect source for thoose few classes.
Then the user can choose: the high portability of Swing or the high performance
of DWT, the higher user-based and bug-fixed Swing or the latest whistles and
bells on DWT.

Note also that porting Swing to another platform means implementing only the
little DWT part that Swing needs. Porting DWT can be done as a later step.

Ciao

---
http://www.mariottini.net/roberto/
Feb 07 2006
parent "Walter Bright" <newshound digitalmars.com> writes:
"Roberto Mariottini" <Roberto_member pathlink.com> wrote in message 
news:ds9l6u$1jjq$1 digitaldaemon.com...

 In article <ds88k3$fho$1 digitaldaemon.com>, Walter Bright says...

One issue stood out for me - that Swing is 7 years
ahead of SWT. This reiterates my belief that if D tries to develop our own
gui, it will take 10 years. We don't have 10 years to do it. An existing 
one
has to be used.


 So starting from Swing you'll be 7 years ahead ;-)


Isn't Swing tightly controlled by Sun? Anyone have a copy of the license for 
it?
Feb 07 2006
prev sibling next sibling parent reply Dave <Dave_member pathlink.com> writes:
In article <ds7un0$6va$1 digitaldaemon.com>, nick says...

Oh, and: http://www.hacknot.info/hacknot/action/showEntry?eid=74

those issues too.


You do raise some good points. Nick, I nominate you to lead this effort, if you
have the time. A couple of things I'd like to add though (all IMHO of course):

- License: Assuming the lib. itself is OSS of some form, most importantly it
will allow developers to use the D version of the lib. commercially w/o posting
their own code.

- Ease of use 'out of the box': Is vital - far and away the most important thing
for a D GUI lib. to get accepted and *used* by the great majority of developers.

After the initial selections are made, as part of the overall eval., I think
someone should develop an app. for each that opens a window with a button that
would display "Hello World" 10 times in a (rich) text box. Simplistic? Yes, but
half the battle is convincing people to use the library, and most of those
people will start out with an app. just that simple.

For example, considering D's 'style' the ideal would be something like this for
me:

import D.gui;
Form f;
Button b;
TextBox t;
void main()
{
f = new Form(0,0,300,300); // default modal,x,y,w,h
b = new Button(f,"Click Me",8,8,75,23); // parent,caption,x,y,w,h
b.Click = &buttonb_onclick;
t = new TextBox(f,88,8,192,248,true); // parent,x,y,w,h,multi-line
f.Show;
}
void buttonb_onclick(EventInfo* e)
{
for(int i = 0; i < 10; i++)
t += "Hello World\n";
}

Just so we can look at the various development 'styles' represented by each.

I'd be happy to help with this *if* I'm not swamped at work when you are ready.

- IDEbility: Is that a word? The lib. we choose should be comparitively easy for
'visual' IDE's to manage the code, needing nothing but legal D code (plus
'anchor' comments) for the majority of uses. The above example shows a 'style'
lending itself to that too, I think.

- Performance: Not real important (imagine me saying that!), as long as it isn't
a total dog, and the overall winner should have a desing that avoids 'object
churn' for larger projects. From what I understand, SWT was originally developed
as an answer to basically one thing: object churn.

I (and I think others) don't want a toolkit where the choice was made biased
toward game programmers just because it includes a great graphics engine at it's
core. The game specific stuff can (and probably should) come from a different
library.

- Dave
Feb 06 2006
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Dave wrote:


 After the initial selections are made, as part of the overall eval., I think
 someone should develop an app. for each that opens a window with a button that
 would display "Hello World" 10 times in a (rich) text box. Simplistic? Yes, but
 half the battle is convincing people to use the library, and most of those
 people will start out with an app. just that simple.
 
 For example, considering D's 'style' the ideal would be something like this for
 me:
 
 import D.gui;
 Form f;
 Button b;
 TextBox t;
 void main()
 {
 f = new Form(0,0,300,300); // default modal,x,y,w,h
 b = new Button(f,"Click Me",8,8,75,23); // parent,caption,x,y,w,h
 b.Click = &buttonb_onclick;
 t = new TextBox(f,88,8,192,248,true); // parent,x,y,w,h,multi-line
 f.Show;
 }
 void buttonb_onclick(EventInfo* e)
 {
 for(int i = 0; i < 10; i++)
 t += "Hello World\n";
 }
 
 Just so we can look at the various development 'styles' represented by each.


Here is one (real-life, working) example:
http://wxd.sourceforge.net/Minimal.html

Could modify it into the above, later...
(for comparison with the other libraries)

--anders
Feb 07 2006
prev sibling parent reply "Shawn Liu" <shawn666.liu gmail.com> writes:
"nick" <nick.atamas gmail.com> says:ds7un0$6va$1 digitaldaemon.com...

 Oh, and: http://www.hacknot.info/hacknot/action/showEntry?eid=74

 those issues too.



Since Swing is older than SWT, it is stable and less bug than SWT. For such
a big and rapidly progressing project, Eclipse/SWT can not avoid bugs. But
nowadays SWT seems stable and feature rich than ever, because the support of
many heavyweight companies in the industry. The excellent architecture of 
Eclipse/
SWT/RCP/GEF has attractted more and more programmers to pursue. With the
fast spread of Eclipse, the documents and third part Widgets will become 
more available.

The author said that "just because SWT is the technically inferior solution
doesn't mean that it will go away. Hype, marketing, vendor over-enthusiasm
and managerial stupidity can propel a second-rate solution to prominence. "

But let's see the success of Eclipse/SWT:
http://www.macromedia.com/macromedia/proom/pr/2005/eclipse_flashplatform.html
http://press.nokia.com/PR/200406/950657_5.html
http://www.symbian.com/news/pr/2005/pr20053158.html
http://www.borland.com/us/company/news/press_releases/2005/02_28_05_borland_amplifies_eclipse_support.html
http://www.bea.com/framework.jsp?CNT=pr01421.htm&FP=/content/news_events/press_releases/2005
http://www.sybase.com/detail?id=1034627
http://www3.ca.com/Press/PressRelease.aspx?CID=65460

and more ...
http://www.eclipse.org/membership/

It seem that this will never happen to NetBeans nor SWING.

Why all those companies support that technically inferior solution?
Feb 07 2006
next sibling parent reply "Shawn Liu" <shawn666.liu gmail.com> writes:
"Shawn Liu" <shawn666.liu gmail.com> says:dsa3hu$207a$1 digitaldaemon.com...

 "nick" <nick.atamas gmail.com> says:ds7un0$6va$1 digitaldaemon.com...

 Oh, and: http://www.hacknot.info/hacknot/action/showEntry?eid=74

 those issues too.




Some story about SWING and SWT
http://www.mail-archive.com/jug-discussion tucson-jug.org/msg00355.html
Feb 07 2006
parent U.Baumanis <U.Baumanis_member pathlink.com> writes:
In article <dsa46m$20mk$1 digitaldaemon.com>, Shawn Liu says...

"Shawn Liu" <shawn666.liu gmail.com> says:dsa3hu$207a$1 digitaldaemon.com...

Some story about SWING and SWT
http://www.mail-archive.com/jug-discussion tucson-jug.org/msg00355.html 


Ye, but look when this story was written! in 2002!
Swing has dramatically changed in these 4 years.
And it is used much more widely than SWT.
It would be realy nice to have Swing like GUI lib in D! :)
(I am java developer, using Swing extensivelly)

--
ub
Feb 07 2006
prev sibling parent Sean Kelly <sean f4.ca> writes:
Shawn Liu wrote:

 
 Why all those companies support that technically inferior solution?


Why did Linux get so much support with FreeBSD around?  Technical merit 
isn't always the deal-breaker.


Sean
Feb 07 2006
prev sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"nick" <nick.atamas gmail.com> wrote in message 
news:ds7542$2fvm$1 digitaldaemon.com...

 I should caution you against DWT/SWT. In addition to reasons outlined by 
 Roberto Mariottini SWT will be viewed by many people as a "bad move for 
 D", because SWT is a large toolkit that has severe issues. This will 
 create a negative image of stagnation and other negative characteristics 
 associated with SWT. JFace is even more problematic.


The problem is, I've heard such strongly negative comments about every GUI 
toolkit out there.
Feb 06 2006
next sibling parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:ds83p6$bmf$3 digitaldaemon.com...

 "nick" <nick.atamas gmail.com> wrote in message 
 news:ds7542$2fvm$1 digitaldaemon.com...

 I should caution you against DWT/SWT. In addition to reasons outlined by 
 Roberto Mariottini SWT will be viewed by many people as a "bad move for 
 D", because SWT is a large toolkit that has severe issues. This will 
 create a negative image of stagnation and other negative characteristics 
 associated with SWT. JFace is even more problematic.


 The problem is, I've heard such strongly negative comments about every GUI 
 toolkit out there.


The reason is simple: people have different requirements for their tasks.
For someone DFL is the best so other toolkits are just garbage. And so on.

No one *toolkit* can serve "Standard D GUI" purposes as each toolkit
is dedicated to be a solution for some task or pretty narrow group of tasks.

E.g. someone needs OpenGL and for him either DFL or DWT is just nothing.

As I mentioned before: task of creation of "Standard D GUI" is conceptually
different from creation of a "toolkit". (looks like words game but anyway)

Conceptually:
"Standard D GUI" is a set of modules. Concrete set of particular
modules is a toolkit.

For example "Arcade Game UI Toolkit" is a set of :
   Standard Graphics Module( using OpenGL "surface" for example ),
   Standard Application Module,
   Standard Windowless Widget Set Module,
   Game specific modules.

"IDE Toolkit" is a set of :
   Standard Graphics Module( using basic "surface" ),
   Standard Application Module,
   Standard Windowed Widget Set Module (may be yes or may be no),
   Document/View Module, Plugins Module, etc.

Andrew.
Feb 06 2006
prev sibling parent reply nick <nick_member pathlink.com> writes:
In article <ds83p6$bmf$3 digitaldaemon.com>, Walter Bright says...

"nick" <nick.atamas gmail.com> wrote in message 
news:ds7542$2fvm$1 digitaldaemon.com...

 I should caution you against DWT/SWT. In addition to reasons outlined by 
 Roberto Mariottini SWT will be viewed by many people as a "bad move for 
 D", because SWT is a large toolkit that has severe issues. This will 
 create a negative image of stagnation and other negative characteristics 
 associated with SWT. JFace is even more problematic.


The problem is, I've heard such strongly negative comments about every GUI 
toolkit out there. 


Agreed. They all have issues. However, "no gui toolkit" may be better than SWT. 

If I had to pick a toolkit to port right off the top of my head, I would choose
QT.

Problem: QT vs SWT
------------------
When you google for QT problems you find bugs and people making mistakes while
learning. When you google for SWT problems, you find pages of experts mentioning
SWT design flaws. QT has a prooven track record of being used by commercial
entities whereas SWT has only a small number of applications all of which have
major issues. Why? Because SWT was built to build the Eclipse IDE. When you try
to use it, you always get an eclipse-IDE as a result, even if that's not what
you intended. You can't grow SWT because it's too compelx and broken, so you are
stuck. (All the classes come with a commet: DO NOT EXTEND THIS OR YOU WILL BREAK
THINGS.)
Many people have praised QT as being the best UI toolkit they have ever used. It
definitely has its problems, but moving QT from C++ to D would fix a lot of
them.

Memory: QT vs SWT
------------------
As far as language is concerned, QT and SWT use very similar memory managing
models (everything is allocated in the constructor dynamically and freed in the
destructor; you end up with a tree where every parent widget keeps track of
memory for all its children). That's right, SWT is not _really_ garbage
collected; it calls dispose.


Problem: QT vs SWT
------------------
So, my suggestion:
You aren't a GUI expert. I have GUI experience. The people at trolltech are GUI
*EXPERTS*. Furthermore, they have an Open Source evangelist. If we don't know
what we are doing, let's at least ask someone who really does -
http://www.trolltech.com/developer/scottcollins.html.

Who knows what will happen? It is possible that, with a more or less stable D,
the next iteration of QT will come with D bindings. At the very least, we can
learn things from Scott Collins. It may very well be the case that mimicking QT
is going to be easier than SWT.

My lunch break is almost over, but I would be glad to provide a more concrete
argument with specific details when I get home.
Feb 06 2006
next sibling parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
"nick" <nick_member pathlink.com> wrote in message 
news:ds8f77$mvh$1 digitaldaemon.com...


 Problem: QT vs SWT


[skiped]

Agree.

QT is good as does GNOME btw.

But these are, as they say widget toolkits.
They implement everything by hand - every
combobox, editbox, etc. is implemented in QT code.
The same approach uses Swing. And there are pluses and minuses of
this approach. E.g. native OS look-n-feel is a huge task there.
But again for some applications this is not bad at all.

<quote src="http://en.wikipedia.org/wiki/Qt_toolkit#Design">

Complete abstraction of the GUI

Qt uses its own paint engine and controls. It emulates the look of the 
different platforms it runs on. This made the porting work easier because 
very few classes in Qt depended really on the target platform. The drawback 
is that Qt had to emulate precisely the look of the different platforms. 
This drawback however no longer applies because the latest versions of Qt 
use the native styles API of the different platforms to draw the Qt 
controls.

Other portable graphical toolkits have made a different design decision, 
such as wxWidgets, MFC (Windows only), and the Java based SWT[2] which use 
the toolkit of the target platform for their implementation.

</quote>

Sidenote: Harmonia uses same approach and it is "natively D" from the very
    beginning, btw. It has own widgets:
    http://www.terrainformatica.com/harmonia/screenshots/harmonia.png
    But I am not proposing Harmonia to be a "Standard GUI toolkit"
    for the simple reason - it is not a toolkit for general use by 
definition.
    Harmonia implements only one particular paradigm - OS independent
    windowless toolkit( you may think about it as about micro-QT if you 
wish.)
    But there are many cases when you would like to use OS widgets -
    for example html browser (IE or Gecko) widgets.

Andrew Fedoniouk.
http://terrainformatica.com
Feb 06 2006
prev sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"nick" <nick_member pathlink.com> wrote in message 
news:ds8f77$mvh$1 digitaldaemon.com...

 If I had to pick a toolkit to port right off the top of my head, I would 
 choose QT.


QT cannot be used because it's a proprietary, non-free product.
Feb 06 2006
next sibling parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:ds8lvv$s2k$2 digitaldaemon.com...

 QT cannot be used because it's a proprietary, non-free product.


Yep, and yet:
http://discuss.joelonsoftware.com/default.asp?joel.3.219431.12 :)
Feb 06 2006
parent nick <nick_member pathlink.com> writes:
In article <ds8n8h$t0a$1 digitaldaemon.com>, Andrew Fedoniouk says...

"Walter Bright" <newshound digitalmars.com> wrote in message 
news:ds8lvv$s2k$2 digitaldaemon.com...

 QT cannot be used because it's a proprietary, non-free product.


Yep, and yet:
http://discuss.joelonsoftware.com/default.asp?joel.3.219431.12 :) 


SWTs problems are slightly different, although that's a pretty good assessment
of the Java API. It tries to be too modular. It's fine to be modular, too
abstract, a factory for building blueprints of factories that builds factories
for hammer.  It's fine to be that modular, as long as you provide an
easy-to-grasp API that people can just start using. Java doesn't do that, one
really bad example is the secure sockets in Java 5.
Feb 06 2006
prev sibling parent reply nick <nick_member pathlink.com> writes:
In article <ds8lvv$s2k$2 digitaldaemon.com>, Walter Bright says...

"nick" <nick_member pathlink.com> wrote in message 
news:ds8f77$mvh$1 digitaldaemon.com...

 If I had to pick a toolkit to port right off the top of my head, I would 
 choose QT.


QT cannot be used because it's a proprietary, non-free product. 


QT is an open source product. It is only proprietary if you plan to use it for
proprietary means. KDE is based on QT from ground up.

The very least we can do, is ask advice from Scott; he would gladly help an open
source initiative.
Feb 06 2006
next sibling parent reply Sean Kelly <sean f4.ca> writes:
nick wrote:

 In article <ds8lvv$s2k$2 digitaldaemon.com>, Walter Bright says...

 "nick" <nick_member pathlink.com> wrote in message 
 news:ds8f77$mvh$1 digitaldaemon.com...

 If I had to pick a toolkit to port right off the top of my head, I would 
 choose QT.


 QT cannot be used because it's a proprietary, non-free product. 


 QT is an open source product. It is only proprietary if you plan to use it for
 proprietary means. KDE is based on QT from ground up.
 
 The very least we can do, is ask advice from Scott; he would gladly help an
open
 source initiative.


The problem is that while the D libraries are open source, not all 
applications using D will be.  Given the viral nature of open-source 
licenses, I think this would prevent Qt from being used in such a 
project, no?


Sean
Feb 06 2006
next sibling parent reply nick <nick_member pathlink.com> writes:
In article <ds8tqr$11ti$1 digitaldaemon.com>, Sean Kelly says...

nick wrote:

 In article <ds8lvv$s2k$2 digitaldaemon.com>, Walter Bright says...

 "nick" <nick_member pathlink.com> wrote in message 
 news:ds8f77$mvh$1 digitaldaemon.com...

 If I had to pick a toolkit to port right off the top of my head, I would 
 choose QT.


 QT cannot be used because it's a proprietary, non-free product. 


 QT is an open source product. It is only proprietary if you plan to use it for
 proprietary means. KDE is based on QT from ground up.
 
 The very least we can do, is ask advice from Scott; he would gladly help an
open
 source initiative.


The problem is that while the D libraries are open source, not all 
applications using D will be.  Given the viral nature of open-source 
licenses, I think this would prevent Qt from being used in such a 
project, no?


I really don't see what the problem is. If by some miracle we convince trolltech
to write d bindings/a d port, anyone will be free to write software using that
tech as long as they open source it. If you plan to make money, you have to pay
a fee. That doesn't seem like a problem to me.

And I keep saying this "Let's present our dilemma to Scott Collins and ask him
for an opinion". As far as I know, he is a GUI expert and will help open source
ideas as well as licensing issues. D is a largely open source project. I just
think that perhaps Walter should be the one to ask. I would do it, but that
would be going over Walter's head.


Sean
Feb 06 2006
next sibling parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
"nick" <nick_member pathlink.com> wrote in message 
news:ds8v5t$12sr$1 digitaldaemon.com...

 I really don't see what the problem is. If by some miracle we convince 
 trolltech
 to write d bindings/a d port, anyone will be free to write software using 
 that
 tech as long as they open source it. If you plan to make money, you have 
 to pay
 a fee. That doesn't seem like a problem to me.

 And I keep saying this "Let's present our dilemma to Scott Collins and ask 
 him
 for an opinion". As far as I know, he is a GUI expert and will help open 
 source
 ideas as well as licensing issues. D is a largely open source project. I 
 just
 think that perhaps Walter should be the one to ask. I would do it, but 
 that
 would be going over Walter's head.


I think that porting of such huge thing is not feasible at all at current 
stage.
Automatic conversion is not possible especially in the light
of their own preprocessor for SINGNAL/SLOT code generation.
And benefits are doubtfull for small applications like notepad.exe
notepad.exe implementation in pure Win32 API is one file - not more.

If someone needs QT style UI/Application in D he can use
Harmonia even in its(her) current state.

Andrew.
Feb 06 2006
prev sibling next sibling parent Sean Kelly <sean f4.ca> writes:
nick wrote:

 In article <ds8tqr$11ti$1 digitaldaemon.com>, Sean Kelly says...

 nick wrote:

 In article <ds8lvv$s2k$2 digitaldaemon.com>, Walter Bright says...

 "nick" <nick_member pathlink.com> wrote in message 
 news:ds8f77$mvh$1 digitaldaemon.com...

 If I had to pick a toolkit to port right off the top of my head, I would 
 choose QT.


 QT cannot be used because it's a proprietary, non-free product. 


 QT is an open source product. It is only proprietary if you plan to use it for
 proprietary means. KDE is based on QT from ground up.

 The very least we can do, is ask advice from Scott; he would gladly help an
open
 source initiative.


 The problem is that while the D libraries are open source, not all 
 applications using D will be.  Given the viral nature of open-source 
 licenses, I think this would prevent Qt from being used in such a 
 project, no?


 
 I really don't see what the problem is. If by some miracle we convince
trolltech
 to write d bindings/a d port, anyone will be free to write software using that
 tech as long as they open source it. If you plan to make money, you have to pay
 a fee. That doesn't seem like a problem to me.


So suppose Qt becomes the standard GUI interface through 1.0.  Joe 
decides to write an app using standard D tools and he doesn't want to 
open source it for whatever reason.  You're saying he would have to pay 
Trolltech a fee for doing so?  For using a standard library tool? 
Frankly, if someone tried to convince me to use a language whose 
standard library had such "hidden fees" I'd laugh at them.  The only 
alternative I'd consider is if the licensing fee could be built into the 
cost of the compiler or standard library distribution, and then only if 
the amount were eminently reasonable (say no more than $50).


 And I keep saying this "Let's present our dilemma to Scott Collins and ask him
 for an opinion". As far as I know, he is a GUI expert and will help open source
 ideas as well as licensing issues. D is a largely open source project. I just
 think that perhaps Walter should be the one to ask. I would do it, but that
 would be going over Walter's head.


You could phrase things in such a way so as not to assume any authority 
over the situation.  As long as it's clear you're not speaking for 
Walter I don't see any problem with asking.


Sean
Feb 06 2006
prev sibling parent "Walter Bright" <newshound digitalmars.com> writes:
"nick" <nick_member pathlink.com> wrote in message 
news:ds8v5t$12sr$1 digitaldaemon.com...

 And I keep saying this "Let's present our dilemma to Scott Collins and ask 
 him
 for an opinion". As far as I know, he is a GUI expert and will help open 
 source
 ideas as well as licensing issues. D is a largely open source project. I 
 just
 think that perhaps Walter should be the one to ask. I would do it, but 
 that
 would be going over Walter's head.


Feel free to ask him. If he's willing to allow a Qt in D for open source, 
free commercial use, then that removes a fatal obstacle for making it a 
standard part of D.
Feb 06 2006
prev sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Sean Kelly" <sean f4.ca> wrote in message 
news:ds8tqr$11ti$1 digitaldaemon.com...

 The problem is that while the D libraries are open source, not all 
 applications using D will be.  Given the viral nature of open-source 
 licenses, I think this would prevent Qt from being used in such a project, 
 no?


That's right. A *standard* component of D needs to be usable by commercial 
projects without needing to pay license fees. That would be no problem if Qt 
were optional, but if it was standard it would impede the adoption of D.
Feb 06 2006
parent reply nick <nick.atamas gmail.com> writes:
Walter Bright wrote:

 "Sean Kelly" <sean f4.ca> wrote in message 
 news:ds8tqr$11ti$1 digitaldaemon.com...

 The problem is that while the D libraries are open source, not all 
 applications using D will be.  Given the viral nature of open-source 
 licenses, I think this would prevent Qt from being used in such a project, 
 no?


 
 That's right. A *standard* component of D needs to be usable by commercial 
 projects without needing to pay license fees. That would be no problem if Qt 
 were optional, but if it was standard it would impede the adoption of D. 


I made several rush posts from work, and I want to take this post to 
remove any ambiguity.


I am biased against it, but I know it well enough to say that this: 
<http://www.hacknot.info/hacknot/action/showEntry?eid=74> is all true. 
AWT and Swing really aren't much better.

QT is amazing, and people love it, but we can't use it. Now that I have 
Walter's blessing, I will attempt to contact Scott and ask him for 
guidance in this matter. I will also gather info on existing options. 
The least we will get out of this is a good picture of where things stand.
Feb 06 2006
next sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"nick" <nick.atamas gmail.com> wrote in message 
news:ds9bg6$1bto$1 digitaldaemon.com...

 I made several rush posts from work, and I want to take this post to 
 remove any ambiguity.


 am biased against it, but I know it well enough to say that this: 
 <http://www.hacknot.info/hacknot/action/showEntry?eid=74> is all true. AWT 
 and Swing really aren't much better.


Keep in mind, though, that AWT despite its flaws is what got Java off the 
ground and kept it going for the initial few years. (I don't think AWT or 
Swing are contenders for D because of Sun licensing issues.)


 QT is amazing, and people love it, but we can't use it. Now that I have 
 Walter's blessing, I will attempt to contact Scott and ask him for 
 guidance in this matter. I will also gather info on existing options. The 
 least we will get out of this is a good picture of where things stand.


Yes, and thanks for doing this. A free D version of QT can benefit QT by 
building its brand and market momentum.
Feb 07 2006
parent reply Roberto Mariottini <Roberto_member pathlink.com> writes:
In article <ds9kot$1j45$1 digitaldaemon.com>, Walter Bright says...


[...]

Keep in mind, though, that AWT despite its flaws is what got Java off the 
ground and kept it going for the initial few years.


I completely disagree. I used Java from the beginning, and I can remember for
sure that Java was nearly dead because of AWT. I remember the "Corel Office for
Java" thing very well. Swing was the right choice, making Java exit the niche of
server-side applications.


(I don't think AWT or 
Swing are contenders for D because of Sun licensing issues.)


I hate to repeat myself, but there is a free Swing available at
www.classpath.org.

Ciao

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



 Feb 07 2006



 next sibling parent reply David Medlock <noone nowhere.com>  writes:


Roberto Mariottini wrote:

 In article <ds9kot$1j45$1 digitaldaemon.com>, Walter Bright says...
 


 [...]
 

Keep in mind, though, that AWT despite its flaws is what got Java off the 
ground and kept it going for the initial few years.


 
 
 I completely disagree. I used Java from the beginning, and I can remember for
 sure that Java was nearly dead because of AWT. I remember the "Corel Office for
 Java" thing very well. Swing was the right choice, making Java exit the niche
of
 server-side applications.
 
 

(I don't think AWT or 
Swing are contenders for D because of Sun licensing issues.)


 
 
 I hate to repeat myself, but there is a free Swing available at
 www.classpath.org.
 
 Ciao
 
 ---
 http://www.mariottini.net/roberto/


Isn't that GPL?
I vote lets not force any D developers into (L)GPL type licensing 
issues.  That type of 'freedom' discourages commercial use (despite what 
the pundits say).

-DavidM



 Feb 07 2006



 next sibling parent  pragma <pragma_member pathlink.com>  writes:


In article <dsacvp$28v0$1 digitaldaemon.com>, David Medlock says...

Roberto Mariottini wrote:

 In article <ds9kot$1j45$1 digitaldaemon.com>, Walter Bright says...
 


 [...]
 

Keep in mind, though, that AWT despite its flaws is what got Java off the 
ground and kept it going for the initial few years.


 
 
 I completely disagree. I used Java from the beginning, and I can remember for
 sure that Java was nearly dead because of AWT. I remember the "Corel Office for
 Java" thing very well. Swing was the right choice, making Java exit the niche
of
 server-side applications.
 
 

(I don't think AWT or 
Swing are contenders for D because of Sun licensing issues.)


 
 
 I hate to repeat myself, but there is a free Swing available at
 www.classpath.org.
 
 Ciao
 
 ---
 http://www.mariottini.net/roberto/


Isn't that GPL?
I vote lets not force any D developers into (L)GPL type licensing 
issues.  That type of 'freedom' discourages commercial use (despite what 
the pundits say).


Seconded.

- Eric Anderton at yahoo



 Feb 07 2006



prev sibling  parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se>  writes:


David Medlock wrote:


 Isn't that GPL?
 I vote lets not force any D developers into (L)GPL type licensing 
 issues.  That type of 'freedom' discourages commercial use (despite what 
 the pundits say).


It's not really fair to bundle GPL and LGPL like that I think...
The *LGPL* will only affect the library development, not the use.

The only "downside" to the LGPL is the dynamic link requirement ?
(It's possible to explicitly allow static linking as an exception)

Just my 2c,
--anders



 Feb 07 2006



  parent reply Don Clugston <dac nospam.com.au>  writes:


Anders F Björklund wrote:

 David Medlock wrote:
 

 Isn't that GPL?
 I vote lets not force any D developers into (L)GPL type licensing 
 issues.  That type of 'freedom' discourages commercial use (despite 
 what the pundits say).


 
 It's not really fair to bundle GPL and LGPL like that I think...
 The *LGPL* will only affect the library development, not the use.
 
 The only "downside" to the LGPL is the dynamic link requirement ?
 (It's possible to explicitly allow static linking as an exception)


rant
Personally, I think the default LGPL license is the most ridiculous one 
I've seen, "Arse licence" included. The dynamic linking requirement 
doesn't benefit anyone. It's annoying for commercial use, but it doesn't 
benefit open source at all. GPL makes a lot of sense (in the right 
context, but definitely not for D standard libraries), but LGPL is just 
nuts.
/rant



 Feb 07 2006



 next sibling parent reply David Medlock <noone nowhere.com>  writes:


Don Clugston wrote:

 Anders F Björklund wrote:
 

 David Medlock wrote:


 Isn't that GPL?
 I vote lets not force any D developers into (L)GPL type licensing 
 issues.  That type of 'freedom' discourages commercial use (despite 
 what the pundits say).



 It's not really fair to bundle GPL and LGPL like that I think...
 The *LGPL* will only affect the library development, not the use.

 The only "downside" to the LGPL is the dynamic link requirement ?
 (It's possible to explicitly allow static linking as an exception)


 
 
 rant
 Personally, I think the default LGPL license is the most ridiculous one 
 I've seen, "Arse licence" included. The dynamic linking requirement 
 doesn't benefit anyone. It's annoying for commercial use, but it doesn't 
 benefit open source at all. GPL makes a lot of sense (in the right 
 context, but definitely not for D standard libraries), but LGPL is just 
 nuts.
 /rant


On top of that, for embedded work the LGPL becomes GPL because there is 
no 'dynamic' linking possible.

The libraries which allow the static linking exception (such as FLTK) 
should just use MPL or Apache Licenses, which avoid the ambiguities 
which come with GNU licenses.

-DavidM



 Feb 07 2006



 next sibling parent  =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se>  writes:


David Medlock wrote:


 On top of that, for embedded work the LGPL becomes GPL because there is 
 no 'dynamic' linking possible.


On the other hand, if they DO have the exception to allow static linking
then there is no such LGPL->GPL change in licensing when going embedded.

For instance: http://www.wxwidgets.org/embedded.htm (wxWindows License)


 The libraries which allow the static linking exception (such as FLTK) 
 should just use MPL or Apache Licenses, which avoid the ambiguities 
 which come with GNU licenses.


Perhaps, but that is their decision to make ? I use zlib/png, usually.

I still find it quite the difference if they use the LGPL-with-static-
linking (such as FLTK or wx) or if it is the GPL license (Qt O.S. Ed.)

--anders



 Feb 07 2006



prev sibling  parent reply "Walter Bright" <newshound digitalmars.com>  writes:


Can we move this discussion over to digitalmars.D.dwt?



 Feb 07 2006



  parent reply nick <nick.atamas gmail.com>  writes:


Walter Bright wrote:

 Can we move this discussion over to digitalmars.D.dwt?
 


Have you thought about moving to a PHPBB type forum? It would be much 
more accessible to newcomers. Just a thought.



 Feb 07 2006



  parent  "Walter Bright" <newshound digitalmars.com>  writes:


"nick" <nick.atamas gmail.com> wrote in message 
news:dsbr0b$l45$1 digitaldaemon.com...

 Walter Bright wrote:

 Can we move this discussion over to digitalmars.D.dwt?


 Have you thought about moving to a PHPBB type forum? It would be much more 
 accessible to newcomers. Just a thought.


Yes, there have been at least a couple of discussions about it. 



 Feb 07 2006



prev sibling  parent reply pragma <pragma_member pathlink.com>  writes:


In article <dsafo1$2c19$1 digitaldaemon.com>, Don Clugston says...

Anders F Björklund wrote:

 David Medlock wrote:
 

 Isn't that GPL?
 I vote lets not force any D developers into (L)GPL type licensing 
 issues.  That type of 'freedom' discourages commercial use (despite 
 what the pundits say).


 
 It's not really fair to bundle GPL and LGPL like that I think...
 The *LGPL* will only affect the library development, not the use.
 
 The only "downside" to the LGPL is the dynamic link requirement ?
 (It's possible to explicitly allow static linking as an exception)


rant
Personally, I think the default LGPL license is the most ridiculous one 
I've seen, "Arse licence" included. The dynamic linking requirement 
doesn't benefit anyone. It's annoying for commercial use, but it doesn't 
benefit open source at all. GPL makes a lot of sense (in the right 
context, but definitely not for D standard libraries), but LGPL is just 
nuts.
/rant


You're not alone in thinking this.  I myself find all GPL variants rather
dogmatic, and practically a form of "PM-repellant" around the office.  I always
felt the tone of the license to be more on the side of foisting a particular
agenda on developers rather than promoting "freedom".  The current flap
surrounding GPLv3, and the proliferation of other more flexible licenses, has
only solidified this belief of mine.

- Eric Anderton at yahoo



 Feb 07 2006



 next sibling parent  Dave <Dave_member pathlink.com>  writes:


In article <dsaofo$2lc8$1 digitaldaemon.com>, pragma says...

In article <dsafo1$2c19$1 digitaldaemon.com>, Don Clugston says...

Anders F Björklund wrote:

 David Medlock wrote:
 

 Isn't that GPL?
 I vote lets not force any D developers into (L)GPL type licensing 
 issues.  That type of 'freedom' discourages commercial use (despite 
 what the pundits say).


 
 It's not really fair to bundle GPL and LGPL like that I think...
 The *LGPL* will only affect the library development, not the use.
 
 The only "downside" to the LGPL is the dynamic link requirement ?
 (It's possible to explicitly allow static linking as an exception)


rant
Personally, I think the default LGPL license is the most ridiculous one 
I've seen, "Arse licence" included. The dynamic linking requirement 
doesn't benefit anyone. It's annoying for commercial use, but it doesn't 
benefit open source at all. GPL makes a lot of sense (in the right 
context, but definitely not for D standard libraries), but LGPL is just 
nuts.
/rant


You're not alone in thinking this.  I myself find all GPL variants rather
dogmatic, and practically a form of "PM-repellant" around the office.  I always
felt the tone of the license to be more on the side of foisting a particular
agenda on developers rather than promoting "freedom".  The current flap
surrounding GPLv3, and the proliferation of other more flexible licenses, has
only solidified this belief of mine.

- Eric Anderton at yahoo


Hear, hear!



 Feb 07 2006



prev sibling  parent  Thomas Kuehne <thomas-dloop kuehne.cn>  writes:


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

pragma schrieb am 2006-02-07:

 In article <dsafo1$2c19$1 digitaldaemon.com>, Don Clugston says...

rant
Personally, I think the default LGPL license is the most ridiculous one 
I've seen, "Arse licence" included. The dynamic linking requirement 
doesn't benefit anyone. It's annoying for commercial use, but it doesn't 
benefit open source at all. GPL makes a lot of sense (in the right 
context, but definitely not for D standard libraries), but LGPL is just 
nuts.
/rant


 You're not alone in thinking this.  I myself find all GPL variants rather
 dogmatic, and practically a form of "PM-repellant" around the office.  I always
 felt the tone of the license to be more on the side of foisting a particular
 agenda on developers rather than promoting "freedom".  The current flap
 surrounding GPLv3, and the proliferation of other more flexible licenses, has
 only solidified this belief of mine.

 - Eric Anderton at yahoo


This might apply if the software is bought.

However if you buy services - classic examples are webhosting and 
feature adding - (L)GPL can be convinent.

Thomas


-----BEGIN PGP SIGNATURE-----

iD8DBQFD6Q+t3w+/yD4P9tIRAqjJAJ9wGM2AM1zuF48QAHM5NDjDQSc+kACfZ643
OKBPfX46a0A+xDoS24f0LLw=
=SGBd
-----END PGP SIGNATURE-----



 Feb 07 2006



prev sibling next sibling parent  Sean Kelly <sean f4.ca>  writes:


Roberto Mariottini wrote:

 In article <ds9kot$1j45$1 digitaldaemon.com>, Walter Bright says...


 [...]

 Keep in mind, though, that AWT despite its flaws is what got Java off the 
 ground and kept it going for the initial few years.


 
 I completely disagree. I used Java from the beginning, and I can remember for
 sure that Java was nearly dead because of AWT. I remember the "Corel Office for
 Java" thing very well. Swing was the right choice, making Java exit the niche
of
 server-side applications.


Wasn't the big problem with AWT that it was slow?  And also partially 
because it didn't look like a native app?  And Swing was created to 
address these issues?  I've kept my eye on Java just enough to not 
really know what's going on ;-)


 (I don't think AWT or 
 Swing are contenders for D because of Sun licensing issues.)


 
 I hate to repeat myself, but there is a free Swing available at
 www.classpath.org.


Free as in beer?  I'd prefer to settle on something soon, but if someone 
can make a case for Swing or Qt or whatever over SWT then please do so.


Sean



 Feb 07 2006



prev sibling  parent reply "Walter Bright" <newshound digitalmars.com>  writes:


"Roberto Mariottini" <Roberto_member pathlink.com> wrote in message 
news:ds9lqd$1k95$1 digitaldaemon.com...

 In article <ds9kot$1j45$1 digitaldaemon.com>, Walter Bright says...

Keep in mind, though, that AWT despite its flaws is what got Java off the
ground and kept it going for the initial few years.


 I completely disagree. I used Java from the beginning, and I can remember 
 for
 sure that Java was nearly dead because of AWT. I remember the "Corel 
 Office for
 Java" thing very well. Swing was the right choice, making Java exit the 
 niche of
 server-side applications.


Everyone agrees that AWT is no good, but still Java wouldn't have gotten 
*anywhere* without it. Yes, I know about the Corel debacle.


(I don't think AWT or
Swing are contenders for D because of Sun licensing issues.)


 I hate to repeat myself, but there is a free Swing available at
 www.classpath.org.


Thank-you. I checked the license for it. It appears to allow commercial use 
of it, though I am not sure. Are you interested in taking the lead on this? 



 Feb 07 2006



  parent  Roberto Mariottini <Roberto_member pathlink.com>  writes:


In article <dsai30$2eim$2 digitaldaemon.com>, Walter Bright says...

(I don't think AWT or
Swing are contenders for D because of Sun licensing issues.)


 I hate to repeat myself, but there is a free Swing available at
 www.classpath.org.


Thank-you. I checked the license for it. It appears to allow commercial use 
of it, though I am not sure. Are you interested in taking the lead on this? 


I am not a lawyer, and I don't know which implications can arise from commercial
use of such a big library. I'd ask the current developers, maybe they have more
competent information.

As for taking a(nother) project lead, I'm sorry but I think I have enough
projects to run in my everyday work, plus at home I have my two 4-months-old
babies to deal with. Maybe in a couple of years I can think of doing it, but I
bet I won't have time anyway.

Ciao

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



 Feb 08 2006



prev sibling  parent  "Charles" <noone nowhere.com>  writes:





LOL.  Reminds me of the phrase 'Opinions are like assholes, everyones got
em.'

I have heard the exact opposite , that QT is not only awful to use ( as some
weird C++ hybrid beast , requiring its own build mechanism 'qmake' ), but
that its very pricey ( $1,500 annualy last time i checked ).



"nick" <nick.atamas gmail.com> wrote in message
news:ds9bg6$1bto$1 digitaldaemon.com...

 Walter Bright wrote:

 "Sean Kelly" <sean f4.ca> wrote in message
 news:ds8tqr$11ti$1 digitaldaemon.com...

 The problem is that while the D libraries are open source, not all
 applications using D will be.  Given the viral nature of open-source
 licenses, I think this would prevent Qt from being used in such a






project,

 no?


 That's right. A *standard* component of D needs to be usable by




commercial

 projects without needing to pay license fees. That would be no problem




if Qt

 were optional, but if it was standard it would impede the adoption of D.


 I made several rush posts from work, and I want to take this post to
 remove any ambiguity.


 I am biased against it, but I know it well enough to say that this:
 <http://www.hacknot.info/hacknot/action/showEntry?eid=74> is all true.
 AWT and Swing really aren't much better.

 QT is amazing, and people love it, but we can't use it. Now that I have
 Walter's blessing, I will attempt to contact Scott and ask him for
 guidance in this matter. I will also gather info on existing options.
 The least we will get out of this is a good picture of where things stand.





 Feb 07 2006



prev sibling  parent reply =?windows-1252?Q?Anders_F_Bj=F6rklund?= <afb algonet.se>  writes:


nick wrote:


QT cannot be used because it's a proprietary, non-free product. 


 
 QT is an open source product. It is only proprietary if you plan to use it for
 proprietary means. KDE is based on QT from ground up.


Seems that the "open source" and "proprietary, non-free" terms
are a bit broad and undefined here. There's more to OS than GPL ?

As I understand it, Qt offers two totally separate products...
Similar to what MySQL offers for embedded databases, it seems.


Either you pay for the full commercial per-developer license,
or you make your program Free Software under the GPL license.

If you want to use another Open Source license (say a BSDish),
or want to make freeware (without code), it seems you're SOL ?


At least that's how I understood it...
http://www.trolltech.com/products/licensing.html
http://www.trolltech.com/company/model.html

Looks like just the first year would run me €3380 ?
(developing a desktop application for three platforms)
http://www.trolltech.com/products/qt/pricing.html?cid=18

--anders

PS.
And there still needs to be Qt C++ -> D wrappers written,
which could prove to be a lot of work to accomplish too ?

But I won't stop anyone else from doing it, of course. :-)
Just that Qt isn't my own personal favorite lib either.



 Feb 07 2006



 next sibling parent  Lars Ivar Igesund <larsivar igesund.net>  writes:


Anders F Björklund wrote:


 nick wrote:
 

QT cannot be used because it's a proprietary, non-free product.


 
 QT is an open source product. It is only proprietary if you plan to use
 it for proprietary means. KDE is based on QT from ground up.


 
 Seems that the "open source" and "proprietary, non-free" terms
 are a bit broad and undefined here. There's more to OS than GPL ?
 
 As I understand it, Qt offers two totally separate products...
 Similar to what MySQL offers for embedded databases, it seems.
 
 
 Either you pay for the full commercial per-developer license,
 or you make your program Free Software under the GPL license.
 
 If you want to use another Open Source license (say a BSDish),
 or want to make freeware (without code), it seems you're SOL ?
 
 
 At least that's how I understood it...
 http://www.trolltech.com/products/licensing.html
 http://www.trolltech.com/company/model.html
 
 Looks like just the first year would run me €3380 ?
 (developing a desktop application for three platforms)
 http://www.trolltech.com/products/qt/pricing.html?cid=18
 
 --anders
 
 PS.
 And there still needs to be Qt C++ -> D wrappers written,
 which could prove to be a lot of work to accomplish too ?
 
 But I won't stop anyone else from doing it, of course. :-)
 Just that Qt isn't my own personal favorite lib either.


You are quite right. It's a fair and square businessmodel, even Walter does
it with DMDScript, and several other companies I know. The clue that makes
this possible for them is that they own the code, and don't accept
patches/contributions that will change this.

And I find it obvious that Trolltech wouldn't let a non-GPL port slip by
without repercussions.

Lars Ivar Igesund



 Feb 07 2006



prev sibling  parent reply "Walter Bright" <newshound digitalmars.com>  writes:


"Anders F Björklund" <afb algonet.se> wrote in message 
news:ds9m7m$1kjh$1 digitaldaemon.com...

 PS.
 And there still needs to be Qt C++ -> D wrappers written,
 which could prove to be a lot of work to accomplish too ?


That's right. It's entirely possible it is too much to be practical. 



 Feb 07 2006



  parent  =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se>  writes:


Walter Bright wrote:


And there still needs to be Qt C++ -> D wrappers written,
which could prove to be a lot of work to accomplish too ?


 
 That's right. It's entirely possible it is too much to be practical. 


If anyone is willing to undertake such a project (i.e. not me !),
I think you could use code from http://qtcsharp.sourceforge.net/

It could be made to work, in a similar manner to wxD, by porting


Seems that they have switched over to some XML-based SWIG workalike)




You would still face the same licensing issues as the C++ version,
though. (i.e. this "Open Source" version is under the GPL license)

--anders



 Feb 07 2006



prev sibling  parent reply "Andrew Fedoniouk" <news terrainformatica.com>  writes:


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?
 





 Feb 03 2006



 next sibling parent reply "Craig Black" <cblack ara.com>  writes:


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?


 





 Feb 03 2006



  parent reply "Andrew Fedoniouk" <news terrainformatica.com>  writes:


"Craig Black" <cblack ara.com> wrote in message 
news:ds0lt7$srs$1 digitaldaemon.com...

 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?


Exactly.

Take a look: all toolkits have classes like
Graphics with acompanying Font, Image and other drawing primitivies.
Can we make them as some standard package? Sure, I would say we must to.
Another candidate for standard library are Rect, Point, Polygon - geometric 
primitives.

Will all toolkits benefit if we would have them as a standard library? Sure.
For example: harmonia.html package as a pure renderer or layout manager
could be used in DWT, DFL, etc. if they will use common drawing and geometry
primitivies from the "Standard D Graphics" package. Thus all toolkits could
have "declarative UI" functionality.

Splitting GUI framework into three modules allows to design
them indepenedently and to do not waste time of relatively small comunity.
"We are not so rich to by cheap things".

Andrew Fedoniouk.
http://terrainformatica.com



 Feb 03 2006



  parent reply Mark D <theomnipotentqatmsn msn.com>  writes:


 Take a look: all toolkits have classes like
 Graphics with acompanying Font, Image and other drawing primitivies.
 Can we make them as some standard package? Sure, I would say we must to.
 Another candidate for standard library are Rect, Point, Polygon - geometric 
 primitives.


I definitely would like to see something like this... but in the back of 
my head - with my limited knowledge - I'm wondering how exactly 
something like this would work.  For example, presumably we are drawing 
all of these things in a window, right?  So that sort of implies that 
even a default, simple and "primitive" graphics functionality also 
involves a standard cross-platform syntax to create and manipulate a 
window.  So what properties does a window need?  And I would guess that 
this is the point where things start to snowball out of control with 
issues like resolution, modality, fullscreen support, color depth, etc.

I remember fondly working with Borland's flavor of C++ in DOS, and using 
those most basic of functions to create classes to encapsulate the 
functionality I wanted (windows, buttons, etc).  But while I can 
understand easily how that works, it seems like we're now in a totally 
different world when it comes to creating a similar experience that is 
truly cross-platform with our current operating systems.  I would 
appreciate any enlightenment! ;)

Mark D.



 Feb 03 2006



 next sibling parent reply "Ben Hinkle" <ben.hinkle gmail.com>  writes:


"Mark D" <theomnipotentqatmsn msn.com> wrote in message 
news:ds0si9$11bk$1 digitaldaemon.com...

 Take a look: all toolkits have classes like
 Graphics with acompanying Font, Image and other drawing primitivies.
 Can we make them as some standard package? Sure, I would say we must to.
 Another candidate for standard library are Rect, Point, Polygon - 
 geometric primitives.


 I definitely would like to see something like this... but in the back of 
 my head - with my limited knowledge - I'm wondering how exactly something 
 like this would work.  For example, presumably we are drawing all of these 
 things in a window, right?  So that sort of implies that even a default, 
 simple and "primitive" graphics functionality also involves a standard 
 cross-platform syntax to create and manipulate a window.  So what 
 properties does a window need?  And I would guess that this is the point 
 where things start to snowball out of control with issues like resolution, 
 modality, fullscreen support, color depth, etc.


The approach I was taking with MinWin was to make the native type available 
(and encouraged) for direct manipulation. That's why it was very important 
to have as minimal a layer as possible between the MinWin D code and the 
underlying OS types and routines. One should be able to easily take a MinWin 
window (or graphics or whatever) and do to it whatever the native system 
supports (within reason). Most cross-platform GUI toolkits try as hard as 
possible to hide the implementation details (as OOP methodology 
traditionally encourages) but I think for GUI toolkits that just results in 
a frustratingly limited toolkit. For example there should be no extra state 
stored in the D objects so that there's no risk of getting the D view of the 
widget out of sync with the OS view.



 I remember fondly working with Borland's flavor of C++ in DOS, and using 
 those most basic of functions to create classes to encapsulate the 
 functionality I wanted (windows, buttons, etc).  But while I can 
 understand easily how that works, it seems like we're now in a totally 
 different world when it comes to creating a similar experience that is 
 truly cross-platform with our current operating systems.  I would 
 appreciate any enlightenment! ;)

 Mark D. 





 Feb 03 2006



  parent  =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se>  writes:


Ben Hinkle wrote:


 The approach I was taking with MinWin was to make the native type available 
 (and encouraged) for direct manipulation. That's why it was very important 
 to have as minimal a layer as possible between the MinWin D code and the 
 underlying OS types and routines. One should be able to easily take a MinWin 
 window (or graphics or whatever) and do to it whatever the native system 
 supports (within reason). Most cross-platform GUI toolkits try as hard as 
 possible to hide the implementation details (as OOP methodology 
 traditionally encourages) but I think for GUI toolkits that just results in 
 a frustratingly limited toolkit. For example there should be no extra state 
 stored in the D objects so that there's no risk of getting the D view of the 
 widget out of sync with the OS view.


One of the problems* on the Mac OS X platform, when I tried to port 
MinWin, was that the two native system libraries/frameworks were not 
easily accessible from D. So there D itself definitely was a problem.

One is written in C/C++ (Carbon) and has a *lot* of old header files 
that needs to be ported over first. The other framework is written in 
Objective-C/Java (Cocoa) and is not easily accessible from D either.


When writing the interface code in C++ or Objective-C++, it is simple
to export the needed functions with a "C" interface for use with D...
(simple, because one can just use the system frameworks as they are)

And this is the approach that wxD uses, so I scrapped my Carbon hacks.
(the Carbon version is in wxMac, and the Cocoa version is in wxCocoa)
GTK+ is unfortunately still very behind the times, on the Mac platform.



--anders


*
If anyone cares, the other reason was that MinWin wasn't copyrighted.
I like the "wxWidgets license" better than releasing as Public Domain.
And licensing was also one of my reasons for not choosing Qt instead...



 Feb 04 2006



prev sibling  parent  "Andrew Fedoniouk" <news terrainformatica.com>  writes:


"Mark D" <theomnipotentqatmsn msn.com> wrote in message 
news:ds0si9$11bk$1 digitaldaemon.com...

 Take a look: all toolkits have classes like
 Graphics with acompanying Font, Image and other drawing primitivies.
 Can we make them as some standard package? Sure, I would say we must to.
 Another candidate for standard library are Rect, Point, Polygon - 
 geometric primitives.


 I definitely would like to see something like this... but in the back of 
 my head - with my limited knowledge - I'm wondering how exactly something 
 like this would work.  For example, presumably we are drawing all of these 
 things in a window, right?  So that sort of implies that even a default, 
 simple and "primitive" graphics functionality also involves a standard 
 cross-platform syntax to create and manipulate a window.  So what 
 properties does a window need?  And I would guess that this is the point 
 where things start to snowball out of control with issues like resolution, 
 modality, fullscreen support, color depth, etc.


consider this:

typedef void* HANDLE;

class Graphics
{
  this(HANDLE h) {....}
}

This is neutral "one size fits all" declaration for the case when
Graphics used as standalone package.
So you can write simple WinProc and in WM_PAINT pass
construct Graphics with HDC handle.
Drawing and Event handling are loosely coupled things or at least
the can be implemented this way.

If some toolkit is using this Graphics package then it should
provide correspondent methods providing Graphics for different "surfaces"
For example in Harmona there are
three sources of Graphics (classes implementing ISurface) and
they all have methods/properties:

Graphics Window.graphics();
Graphics Image.graphics();
Graphics Printer.graphics();

Some other toolkit, for example http server side image package
will have only
Graphics Image.graphics();
to provide dynamic image drawing facilities.



 I remember fondly working with Borland's flavor of C++ in DOS, and using 
 those most basic of functions to create classes to encapsulate the 
 functionality I wanted (windows, buttons, etc).  But while I can 
 understand easily how that works, it seems like we're now in a totally 
 different world when it comes to creating a similar experience that is 
 truly cross-platform with our current operating systems.  I would 
 appreciate any enlightenment! ;)


I beleive you are speaking about BGI, right?
Nothing changed in principle here.
As I mentioned before there are two ways of how to design toolkit.
MinWin is thin layer wrapping underlying window primitives which is
extremely usefull if you need to write something native for e.g. Windows.
And Harmonia uses quite different approach similar to what you did in BGI -
it uses only topmost os windows - no child HWNDs inside - it draws
everything by itself (menus, buttons, checkboxes, etc).

Hope I've explained all this clear in my Eng++.
Sorry otherwise.


Andrew Fedoniouk.
http://terrainformatica.com



 Feb 03 2006



prev sibling next sibling parent reply Kyle Furlong <kylefurlong gmail.com>  writes:


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.



 Feb 03 2006



  parent reply "Walter Bright" <newshound digitalmars.com>  writes:


"Kyle Furlong" <kylefurlong gmail.com> wrote in message 
news:ds0m2i$sus$1 digitaldaemon.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.


Personally, I don't like the java coding style either. But think of it like 
strapping a rocket engine on a chicken, once we get that sucker off the 
ground, we can build ourselves a nicer set of wings <g>. 



 Feb 03 2006



  parent reply Sean Kelly <sean f4.ca>  writes:


Walter Bright wrote:

 "Kyle Furlong" <kylefurlong gmail.com> wrote in message 
 news:ds0m2i$sus$1 digitaldaemon.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.


 
 Personally, I don't like the java coding style either. But think of it like 
 strapping a rocket engine on a chicken, once we get that sucker off the 
 ground, we can build ourselves a nicer set of wings <g>. 


I'm really enjoying these chicken analogies.  Someone needs to create a 
D logo that has a picture of a chicken strapped to a rocket ;-)


Sean



 Feb 03 2006



 next sibling parent  "Kris" <fu bar.com>  writes:


"Sean Kelly" <sean f4.ca> wrote...

 I'm really enjoying these chicken analogies.  Someone needs to create a D 
 logo that has a picture of a chicken strapped to a rocket ;-)



Be careful about that, Sean ...

You might end up with some group of religious 
fanatics/fundamentalists/ideologists/terrorists trying to kill you for 
expressing a right to free-speech. Chickens are not to be illustrated! 
Dammit!

(I'll probably get threats from the same kind & gentle people for noting the 
above)



 Feb 03 2006



prev sibling  parent reply pragma <pragma_member pathlink.com>  writes:


In article <ds0u4s$12ad$1 digitaldaemon.com>, Sean Kelly says...

Walter Bright wrote:

 "Kyle Furlong" <kylefurlong gmail.com> wrote in message 
 news:ds0m2i$sus$1 digitaldaemon.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.


 
 Personally, I don't like the java coding style either. But think of it like 
 strapping a rocket engine on a chicken, once we get that sucker off the 
 ground, we can build ourselves a nicer set of wings <g>. 


I'm really enjoying these chicken analogies.  Someone needs to create a 
D logo that has a picture of a chicken strapped to a rocket ;-)


How did I ever use the internet without google?

http://www.pioneerlocal.com/movies/graphics/pix/11-03-05-review.jpg
http://www.chickenrocket.com/
http://www.users.bigpond.net.au/calleja/images/100_1493.JPG

The last one seems apt.


- Eric Anderton at yahoo



 Feb 03 2006



  parent  "Kris" <fu bar.com>  writes:


"pragma" <pragma_member pathlink.com> wrote ...

 How did I ever use the internet without google?

 http://www.pioneerlocal.com/movies/graphics/pix/11-03-05-review.jpg
 http://www.chickenrocket.com/
 http://www.users.bigpond.net.au/calleja/images/100_1493.JPG

 The last one seems apt.


Oh boy ... you sure are inviting trouble, Eric; for "reprinting" such 
insensitive images.


[ok; ok; I'll stop now] 



 Feb 03 2006



prev sibling  parent reply "Walter Bright" <newshound digitalmars.com>  writes:


You've made some very good points, and I want to address them.

1) Yes, there are the two major approaches to a gui toolkit, good for 
different purposes. But right now, the important thing is that we have one, 
not which approach it is. As D grows, then other guis with the other 
approaches will naturally become available. Picking DWT now does not shut 
the door on those others, all it does is get enough momentum and focus to 
get one *done*. It's the chicken and egg problem here, people won't use D 
because it has no gui, people won't develop guis because there's no people 
using D. Even if it's not the perfect chicken, we need a chicken to start 
our farm <g>. Once our farm is going, then we can buy some better chickens 
and add them in.

2) I agree that it would be better to use delegates and other cool D 
features to do a better gui design than SWT. I discussed this at length with 
Kris in email a while back, we both came to the conclusion that this is just 
not practical to do right now, because we don't have a large staff of 
minions paid to attack this problem. We have very limited resources, so it's 
all about leverage. We need a chicken to bootstrap the process, and the 
fastest way to get one is to forget about redesigning SWT, but to just 
translate it as is.

3) DWT doesn't need to track changes in SWT once DWT is built. If it forks 
from SWT, that's OK, because then we'll have our chicken, and so we'll have 
eggs, then more chickens, etc.

4) You're right in that automated translation from Java to a D program isn't 
going to work 100%, 90%, or even 80%. If it works 75%, with 25% manual 
fiddling, that's still a big leg up. The percentage for C++ would be a lot 
lower, especially if the C++ code uses STL or Boost, where it won't work at 
all. I tend to write C++ code that would easilly convert to D, but very 
little of what I run across otherwise would.


"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





 Feb 03 2006



  parent reply "Andrew Fedoniouk" <news terrainformatica.com>  writes:


Thanks, Walter, see below:

"Walter Bright" <newshound digitalmars.com> wrote in message 
news:ds0run$110u$1 digitaldaemon.com...

 You've made some very good points, and I want to address them.

 1) Yes, there are the two major approaches to a gui toolkit, good for 
 different purposes. But right now, the important thing is that we have 
 one, not which approach it is. As D grows, then other guis with the other 
 approaches will naturally become available. Picking DWT now does not shut 
 the door on those others, all it does is get enough momentum and focus to 
 get one *done*. It's the chicken and egg problem here, people won't use D 
 because it has no gui, people won't develop guis because there's no people 
 using D. Even if it's not the perfect chicken, we need a chicken to start 
 our farm <g>. Once our farm is going, then we can buy some better chickens 
 and add them in.


Well, of course you can assign name "DWT, official toolkit".
If it will help then why not?


 2) I agree that it would be better to use delegates and other cool D 
 features to do a better gui design than SWT. I discussed this at length 
 with Kris in email a while back, we both came to the conclusion that this 
 is just not practical to do right now, because we don't have a large staff 
 of minions paid to attack this problem. We have very limited resources, so 
 it's all about leverage. We need a chicken to bootstrap the process, and 
 the fastest way to get one is to forget about redesigning SWT, but to just 
 translate it as is.


Again if it will help....


 3) DWT doesn't need to track changes in SWT once DWT is built. If it forks 
 from SWT, that's OK, because then we'll have our chicken, and so we'll 
 have eggs, then more chickens, etc.


As I said: the egg is strong, simple and effective D-ish Graphical package
wrapping HDC stuff. Chickens and other animals will be born from it.
IMHO of course.


 4) You're right in that automated translation from Java to a D program 
 isn't going to work 100%, 90%, or even 80%. If it works 75%, with 25% 
 manual fiddling, that's still a big leg up. The percentage for C++ would 
 be a lot lower, especially if the C++ code uses STL or Boost, where it 
 won't work at all. I tend to write C++ code that would easilly convert to 
 D, but very little of what I run across otherwise would.


Forget about STL and boost. There is no practical GUI  toolkit in the wild
using them anyway.  (This fact speaks for itself)

Andrew Fedoniouk.
http://terrainformatica.com



 Feb 03 2006



  parent reply "Walter Bright" <newshound digitalmars.com>  writes:


"Andrew Fedoniouk" <news terrainformatica.com> wrote in message 
news:ds10up$14av$1 digitaldaemon.com...

 Forget about STL and boost. There is no practical GUI  toolkit in the wild
 using them anyway.  (This fact speaks for itself)


I know. I have a suspicion that both are evolutionary dead ends. Your fact 
is evidence for that, as well as the failure of any other language to pick 
up those features. 



 Feb 03 2006



 next sibling parent reply "Andrew Fedoniouk" <news terrainformatica.com>  writes:


"Walter Bright" <newshound digitalmars.com> wrote in message 
news:ds130o$15kh$1 digitaldaemon.com...

 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message 
 news:ds10up$14av$1 digitaldaemon.com...

 Forget about STL and boost. There is no practical GUI  toolkit in the 
 wild
 using them anyway.  (This fact speaks for itself)


 I know. I have a suspicion that both are evolutionary dead ends. Your fact 
 is evidence for that, as well as the failure of any other language to pick 
 up those features.


I think this way too. I am monitoring couple of GUI projects trying
to interbreed STL or even boost with GUI ... aesthetical disaster is
what I can say at least.

Sidenote: on RSDN forum one person was asking about
some tool for C++ sources obfuscation (purpose is unknown to me),
and practical advice-answer was to write code using boost.

-----------
BTW, generally speaking C++ has no "official GUI toolkit" too.
Seems like only persons who are not satisfied with this situation are
Bjarne Stroustrup, Michael Rasmussen and John Medema
according to http://lafstern.org/matt/wishlist.html section "GUI"

-----------
Walter, as you are here...  any news from
"immutability aka const aka readonly" front?
And one more: external aka outer methods for primitive types,
especially arrays... No?
Just in case.... as seems like you are in good mood :)

Andrew Fedoniouk.
http://terrainformatica.com



 Feb 03 2006



  parent reply "Walter Bright" <newshound digitalmars.com>  writes:


"Andrew Fedoniouk" <news terrainformatica.com> wrote in message 
news:ds16ar$17fh$1 digitaldaemon.com...

 Sidenote: on RSDN forum one person was asking about
 some tool for C++ sources obfuscation (purpose is unknown to me),
 and practical advice-answer was to write code using boost.


I find boost impractical to use as well. It's just--too--complicated.


 -----------
 BTW, generally speaking C++ has no "official GUI toolkit" too.
 Seems like only persons who are not satisfied with this situation are
 Bjarne Stroustrup, Michael Rasmussen and John Medema
 according to http://lafstern.org/matt/wishlist.html section "GUI"


Bjarne is right.

C++ has 3 choices:

1) Do nothing and argue that a standard gui is a bad idea.
2) Design by committee a new gui from scratch. Odds of this turning out 
something useful are zilch.
3) Endorse one of the existing C++ guis. One vendor gets rich and the rest 
are mad as h*ll. Not going to happen.

This is why (1) is where C++ is going, despite it being the wrong choice. I 
figure we need to fix the problem with D before we get trapped by (2) and 
(3) as well.



 -----------
 Walter, as you are here...  any news from
 "immutability aka const aka readonly" front?
 And one more: external aka outer methods for primitive types,
 especially arrays... No?


Haven't time to deal with those issues at the moment, and I don't think 
there'll be any movement on them until after 1.0. 



 Feb 03 2006



 next sibling parent reply Hasan Aljudy <hasan.aljudy gmail.com>  writes:


Walter Bright wrote:

 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message 
 news:ds16ar$17fh$1 digitaldaemon.com...
 

Sidenote: on RSDN forum one person was asking about
some tool for C++ sources obfuscation (purpose is unknown to me),
and practical advice-answer was to write code using boost.


 
 
 I find boost impractical to use as well. It's just--too--complicated.
 
 

-----------
BTW, generally speaking C++ has no "official GUI toolkit" too.
Seems like only persons who are not satisfied with this situation are
Bjarne Stroustrup, Michael Rasmussen and John Medema
according to http://lafstern.org/matt/wishlist.html section "GUI"


 
 
 Bjarne is right.
 
 C++ has 3 choices:
 


[snip]

 2) Design by committee a new gui from scratch. Odds of this turning out 
 something useful are zilch.


Do they admit this? because IMO, they should admit that their Design of 
C++ just sucks!! I returned to C++ few days ago because some of my 
courses now require it .. and I discovered that C++ really sucks!! like 
.. really really sucks! specially for doing object oriented programming! 
Ofcourse they choose C++ for effeciency .. man I wish I could that 
assignment in D! It'd be awesome!! Hmm, come to think of it, maybe I can 
tell my prof about D .. if he likes it, he might use it for the next 
semister .. or something! Can someone write a short paragraph/essay to 
convince a University professor that D is more suitable for graphics 
programming than C++?! Seriously, all these profs care about (I 
think/hope) is performance, they would probably use Java, if it wasn't 
so slow and didn't run in a VM!
Same for networking course .. as long as there are D bindings for things 
related to socket programming and everything else network related.
I know for sure that the Prof can use whatever language he likes for 
courses, one prof made us use Python for .. guess what? data 
structures!! Why? because he likes it!!

OK, I've gone OT ..

Anyway, why don't they (the C++ committee) ask a bunch of 
developers/copmpanies/whatever to develope a standard gui for C++? Did 
they consider doing this? Kind of combines the best of points (2) and 
(3) I think.



 Feb 03 2006



  parent reply Sean Kelly <sean f4.ca>  writes:


Hasan Aljudy wrote:

 Walter Bright wrote:


 2) Design by committee a new gui from scratch. Odds of this turning 
 out something useful are zilch.


 
 Do they admit this? because IMO, they should admit that their Design of 
 C++ just sucks!!


In this case, the problem has more to do with the committee aspect than 
the language design.


 I returned to C++ few days ago because some of my 
 courses now require it .. and I discovered that C++ really sucks!! like 
 .. really really sucks! specially for doing object oriented programming! 


C++ turned out nearly as well as it could given historic issues and 
design constraints.  The committee aspect also hobbled things a bit--a 
good chunk of the original standard library proposal was simply scrapped 
for lack of time to evaluate it.  In my opinion, there are two primary 
problems with C+:

* The language supports so many different programming techniques that 
coordinating team development to produce a consistent code-level design 
is very difficult.

* The desire to implement as much functionality as possible in library 
code has made code interoperability difficult to achieve, and the 
language facilities required to support this have hurt code readability.

Baically, there are simply too many corner cases and odd exceptions in 
how C++ code behaves for the language to be well understood without a 
significant amount of study.  That isn't to say it's impossible to write 
elegant, fast, maintainable code in C++ however, only that the language 
doesn't encourage it.


 Ofcourse they choose C++ for effeciency .. man I wish I could that 
 assignment in D! It'd be awesome!! Hmm, come to think of it, maybe I can 
 tell my prof about D .. if he likes it, he might use it for the next 
 semister .. or something! Can someone write a short paragraph/essay to 
 convince a University professor that D is more suitable for graphics 
 programming than C++?! Seriously, all these profs care about (I 
 think/hope) is performance, they would probably use Java, if it wasn't 
 so slow and didn't run in a VM!


For D to be taught in a university course I think it probably needs a 
book about it.  School is weird that way.  However, D has a lot of 
selling points that should make it attractive for academic use.  A few 
of the more obvious ones are its floating-point support, garbage 
collection of UDTs, and its ability to get to the bare metal via 
pointers and inline assembly code.  This would allow a teacher to focus 
on algorithms without worrying about memory allocation and the like 
(which is why Java has become so popular in academics), to do accurate 
number-crunching for engineering classes with a simple straightforward 
syntax, and to also allow low-level issues to be explored *all in the 
same language*.  I can't think of any other programming language that 
can make such a claim.  The only drawback at the moment is the lack of 
solid debugger support, as I think debuggers can be a useful tool for 
learning how code executes.


 Anyway, why don't they (the C++ committee) ask a bunch of 
 developers/copmpanies/whatever to develope a standard gui for C++? Did 
 they consider doing this? Kind of combines the best of points (2) and 
 (3) I think.


Such a library would still have to be evaluated by the committee before 
being accepted, and that's a few years worth of meetings all by itself. 
  I think the project is simply too large for those involved to consider 
it worthwhile.  After all, C++ is lacking a lot more basic things that 
need to be sorted out first.  Perhaps we'll see one in the 2020 
iteration of the standard.


Sean



 Feb 03 2006



 next sibling parent reply Sean Kelly <sean f4.ca>  writes:


Sean Kelly wrote:

 Hasan Aljudy wrote:
 

 Anyway, why don't they (the C++ committee) ask a bunch of 
 developers/copmpanies/whatever to develope a standard gui for C++? Did 
 they consider doing this? Kind of combines the best of points (2) and 
 (3) I think.


 
 Such a library would still have to be evaluated by the committee before 
 being accepted, and that's a few years worth of meetings all by itself. 
  I think the project is simply too large for those involved to consider 
 it worthwhile.  After all, C++ is lacking a lot more basic things that 
 need to be sorted out first.  Perhaps we'll see one in the 2020 
 iteration of the standard.


I forgot to mention... another big issue is support.  It's far easier to 
add things to the standard than it is to remove them, and with the rate 
that UIs are changing, the committee would have be considering any 
submission in the light that it should be meaningful 20 years from now. 
  Also, there has been historic resistance to anything that isn't 
perceived as common to all platforms using C++, or that is difficult to 
present in a manner that would be applicable to all such platforms 
(though this is changing a bit now).  And in this case "all platforms" 
can mean 15 year old embedded processors with 6 bit bytes.  Fortunately, 
D isn't hobbled by such restrictions.


Sean



 Feb 03 2006



  parent reply "Walter Bright" <newshound digitalmars.com>  writes:


"Sean Kelly" <sean f4.ca> wrote in message 
news:ds1cka$1bas$1 digitaldaemon.com...

 I forgot to mention... another big issue is support.  It's far easier to 
 add things to the standard than it is to remove them, and with the rate 
 that UIs are changing, the committee would have be considering any 
 submission in the light that it should be meaningful 20 years from now.


Nobody has any idea what will happen in 20 years, so that's a hopeless 
condition.


  Also, there has been historic resistance to anything that isn't perceived 
 as common to all platforms using C++, or that is difficult to present in a 
 manner that would be applicable to all such platforms (though this is 
 changing a bit now).  And in this case "all platforms" can mean 15 year 
 old embedded processors with 6 bit bytes.  Fortunately, D isn't hobbled by 
 such restrictions.


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. 



 Feb 03 2006



  parent reply U.Baumanis <U.Baumanis_member pathlink.com>  writes:


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



 Feb 04 2006



  parent  "Walter Bright" <newshound digitalmars.com>  writes:


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



 Feb 04 2006



prev sibling next sibling parent  kris <fu bar.org>  writes:


That's probably the most concise and accurate illustration of C++ issues 
that I've seen, Sean.



Sean Kelly wrote:

 Hasan Aljudy wrote:
 

 Walter Bright wrote:


 2) Design by committee a new gui from scratch. Odds of this turning 
 out something useful are zilch.



 Do they admit this? because IMO, they should admit that their Design 
 of C++ just sucks!!


 
 
 In this case, the problem has more to do with the committee aspect than 
 the language design.
 

 I returned to C++ few days ago because some of my courses now require 
 it .. and I discovered that C++ really sucks!! like .. really really 
 sucks! specially for doing object oriented programming! 


 
 
 C++ turned out nearly as well as it could given historic issues and 
 design constraints.  The committee aspect also hobbled things a bit--a 
 good chunk of the original standard library proposal was simply scrapped 
 for lack of time to evaluate it.  In my opinion, there are two primary 
 problems with C+:
 
 * The language supports so many different programming techniques that 
 coordinating team development to produce a consistent code-level design 
 is very difficult.
 
 * The desire to implement as much functionality as possible in library 
 code has made code interoperability difficult to achieve, and the 
 language facilities required to support this have hurt code readability.
 
 Baically, there are simply too many corner cases and odd exceptions in 
 how C++ code behaves for the language to be well understood without a 
 significant amount of study.  That isn't to say it's impossible to write 
 elegant, fast, maintainable code in C++ however, only that the language 
 doesn't encourage it.
 

 Ofcourse they choose C++ for effeciency .. man I wish I could that 
 assignment in D! It'd be awesome!! Hmm, come to think of it, maybe I 
 can tell my prof about D .. if he likes it, he might use it for the 
 next semister .. or something! Can someone write a short 
 paragraph/essay to convince a University professor that D is more 
 suitable for graphics programming than C++?! Seriously, all these 
 profs care about (I think/hope) is performance, they would probably 
 use Java, if it wasn't so slow and didn't run in a VM!


 
 
 For D to be taught in a university course I think it probably needs a 
 book about it.  School is weird that way.  However, D has a lot of 
 selling points that should make it attractive for academic use.  A few 
 of the more obvious ones are its floating-point support, garbage 
 collection of UDTs, and its ability to get to the bare metal via 
 pointers and inline assembly code.  This would allow a teacher to focus 
 on algorithms without worrying about memory allocation and the like 
 (which is why Java has become so popular in academics), to do accurate 
 number-crunching for engineering classes with a simple straightforward 
 syntax, and to also allow low-level issues to be explored *all in the 
 same language*.  I can't think of any other programming language that 
 can make such a claim.  The only drawback at the moment is the lack of 
 solid debugger support, as I think debuggers can be a useful tool for 
 learning how code executes.
 

 Anyway, why don't they (the C++ committee) ask a bunch of 
 developers/copmpanies/whatever to develope a standard gui for C++? Did 
 they consider doing this? Kind of combines the best of points (2) and 
 (3) I think.


 
 
 Such a library would still have to be evaluated by the committee before 
 being accepted, and that's a few years worth of meetings all by itself. 
  I think the project is simply too large for those involved to consider 
 it worthwhile.  After all, C++ is lacking a lot more basic things that 
 need to be sorted out first.  Perhaps we'll see one in the 2020 
 iteration of the standard.
 
 
 Sean





 Feb 03 2006



prev sibling next sibling parent  "Walter Bright" <newshound digitalmars.com>  writes:


"Sean Kelly" <sean f4.ca> wrote in message 
news:ds1c2c$1apm$1 digitaldaemon.com...

 Hasan Aljudy wrote:

 Walter Bright wrote:


 2) Design by committee a new gui from scratch. Odds of this turning out 
 something useful are zilch.


 Do they admit this? because IMO, they should admit that their Design of 
 C++ just sucks!!


 In this case, the problem has more to do with the committee aspect than 
 the language design.


That's what I meant. The people on the C++ committee are excellent 
programmers. But the problems of design by committee are human nature. 



 Feb 03 2006



prev sibling  parent reply clayasaurus <clayasaurus gmail.com>  writes:


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.



 Feb 04 2006



 next sibling parent  Sean Kelly <sean f4.ca>  writes:


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



 Feb 04 2006



prev sibling  parent  Bruno Medeiros <daiphoenixNO SPAMlycos.com>  writes:


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>


 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.


Using that comparision is probably not good, as it is awfully outdated, 
and (more arguably) perhaps a bit biased. Perhaps the Wiki4D one is 
better suited. (and Walter, you may want to start thinking about 


-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to 
be... unnatural."



 Feb 06 2006



prev sibling  parent reply "Andrew Fedoniouk" <news terrainformatica.com>  writes:


"Walter Bright" <newshound digitalmars.com> wrote in message 
news:ds18ci$18rm$1 digitaldaemon.com...

 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message 
 news:ds16ar$17fh$1 digitaldaemon.com...

 Sidenote: on RSDN forum one person was asking about
 some tool for C++ sources obfuscation (purpose is unknown to me),
 and practical advice-answer was to write code using boost.


 I find boost impractical to use as well. It's just--too--complicated.


 -----------
 BTW, generally speaking C++ has no "official GUI toolkit" too.
 Seems like only persons who are not satisfied with this situation are
 Bjarne Stroustrup, Michael Rasmussen and John Medema
 according to http://lafstern.org/matt/wishlist.html section "GUI"


 Bjarne is right.


I don't think so :)


 C++ has 3 choices:

 1) Do nothing and argue that a standard gui is a bad idea.


Exactly! I don't even know what "standard gui" means.
Each application (or group of applications) has its own requirement set 
here.
"standard" of what for the byte sake?


 2) Design by committee a new gui from scratch. Odds of this turning out 
 something useful are zilch.
 3) Endorse one of the existing C++ guis. One vendor gets rich and the rest 
 are mad as h*ll. Not going to happen.

 This is why (1) is where C++ is going, despite it being the wrong choice. 
 I figure we need to fix the problem with D before we get trapped by (2) 
 and (3) as well.


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.

Sidenote: Recently we did UI for some online application
(70,000 subscribers so far) - client side GUI is just one
big Java applet.
Swing is basicly not moving and SWT just does not work in browser
so we've ended up with our own toolkit  based on low level AWT
primitives with architecture very close to what Harmonia uses.

The point here - even in Java with its "official
toolkit" (two of them, btw) in real life you will be forced to use your own 
at the end.
(I've never seen real application using Swing, btw)
In .NET situation is similar: Microsoft is dropping WinForms in favour
of Avalon foundation now. At the meantime people are doing their
own stuff even redesigning basic GDI+ primitives.
Example: GUI of http://www.creativedocs.net/ Pierre Arnaud
.NET application with AGG (http://antigrain.com/) engine and
completely custom GUI toolkit.

So the question - what is this "standard GUI" for?

Again, solution could be in building "standard GUI" pyramid
from reusable blocks like Graphics Package, etc.
Such blocks will have more chance to be a) accepted widely
b) to be not thrown away if something will go wrong.

Accepting this D will demonstrate maturity in its
design principles. Joke.

If you wish we can establish sort of working group
on creation of such D GUI foundation,
Graphics Package, etc.
I am short on time a bit now but will try to do something here
if we need to.


 -----------
 Walter, as you are here...  any news from
 "immutability aka const aka readonly" front?
 And one more: external aka outer methods for primitive types,
 especially arrays... No?


 Haven't time to deal with those issues at the moment, and I don't think 
 there'll be any movement on them until after 1.0.


(Sigh) , too pity...

I think I don't need to ask about this "too universal" 'auto'
keyword too.

For me everything seems perfect except these three:
'readonly' (string!), 'outer methods' (string!) (are they still work for 
arrays,btw?)
and the 'auto' mess introduced recently.

Andrew Fedoniouk.
http://terrainformatica.com



 Feb 03 2006



 next sibling parent reply "Walter Bright" <newshound digitalmars.com>  writes:


"Andrew Fedoniouk" <news terrainformatica.com> wrote in message 
news:ds1g3o$1d63$1 digitaldaemon.com...

 1) Do nothing and argue that a standard gui is a bad idea.


 Exactly! I don't even know what "standard gui" means.
 Each application (or group of applications) has its own requirement set 
 here.
 "standard" of what for the byte sake?


All standard means is there are is a gui library as part of the D standard, 
it wouldn't be a separate add-on.



 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.


Java started out with just AWT. Without AWT, Java would have gotten nowhere. 
The other gui libraries came along later as the user base expanded. AWT was 
Java's proverbial "chicken" to bootstrap the process. We need one, too. It 
isn't like DWT will be the only gui toolkit ever.


 The point here - even in Java with its "official
 toolkit" (two of them, btw) in real life you will be forced to use your 
 own at the end.


I'm not a bit surprised. Nobody has figured out the last word in gui 
toolkits.


 So the question - what is this "standard GUI" for?


If you like, think of having a standard gui like DWT as useful for 
marketing. It *is* a big win for marketing the language. Quite a lot of 
people think it is necessary before even considering D, therefore it is 
necessary.


 Again, solution could be in building "standard GUI" pyramid
 from reusable blocks like Graphics Package, etc.
 Such blocks will have more chance to be a) accepted widely
 b) to be not thrown away if something will go wrong.
 If you wish we can establish sort of working group
 on creation of such D GUI foundation,
 Graphics Package, etc.
 I am short on time a bit now but will try to do something here
 if we need to.


I think you're probably right, and this would be a better long term solution 
than DWT is, so I encourage you to work on it. But we need something now.


 For me everything seems perfect except these three:
 'readonly' (string!), 'outer methods' (string!) (are they still work for 
 arrays,btw?)


Yes. 



 Feb 03 2006



 next sibling parent reply "Derek Parnell" <derek psych.ward>  writes:


On Sat, 04 Feb 2006 17:58:09 +1100, Walter Bright  
<newshound digitalmars.com> wrote:

[snip]


 I think you're probably right, and this would be a better long term  
 solution
 than DWT is, so I encourage you to work on it. But we need something now.


I think I'm in general agreement with both Andrew and Walter.

I have written a GUI library for Windows in the Euphoria language. Most  
people who use it like it very much. So I figure I better start porting it  
to D. Maybe be later on, some one can add support for other windowing  
systems (eg. Motif) if they want to.

It could bootstap ideas and other libraries.

-- 
Derek Parnell
Melbourne, Australia



 Feb 04 2006



  parent reply "Andrew Fedoniouk" <news terrainformatica.com>  writes:


"Derek Parnell" <derek psych.ward> wrote in message 
news:op.s4f69cx46b8z09 ginger.vic.bigpond.net.au...

 On Sat, 04 Feb 2006 17:58:09 +1100, Walter Bright 
 <newshound digitalmars.com> wrote:

 [snip]


 I think you're probably right, and this would be a better long term 
 solution
 than DWT is, so I encourage you to work on it. But we need something now.


 I think I'm in general agreement with both Andrew and Walter.

 I have written a GUI library for Windows in the Euphoria language. Most 
 people who use it like it very much. So I figure I better start porting it 
 to D. Maybe be later on, some one can add support for other windowing 
 systems (eg. Motif) if they want to.

 It could bootstap ideas and other libraries.

 -- 


Derek, just as a proposal: can we start from defining
Standard D Graphics Toolkit?
Just pure GX package as a basement of foundation?

We need 2D geometry primitives and Graphics per se.
It is really simple and can be accomplished in one month as
we already have similar code in DWT/DFL/MinWin/Harmonia.
+ probably somethng on your side + may be someone else.
So we can assemeble this really quickly.

And to start from opening Wiki page somewhere with
discussion board.
Probably it is better to use news.digitalmars.com/gui as
it is going to be something standard and common.

Andrew. 



 Feb 05 2006



  parent reply Derek Parnell <derek psych.ward>  writes:


On Sun, 5 Feb 2006 17:32:50 -0800, Andrew Fedoniouk wrote:


 Derek, just as a proposal: can we start from defining
 Standard D Graphics Toolkit?
 Just pure GX package as a basement of foundation?


Yes, I suppose so ... but ...


 We need 2D geometry primitives and Graphics per se.
 It is really simple and can be accomplished in one month as
 we already have similar code in DWT/DFL/MinWin/Harmonia.
 + probably somethng on your side + may be someone else.
 So we can assemeble this really quickly.


... the gfx side of a GUI is the easy part. The problematic parts deal with
the behaviour of the widgets and the non-graphic elements. 

My efforts with the "Win32lib for Euphoria" library was focused on making
Windows(tm) programming drop-dead simple to do. And in that I believe I
succeeded quite well. I did not try to do the 'owner-drawn' thing or use a
primitive gfx API to draw widgets; I just used the bog-standard widgets one
gets from Microsoft. Though I did include a mechanism for people to create
brand new widget types if they wanted to.

No attempt was made to make it cross-platform.


 And to start from opening Wiki page somewhere with
 discussion board.
 Probably it is better to use news.digitalmars.com/gui as
 it is going to be something standard and common.


If we were going to do a cross platform GUI for D, we would need to decide
before anything if we are going to use the target platform's default
widgets, or do our own, or a mixture of both.

Over the top of the widget drawing and message passing, we would write the
platform agnostic API for D coders to use. I imagine this would be in a
different library from the primitives, and that the primitives should be
able to be a plug-and-play library loaded at run-time.

So in short, a 2d gfx primitives library would be useful, both for a GUI
library and any other gfx usages (eg. a charting program).

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
6/02/2006 1:27:19 PM



 Feb 05 2006



  parent reply "Andrew Fedoniouk" <news terrainformatica.com>  writes:


"Derek Parnell" <derek psych.ward> wrote in message 
news:1g5f1le84n7dm.74cz12d1zy93$.dlg 40tude.net...

 On Sun, 5 Feb 2006 17:32:50 -0800, Andrew Fedoniouk wrote:


 Derek, just as a proposal: can we start from defining
 Standard D Graphics Toolkit?
 Just pure GX package as a basement of foundation?


 Yes, I suppose so ... but ...


 We need 2D geometry primitives and Graphics per se.
 It is really simple and can be accomplished in one month as
 we already have similar code in DWT/DFL/MinWin/Harmonia.
 + probably somethng on your side + may be someone else.
 So we can assemeble this really quickly.


 ... the gfx side of a GUI is the easy part. The problematic parts deal 
 with
 the behaviour of the widgets and the non-graphic elements.

 My efforts with the "Win32lib for Euphoria" library was focused on making
 Windows(tm) programming drop-dead simple to do. And in that I believe I
 succeeded quite well. I did not try to do the 'owner-drawn' thing or use a
 primitive gfx API to draw widgets; I just used the bog-standard widgets 
 one
 gets from Microsoft. Though I did include a mechanism for people to create
 brand new widget types if they wanted to.

 No attempt was made to make it cross-platform.


 And to start from opening Wiki page somewhere with
 discussion board.
 Probably it is better to use news.digitalmars.com/gui as
 it is going to be something standard and common.


 If we were going to do a cross platform GUI for D, we would need to decide
 before anything if we are going to use the target platform's default
 widgets, or do our own, or a mixture of both.


Let's start from the fact that "Standard D Graphics" has its
own value.
(
 GD package for PHP ( http://ca.php.net/gd ).
 This way SDG can can be used for example in Mango.
 Let's say I have code for rich text editor which
 is loosely coupled with event handling and window
 architecture of any toolkit.
So to use it inside let's say DWT I need a simple
thunk from dwt::GD to std::Graphics and couple
of thunks for events. This is it.
)

So first is SDG as it is really independent module.

Next thing on the road to Standard GUI Framework is

Application Module:
  It contains Application and Window classes.

  Application is a wrapper around main/winmain
  and implementation of message pump. (Get/DispatchMessage)

  Window (or Frame) is a top level OS window.

Application module will not define architecture
of child contols.
This way Application as standard module can be
used in various frameworks - windowed or not.


And after that we can define
OsWidgets module which will contain wrappers
for native OS "controls" - edit boxes, comboboxes, etc.


"Harmonia" (or some other name) Module will
use Graphics and Application modules but will
not contain references to OsWidgets module.
"Harmonia" (windowless, lightweight, declarative, ?


Applications which will use OsWidgets may
or may not use also "Harmonia" module runing
it in "Harmonia"Widget which is child window.
Another applications will not use OsWidgets
and will live happily with windowless GUI only.

As you may see we will have 4 basic modules
so application may choose what it needs.

For example application like notepad.exe
will use Application and OsWidgets modules only and
not even Graphics.

So any time you will have as compact as possible binary.

I am not sure if I expalined this clear enough...


 Over the top of the widget drawing and message passing, we would write the
 platform agnostic API for D coders to use. I imagine this would be in a
 different library from the primitives, and that the primitives should be
 able to be a plug-and-play library loaded at run-time.

 So in short, a 2d gfx primitives library would be useful, both for a GUI
 library and any other gfx usages (eg. a charting program).


Exactly.

Andrew. 



 Feb 05 2006



  parent reply Derek Parnell <derek psych.ward>  writes:


On Sun, 5 Feb 2006 20:31:44 -0800, Andrew Fedoniouk wrote:


[snip]


 Let's start from the fact that "Standard D Graphics" has its
 own value ...
 ... So first is SDG as it is really independent module.
 
 Next thing on the road to Standard GUI Framework is
 
 Application Module:
   It contains Application and Window classes.
 
   Application is a wrapper around main/winmain
   and implementation of message pump. (Get/DispatchMessage)
 
   Window (or Frame) is a top level OS window.
 


 ...  

 And after that we can define
 OsWidgets module ...



 I am not sure if I expalined this clear enough...


I think we are one on this. You have explained it well and I agree with the
strategy.

Have we enough skills to write a fast 2D library or do we leverage off
existing ones? I know I can write a basic graphics library ('cos I've done
it a couple of times already) but I've never had to optimize it to the Nth
degree as I suspect one would have to for general usage. For example, do we
use hardware acceleration when possible or do it all through software? And
do we worry about unusual screen geometries (such as multiple screens
making a single virtual screen)? I assume a stock 2d library would not be
interested in 3d effects (shading, Z-axis, etc...) but it would be
interested in anti-aliasing and alpha-blending.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
6/02/2006 4:11:39 PM



 Feb 05 2006



 next sibling parent reply Kyle Furlong <kylefurlong gmail.com>  writes:


Derek Parnell wrote:

 On Sun, 5 Feb 2006 20:31:44 -0800, Andrew Fedoniouk wrote:
 
 
 [snip]
 

 Let's start from the fact that "Standard D Graphics" has its
 own value ...
 ... So first is SDG as it is really independent module.

 Next thing on the road to Standard GUI Framework is

 Application Module:
   It contains Application and Window classes.

   Application is a wrapper around main/winmain
   and implementation of message pump. (Get/DispatchMessage)

   Window (or Frame) is a top level OS window.


  ...  

 And after that we can define
 OsWidgets module ...


 

 I am not sure if I expalined this clear enough...


 
 I think we are one on this. You have explained it well and I agree with the
 strategy.
 
 Have we enough skills to write a fast 2D library or do we leverage off
 existing ones? I know I can write a basic graphics library ('cos I've done
 it a couple of times already) but I've never had to optimize it to the Nth
 degree as I suspect one would have to for general usage. For example, do we
 use hardware acceleration when possible or do it all through software? And
 do we worry about unusual screen geometries (such as multiple screens
 making a single virtual screen)? I assume a stock 2d library would not be
 interested in 3d effects (shading, Z-axis, etc...) but it would be
 interested in anti-aliasing and alpha-blending.
 


Any graphics library should leverage as much of the current hardware as
possible. What I think this means is that the graphics 
should use opengl as a base, ala Terra.



 Feb 05 2006



  parent reply Oskar Linde <oskar.lindeREM OVEgmail.com>  writes:


I agree that this seems a good path to follow. A 2D graphics library 
would be useful even without a GUI.

Kyle Furlong wrote:

 Derek Parnell wrote:



 Have we enough skills to write a fast 2D library or do we leverage off
 existing ones? I know I can write a basic graphics library ('cos I've 
 done
 it a couple of times already) but I've never had to optimize it to the 
 Nth
 degree as I suspect one would have to for general usage. For example, 
 do we
 use hardware acceleration when possible or do it all through software? 
 And
 do we worry about unusual screen geometries (such as multiple screens
 making a single virtual screen)? I assume a stock 2d library would not be
 interested in 3d effects (shading, Z-axis, etc...) but it would be
 interested in anti-aliasing and alpha-blending.


 
 Any graphics library should leverage as much of the current hardware as 
 possible. What I think this means is that the graphics should use opengl 
 as a base, ala Terra.


IMHO, a generic 2d graphics library such as this should support multiple 
backends. The most important one would be a (possibly non-accelerated) 
pixel-based backend usable even without a graphics card. Other backends 
such as OpenGL, GDI, X11, PostScript, SVG, and more should be 
implementable later on. The important thing is to make the correct 
abstraction that makes it possible to use the hardware acceleration 
possible in the different backends.

The correct abstraction depth is not always easy to find, but it is 
probably best to be at about the same level as other 2D libraries. 
(Briefly: support different pens and brushes and be able do draw points, 
lines, polygons, ellipses, bitmap images and text on an abstract surface.)

I also think everyone expects a modern 2d graphics library to support 
alpha blending and anti-aliased rendering. (The latter could be up to 
the backend.)

Looking at existing libraries, it is probably not hard to draw up the 
specifications.

Regards,

Oskar



 Feb 06 2006



 next sibling parent  Mike Capp <mike.capp gmail.com>  writes:


In article <ds7dv4$2n9k$1 digitaldaemon.com>, Oskar Linde says...

IMHO, a generic 2d graphics library such as this should support multiple 
backends. The most important one would be a (possibly non-accelerated) 
pixel-based backend usable even without a graphics card. Other backends 
such as OpenGL, GDI, X11, PostScript, SVG, and more should be 
implementable later on. The important thing is to make the correct 
abstraction that makes it possible to use the hardware acceleration 
possible in the different backends.


Something like Cairo (http://www.cairographics.org/) would seem to fit the bill
nicely. And it's written in C, so should be relatively easy to use from D.



 Feb 06 2006



prev sibling  parent  Lurker <Lurker_member pathlink.com>  writes:


Here are a few links.

Visual Component Framework
http://vcf-online.org/

Uses AGG (Anti-Grain Geometry for all rendering)

through the AntiGrain Geometry library. 
A theme manager allows to change the appearance of the user interface
http://www.creativedocs.net/devs/gui

AGG is very good and easy to use backend.

Cairo Graphics (good engine but I'm not comfortable with it)
http://www.cairographics.org/introduction



 Feb 06 2006



prev sibling  parent reply "Andrew Fedoniouk" <news terrainformatica.com>  writes:


"Derek Parnell" <derek psych.ward> wrote in message 
news:e2nam8zl4e3k$.1htyv23ne0hg2.dlg 40tude.net...

 On Sun, 5 Feb 2006 20:31:44 -0800, Andrew Fedoniouk wrote:


 [snip]


 Let's start from the fact that "Standard D Graphics" has its
 own value ...
 ... So first is SDG as it is really independent module.

 Next thing on the road to Standard GUI Framework is

 Application Module:
   It contains Application and Window classes.

   Application is a wrapper around main/winmain
   and implementation of message pump. (Get/DispatchMessage)

   Window (or Frame) is a top level OS window.


 ...

 And after that we can define
 OsWidgets module ...



 I am not sure if I expalined this clear enough...


 I think we are one on this. You have explained it well and I agree with 
 the
 strategy.

 Have we enough skills to write a fast 2D library or do we leverage off
 existing ones? I know I can write a basic graphics library ('cos I've done
 it a couple of times already) but I've never had to optimize it to the Nth
 degree as I suspect one would have to for general usage. For example, do 
 we
 use hardware acceleration when possible or do it all through software? And
 do we worry about unusual screen geometries (such as multiple screens
 making a single virtual screen)? I assume a stock 2d library would not be
 interested in 3d effects (shading, Z-axis, etc...) but it would be
 interested in anti-aliasing and alpha-blending.


I thought about something different.

Typical implementation is:

Two classes:
Graphics and GraphicsEx : Graphics
and interface ISurface.

Graphics is a set of basic functions to draw on some
surface. GraphicsEx is a set of extended functions,
in Java it is known as Graphics2D - extended set for
vector drawings - antialiasing and extended line styles,
transformations etc.

Graphics in Windows is a pretty much wrapper of
HDC functions, ISurface is a HDC handler provider:
Objects like Window, Image and Printer implement
ISurface.

GraphicsEx (2D) could be a wrapper of GDI+, OpenGL,
Quartz2D, AGG or DirectX derived gfx subsystem of Vista.

The idea is simple: for UI implementation
you need only Graphics (like in Harmonia I use only 10 or so
graphic functions). For various vector graphic tasks you will
need GraphicsEx.

Having them both will allow to use only what is needed.
As GraphicsEx is a Graphics too thus you can draw your
UI on e.g. OpenGL surfaces if needed.

Graphics has concrete implementations
for each platform : on windows it is Graphics:Win32Graphics
or even Graphics:GC on DWT if DWT will need to use some
components knowing only about Graphics.

Even on the same platform there are multiple rendering
engines available. Graphics[Ex] will alow to cover them.
I don't think that we need to implement low level drawing.
It would be too much for most of practical cases.
For sure we shall cover at least official OS
drawing primitives GDI/GDI+  and DirectDraw/Quarts2D.

Andrew Fedoniouk.
http://terrainformatica.com



 Feb 06 2006



  parent reply Bruno Medeiros <daiphoenixNO SPAMlycos.com>  writes:


Andrew Fedoniouk wrote:

 "Derek Parnell" <derek psych.ward> wrote in message 
 news:e2nam8zl4e3k$.1htyv23ne0hg2.dlg 40tude.net...

 On Sun, 5 Feb 2006 20:31:44 -0800, Andrew Fedoniouk wrote:


 [snip]


 Let's start from the fact that "Standard D Graphics" has its
 own value ...
 ... So first is SDG as it is really independent module.

 Next thing on the road to Standard GUI Framework is

 Application Module:
   It contains Application and Window classes.

   Application is a wrapper around main/winmain
   and implementation of message pump. (Get/DispatchMessage)

   Window (or Frame) is a top level OS window.


 ...

 And after that we can define
 OsWidgets module ...
 I am not sure if I expalined this clear enough...


 I think we are one on this. You have explained it well and I agree with 
 the
 strategy.

 Have we enough skills to write a fast 2D library or do we leverage off
 existing ones? I know I can write a basic graphics library ('cos I've done
 it a couple of times already) but I've never had to optimize it to the Nth
 degree as I suspect one would have to for general usage. For example, do 
 we
 use hardware acceleration when possible or do it all through software? And
 do we worry about unusual screen geometries (such as multiple screens
 making a single virtual screen)? I assume a stock 2d library would not be
 interested in 3d effects (shading, Z-axis, etc...) but it would be
 interested in anti-aliasing and alpha-blending.


 
 I thought about something different.
 
 Typical implementation is:
 
 Two classes:
 Graphics and GraphicsEx : Graphics
 and interface ISurface.
 
 Graphics is a set of basic functions to draw on some
 surface. GraphicsEx is a set of extended functions,
 in Java it is known as Graphics2D - extended set for
 vector drawings - antialiasing and extended line styles,
 transformations etc.
 
 Graphics in Windows is a pretty much wrapper of
 HDC functions, ISurface is a HDC handler provider:
 Objects like Window, Image and Printer implement
 ISurface.
 
 GraphicsEx (2D) could be a wrapper of GDI+, OpenGL,
 Quartz2D, AGG or DirectX derived gfx subsystem of Vista.
 
 The idea is simple: for UI implementation
 you need only Graphics (like in Harmonia I use only 10 or so
 graphic functions). For various vector graphic tasks you will
 need GraphicsEx.
 
 Having them both will allow to use only what is needed.
 As GraphicsEx is a Graphics too thus you can draw your
 UI on e.g. OpenGL surfaces if needed.
 
 Graphics has concrete implementations
 for each platform : on windows it is Graphics:Win32Graphics
 or even Graphics:GC on DWT if DWT will need to use some
 components knowing only about Graphics.
 
 Even on the same platform there are multiple rendering
 engines available. Graphics[Ex] will alow to cover them.
 I don't think that we need to implement low level drawing.
 It would be too much for most of practical cases.
 For sure we shall cover at least official OS
 drawing primitives GDI/GDI+  and DirectDraw/Quarts2D.
 
 Andrew Fedoniouk.
 http://terrainformatica.com
 


Let the first say I find quite good this idea of having a common (i.e. 
standard) primitive graphics library in D. Not only because it is more 
readily available, but especially because it can later be used upon to 
build higher level libraries like the advanced graphics lib or a GUI 
lib, with a higher degree of unification. (For instance there could be 
several GUI libs, but nonetheless they would share the same graphic 
primitives).

As for this primitive graphics library, there already exists one, (made 
in C), and it not only exists, but it is *The* library. I hope you know 
which one I'm talking about, and I hope too that you realize that your 
work should be to make a D layer/version of this lib. Not a direct C 
wrapper, as that already exists, but one to make use of the relevant D's 
prime features (OO and structured namespacing)


-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to 
be... unnatural."



 Feb 06 2006



 next sibling parent  "Andrew Fedoniouk" <news terrainformatica.com>  writes:


 As for this primitive graphics library, there already exists one, (made in 
 C), and it not only exists, but it is *The* library. I hope you know which 
 one I'm talking about, and I hope too that you realize that your work 
 should be to make a D layer/version of this lib. Not a direct C wrapper, 
 as that already exists, but one to make use of the relevant D's prime 
 features (OO and structured namespacing)


Sorry, I don't know what is *The* library.
OpenGL probably?

If yes then it is overkill to use it for drawing e.g. one particular custom 
button
in let's say some IDE. (I am assuming that all other UI in IDE is using only 
standard
set of native OS widgets).

Ideally Standard D Graphics Module/Package shall allow
to do basic drawing without any third party library and
use only OS native primitives.

Nobody will want to create a calculator.exe which will
*always* require installation of some additional DLLs or new version
of the Framework.

Andrew.



 Feb 06 2006



prev sibling next sibling parent reply clayasaurus <clayasaurus gmail.com>  writes:


Bruno Medeiros wrote:

 Andrew Fedoniouk wrote:

 "Derek Parnell" <derek psych.ward> wrote in message 
 news:e2nam8zl4e3k$.1htyv23ne0hg2.dlg 40tude.net...

 On Sun, 5 Feb 2006 20:31:44 -0800, Andrew Fedoniouk wrote:


 [snip]


 Let's start from the fact that "Standard D Graphics" has its
 own value ...
 ... So first is SDG as it is really independent module.

 Next thing on the road to Standard GUI Framework is

 Application Module:
   It contains Application and Window classes.

   Application is a wrapper around main/winmain
   and implementation of message pump. (Get/DispatchMessage)

   Window (or Frame) is a top level OS window.


 ...

 And after that we can define
 OsWidgets module ...
 I am not sure if I expalined this clear enough...


 I think we are one on this. You have explained it well and I agree 
 with the
 strategy.

 Have we enough skills to write a fast 2D library or do we leverage off
 existing ones? I know I can write a basic graphics library ('cos I've 
 done
 it a couple of times already) but I've never had to optimize it to 
 the Nth
 degree as I suspect one would have to for general usage. For example, 
 do we
 use hardware acceleration when possible or do it all through 
 software? And
 do we worry about unusual screen geometries (such as multiple screens
 making a single virtual screen)? I assume a stock 2d library would 
 not be
 interested in 3d effects (shading, Z-axis, etc...) but it would be
 interested in anti-aliasing and alpha-blending.


 I thought about something different.

 Typical implementation is:

 Two classes:
 Graphics and GraphicsEx : Graphics
 and interface ISurface.

 Graphics is a set of basic functions to draw on some
 surface. GraphicsEx is a set of extended functions,
 in Java it is known as Graphics2D - extended set for
 vector drawings - antialiasing and extended line styles,
 transformations etc.

 Graphics in Windows is a pretty much wrapper of
 HDC functions, ISurface is a HDC handler provider:
 Objects like Window, Image and Printer implement
 ISurface.

 GraphicsEx (2D) could be a wrapper of GDI+, OpenGL,
 Quartz2D, AGG or DirectX derived gfx subsystem of Vista.

 The idea is simple: for UI implementation
 you need only Graphics (like in Harmonia I use only 10 or so
 graphic functions). For various vector graphic tasks you will
 need GraphicsEx.

 Having them both will allow to use only what is needed.
 As GraphicsEx is a Graphics too thus you can draw your
 UI on e.g. OpenGL surfaces if needed.

 Graphics has concrete implementations
 for each platform : on windows it is Graphics:Win32Graphics
 or even Graphics:GC on DWT if DWT will need to use some
 components knowing only about Graphics.

 Even on the same platform there are multiple rendering
 engines available. Graphics[Ex] will alow to cover them.
 I don't think that we need to implement low level drawing.
 It would be too much for most of practical cases.
 For sure we shall cover at least official OS
 drawing primitives GDI/GDI+  and DirectDraw/Quarts2D.

 Andrew Fedoniouk.
 http://terrainformatica.com


 
 Let the first say I find quite good this idea of having a common (i.e. 
 standard) primitive graphics library in D. Not only because it is more 
 readily available, but especially because it can later be used upon to 
 build higher level libraries like the advanced graphics lib or a GUI 
 lib, with a higher degree of unification. (For instance there could be 
 several GUI libs, but nonetheless they would share the same graphic 
 primitives).
 
 As for this primitive graphics library, there already exists one, (made 
 in C), and it not only exists, but it is *The* library. I hope you know 
 which one I'm talking about, and I hope too that you realize that your 
 work should be to make a D layer/version of this lib. Not a direct C 
 wrapper, as that already exists, but one to make use of the relevant D's 
 prime features (OO and structured namespacing)
 
 


Are you talking about GTK? If so, maybe you should check out DUI. ( 
www.dsource.org/projects/dui )



 Feb 06 2006



  parent  John Reimer <terminal.node gmail.com>  writes:


clayasaurus wrote:


 Let the first say I find quite good this idea of having a common (i.e. 
 standard) primitive graphics library in D. Not only because it is more 
 readily available, but especially because it can later be used upon to 
 build higher level libraries like the advanced graphics lib or a GUI 
 lib, with a higher degree of unification. (For instance there could be 
 several GUI libs, but nonetheless they would share the same graphic 
 primitives).

 As for this primitive graphics library, there already exists one, 
 (made in C), and it not only exists, but it is *The* library. I hope 
 you know which one I'm talking about, and I hope too that you realize 
 that your work should be to make a D layer/version of this lib. Not a 
 direct C wrapper, as that already exists, but one to make use of the 
 relevant D's prime features (OO and structured namespacing)


 
 Are you talking about GTK? If so, maybe you should check out DUI. ( 
 www.dsource.org/projects/dui )



I think he means Cairo.

GTK is a gui library... not a graphics primitive library.

-JJR



 Feb 06 2006



prev sibling  parent reply Bruno Medeiros <daiphoenixNO SPAMlycos.com>  writes:


Bruno Medeiros wrote:

 Andrew Fedoniouk wrote:

 I thought about something different.

 Typical implementation is:

 Two classes:
 Graphics and GraphicsEx : Graphics
 and interface ISurface.

 Graphics is a set of basic functions to draw on some
 surface. GraphicsEx is a set of extended functions,
 in Java it is known as Graphics2D - extended set for
 vector drawings - antialiasing and extended line styles,
 transformations etc.

 Graphics in Windows is a pretty much wrapper of
 HDC functions, ISurface is a HDC handler provider:
 Objects like Window, Image and Printer implement
 ISurface.

 GraphicsEx (2D) could be a wrapper of GDI+, OpenGL,
 Quartz2D, AGG or DirectX derived gfx subsystem of Vista.

 The idea is simple: for UI implementation
 you need only Graphics (like in Harmonia I use only 10 or so
 graphic functions). For various vector graphic tasks you will
 need GraphicsEx.

 Having them both will allow to use only what is needed.
 As GraphicsEx is a Graphics too thus you can draw your
 UI on e.g. OpenGL surfaces if needed.

 Graphics has concrete implementations
 for each platform : on windows it is Graphics:Win32Graphics
 or even Graphics:GC on DWT if DWT will need to use some
 components knowing only about Graphics.

 Even on the same platform there are multiple rendering
 engines available. Graphics[Ex] will alow to cover them.
 I don't think that we need to implement low level drawing.
 It would be too much for most of practical cases.
 For sure we shall cover at least official OS
 drawing primitives GDI/GDI+  and DirectDraw/Quarts2D.

 Andrew Fedoniouk.
 http://terrainformatica.com


 
 Let the first say I find quite good this idea of having a common (i.e. 
 standard) primitive graphics library in D. Not only because it is more 
 readily available, but especially because it can later be used upon to 
 build higher level libraries like the advanced graphics lib or a GUI 
 lib, with a higher degree of unification. (For instance there could be 
 several GUI libs, but nonetheless they would share the same graphic 
 primitives).
 
 As for this primitive graphics library, there already exists one, (made 
 in C), and it not only exists, but it is *The* library. I hope you know 
 which one I'm talking about, and I hope too that you realize that your 
 work should be to make a D layer/version of this lib. Not a direct C 
 wrapper, as that already exists, but one to make use of the relevant D's 
 prime features (OO and structured namespacing)
 
 


No, I wasn't thinking about GTK (which is a GUI library), nor Cairo 
(which is a vector library, still not primitive), nor OpenGL (related 
though)

I was thinking of SDL (Simple DirectMedia Layer, www.libsdl.org).
For those who don't know, SDL is a cross-platform multimedia library 
designed to provide low level access to 2D video surfaces(framebuffers) 
and 3D hardware via OpenGL (as well as audio, keyboard, mouse, 
joystick). In terms of graphics, it only provides the means to open a 
surface/framebuffer that you can write to, plus related functionality, 
like datatypes and conversions related to color encondings/channels 
etc.) It is available in many platforms, more than D is.

There are other libraries who provide similar functionality (like GLUT 
f.e.), but SDL is *the* library. It was used in entirety in some 
commercial games like Civilization, or (more recently), in the Linux 
ports of the Unreal Tournament games. The maintainer of the library (Sam 
Latinga) works for Blizzard Entertainment in World of Warcraft.
It is used in the ABA games made in D (those japanese arcade style 
games). I reckon this may have been one of the first libraries (together 
with OpenGL) that a import header was made.

So, using SDL as a rendering backend (and adapting it's design to D) 
might be interesting for whatever higher-level graphics libraries one 
wants to implement. There are some disadvantages though. There is no 
access to native widgets (naturally) and SDL only allows one window to 
be created (they're considering changing that in a future version).

Still, it *might* (depending on how it's done) be interesting to have a 
D framework for all those concepts (like color, surface/canvas, etc.) 
that are common to all graphics libraries, high-level or not, 
native-widgets or not.

-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to 
be... unnatural."



 Feb 09 2006



 next sibling parent  "Andrew Fedoniouk" <news terrainformatica.com>  writes:


"Bruno Medeiros" <daiphoenixNO SPAMlycos.com> wrote in message 
news:dsg9rh$2ce6$1 digitaldaemon.com...

 Bruno Medeiros wrote:

 Andrew Fedoniouk wrote:

 I thought about something different.

 Typical implementation is:

 Two classes:
 Graphics and GraphicsEx : Graphics
 and interface ISurface.

 Graphics is a set of basic functions to draw on some
 surface. GraphicsEx is a set of extended functions,
 in Java it is known as Graphics2D - extended set for
 vector drawings - antialiasing and extended line styles,
 transformations etc.

 Graphics in Windows is a pretty much wrapper of
 HDC functions, ISurface is a HDC handler provider:
 Objects like Window, Image and Printer implement
 ISurface.

 GraphicsEx (2D) could be a wrapper of GDI+, OpenGL,
 Quartz2D, AGG or DirectX derived gfx subsystem of Vista.

 The idea is simple: for UI implementation
 you need only Graphics (like in Harmonia I use only 10 or so
 graphic functions). For various vector graphic tasks you will
 need GraphicsEx.

 Having them both will allow to use only what is needed.
 As GraphicsEx is a Graphics too thus you can draw your
 UI on e.g. OpenGL surfaces if needed.

 Graphics has concrete implementations
 for each platform : on windows it is Graphics:Win32Graphics
 or even Graphics:GC on DWT if DWT will need to use some
 components knowing only about Graphics.

 Even on the same platform there are multiple rendering
 engines available. Graphics[Ex] will alow to cover them.
 I don't think that we need to implement low level drawing.
 It would be too much for most of practical cases.
 For sure we shall cover at least official OS
 drawing primitives GDI/GDI+  and DirectDraw/Quarts2D.

 Andrew Fedoniouk.
 http://terrainformatica.com


 Let the first say I find quite good this idea of having a common (i.e. 
 standard) primitive graphics library in D. Not only because it is more 
 readily available, but especially because it can later be used upon to 
 build higher level libraries like the advanced graphics lib or a GUI lib, 
 with a higher degree of unification. (For instance there could be several 
 GUI libs, but nonetheless they would share the same graphic primitives).

 As for this primitive graphics library, there already exists one, (made 
 in C), and it not only exists, but it is *The* library. I hope you know 
 which one I'm talking about, and I hope too that you realize that your 
 work should be to make a D layer/version of this lib. Not a direct C 
 wrapper, as that already exists, but one to make use of the relevant D's 
 prime features (OO and structured namespacing)


 No, I wasn't thinking about GTK (which is a GUI library), nor Cairo (which 
 is a vector library, still not primitive), nor OpenGL (related though)

 I was thinking of SDL (Simple DirectMedia Layer, www.libsdl.org).
 For those who don't know, SDL is a cross-platform multimedia library 
 designed to provide low level access to 2D video surfaces(framebuffers) 
 and 3D hardware via OpenGL (as well as audio, keyboard, mouse, joystick). 
 In terms of graphics, it only provides the means to open a 
 surface/framebuffer that you can write to, plus related functionality, 
 like datatypes and conversions related to color encondings/channels etc.) 
 It is available in many platforms, more than D is.

 There are other libraries who provide similar functionality (like GLUT 
 f.e.), but SDL is *the* library. It was used in entirety in some 
 commercial games like Civilization, or (more recently), in the Linux ports 
 of the Unreal Tournament games. The maintainer of the library (Sam 
 Latinga) works for Blizzard Entertainment in World of Warcraft.
 It is used in the ABA games made in D (those japanese arcade style games). 
 I reckon this may have been one of the first libraries (together with 
 OpenGL) that a import header was made.

 So, using SDL as a rendering backend (and adapting it's design to D) might 
 be interesting for whatever higher-level graphics libraries one wants to 
 implement. There are some disadvantages though. There is no access to 
 native widgets (naturally) and SDL only allows one window to be created 
 (they're considering changing that in a future version).

 Still, it *might* (depending on how it's done) be interesting to have a D 
 framework for all those concepts (like color, surface/canvas, etc.) that 
 are common to all graphics libraries, high-level or not, native-widgets or 
 not.


class Graphics
{
    IGraphicsImpl impl; // GDI, GDI+, OpenGL(SDL), etc.
};

is the only way to have *standard* Graphics package used
in many toolkits and toolkit-less apllications so why is "might"?

Andrew.


 -- 
 Bruno Medeiros - CS/E student
 "Certain aspects of D are a pathway to many abilities some consider to 
 be... unnatural."





 Feb 09 2006



prev sibling  parent  "Andrew Fedoniouk" <news terrainformatica.com>  writes:


Probably this will be interesting to you too:

GLUI:
http://www.cs.unc.edu/~rademach/glui/

<quote>
GLUI is a GLUT-based C++ user interface library which provides controls such 
as buttons, checkboxes, radio buttons, and spinners to OpenGL applications. 
It is window-system independent, relying on GLUT to handle all 
system-dependent issues, such as window and mouse management. Features of 
the GLUI User Interface Library include
</quote>



 Feb 10 2006



prev sibling next sibling parent reply "Andrew Fedoniouk" <news terrainformatica.com>  writes:


"Walter Bright" <newshound digitalmars.com> wrote in message 
news:ds1ksm$1fo6$1 digitaldaemon.com...

 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message 
 news:ds1g3o$1d63$1 digitaldaemon.com...

 1) Do nothing and argue that a standard gui is a bad idea.


 Exactly! I don't even know what "standard gui" means.
 Each application (or group of applications) has its own requirement set 
 here.
 "standard" of what for the byte sake?


 All standard means is there are is a gui library as part of the D 
 standard, it wouldn't be a separate add-on.


Again, if marketing people
think that it will benefit D significantly then I will
vote by two hands too.


 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.


 Java started out with just AWT. Without AWT, Java would have gotten 
 nowhere. The other gui libraries came along later as the user base 
 expanded. AWT was Java's proverbial "chicken" to bootstrap the process. We 
 need one, too. It isn't like DWT will be the only gui toolkit ever.


AWT is a minimal window toolkit. And abstract.
Abstract is a synonym of the egg here I beleive.
And MinWin by its feature set is close to AWT more than
anything else.

It has minimal Application framework allowing beginers
to easily start from something.
I would strip from there Graphics with some its redesign
aimed to generalization and with Standard D Graphics in mind.
And would declare it and  SDG as D GUI Foundation.

Generally speaking design of "Standard D GUI" as a task
is quite different from what authors of DWT/SWT, DFL
and myself had in their minds.

Design goal of "Standard D GUI" at the first place
should be to create foundation (bootstrap and not a complete
 widget set) - to define only  set of basic classes like
Application (winmain encapsulation),
generic Window and generic event handling.
This is what all toolkits have in common anyway and may use.

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.

Conseptually AWT is very good thing - it is classical in "GUI
science". But its practical implementation....

I beleive that compact version of AWT implemented in
D with all its power and compactness is what D needs now.
Simple and clean. AWT supported by all OS vendors
and there a lot of its implementations where OS specific code
can be borrowed.

Again, main goal is not in creation of particular widget set
(e.g. for creation of some IDE like Eclipse) but to be a
common denominator different types of applications
(frameworks, toolkits) can use as a basis.

Andrew Fedoniouk.
http://terrainformatica.com



 Feb 04 2006



  parent reply kris <fu bar.org>  writes:


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.



 Feb 04 2006



  parent reply "Andrew Fedoniouk" <news terrainformatica.com>  writes:


"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



 Feb 04 2006



  parent reply "Charles" <noone nowhere.com>  writes:


 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





 Feb 05 2006



  parent reply "Andrew Fedoniouk" <news terrainformatica.com>  writes:


"Charles" <noone nowhere.com> wrote in message 
news:ds5b72$124c$1 digitaldaemon.com...

 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.


Oh, thanks a lot.
Next question: what applications from the list you are using personally?



 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.


Negative.

SWT is nearly ideal for the task it was designed for -
extendable IDE environment for Java.

I am not using it though.
I need performance at first and I am not interested
in other bells and whistles.

I am using native code IDEs if you will ask me.
For commercial project we did recently -
Microsoft VisualJ (Visual Studio) - still the best IDE and debugger (deep 
IMHO)
And GEL for private java projects (http://www.gexperts.com/)


 Out of curiousity, what is your ideal GUI toolkit ?


For what? That is the question....
Each task has its own ideal toolkit. No silver bullet in principle.

For BlockNote[.net] I was using WTL as I had design goal to
create native Windows application - drop-in replacement of
notepad.exe and wordpad.exe but for HTML.  So it should
look natively for windows.

WTL is just thin set of templates wrapping HWND and using
native look and feel as much as possible.
HTML engine in BlockNote by itself is using its own set of classes - its own
toolkit.

And next version of BlockNote will appear as a set of HTML/CSS/Script
files running in some "smart client" application I am designing now.
You may think about http://www.terrainformatica.com/htmlayout/
as a GUI toolkit for new BlockNote.
Sort of http://www.terrainformatica.com/htmlayout/images/image5.png

Time changed and as do requirements. I've got a lot of customization
request for example. Having application defined as set of
HTML/CSS/Script declarations opens it for customizations, extnesions
and integration with legacy systems.

I extended CSS (cascading style sheets) to serve better
apllication UI purposes. E.g. simple animation has been added.
See screenshots http://www.terrainformatica.com/htmlayout/screenshots.whtm
or download demo from the site.

Andrew.



 Feb 05 2006



  parent reply "Charles" <noone nowhere.com>  writes:


 Oh, thanks a lot.
 Next question: what applications from the list you are using personally?


I use rssowl.

And actually I spoke too soon , SWT is not as popular as I thought it was ,
though I still think its a solid GUI kit.


 I am not using it though.
 I need performance at first and I am not interested
 in other bells and whistles.


DWT is likely faster than SWT , I notice a marginal difference on my local
machine.


 For what? That is the question....
 Each task has its own ideal toolkit. No silver bullet in principle.


Your right, and having DWT as 'The Standard' won't stop people from using
others.  I think having DWT as a standard is more of a marketing move.



 Time changed and as do requirements. I've got a lot of customization
 request for example. Having application defined as set of
 HTML/CSS/Script declarations opens it for customizations, extnesions
 and integration with legacy systems.


I think HTMLLayout and Harmonia are simply gorgeous ( I cant find a download
for harmonia anymore ? http://www.terrainformatica.com/harmonia/ ) , and I
like the idea behind it. I hope you continue developing harmonia.

Charlie



"Andrew Fedoniouk" <news terrainformatica.com> wrote in message
news:ds5scd$1hak$1 digitaldaemon.com...

 "Charles" <noone nowhere.com> wrote in message
 news:ds5b72$124c$1 digitaldaemon.com...

 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.


 Oh, thanks a lot.
 Next question: what applications from the list you are using personally?






http://www.amazon.com/exec/obidos/search-handle-url/ref=br_ss_hs/103-0362120

 -4087815?platform=gurupa&url=index%3Dstripbooks%3Arelevance-above%26dispat


ch

 %3Dsearch%26results-process%3Dbin&field-keywords=swt&Go.x=8&Go.y=8

 I think your greatly underestimating SWT.


 Negative.

 SWT is nearly ideal for the task it was designed for -
 extendable IDE environment for Java.

 I am not using it though.
 I need performance at first and I am not interested
 in other bells and whistles.

 I am using native code IDEs if you will ask me.
 For commercial project we did recently -
 Microsoft VisualJ (Visual Studio) - still the best IDE and debugger (deep
 IMHO)
 And GEL for private java projects (http://www.gexperts.com/)


 Out of curiousity, what is your ideal GUI toolkit ?


 For what? That is the question....
 Each task has its own ideal toolkit. No silver bullet in principle.

 For BlockNote[.net] I was using WTL as I had design goal to
 create native Windows application - drop-in replacement of
 notepad.exe and wordpad.exe but for HTML.  So it should
 look natively for windows.

 WTL is just thin set of templates wrapping HWND and using
 native look and feel as much as possible.
 HTML engine in BlockNote by itself is using its own set of classes - its


own

 toolkit.

 And next version of BlockNote will appear as a set of HTML/CSS/Script
 files running in some "smart client" application I am designing now.
 You may think about http://www.terrainformatica.com/htmlayout/
 as a GUI toolkit for new BlockNote.
 Sort of http://www.terrainformatica.com/htmlayout/images/image5.png

 Time changed and as do requirements. I've got a lot of customization
 request for example. Having application defined as set of
 HTML/CSS/Script declarations opens it for customizations, extnesions
 and integration with legacy systems.

 I extended CSS (cascading style sheets) to serve better
 apllication UI purposes. E.g. simple animation has been added.
 See screenshots http://www.terrainformatica.com/htmlayout/screenshots.whtm
 or download demo from the site.

 Andrew.





 Feb 05 2006



 next sibling parent reply Kyle Furlong <kylefurlong gmail.com>  writes:


Charles wrote:

 Oh, thanks a lot.
 Next question: what applications from the list you are using personally?


 
 I use rssowl.
 
 And actually I spoke too soon , SWT is not as popular as I thought it was ,
 though I still think its a solid GUI kit.
 

 I am not using it though.
 I need performance at first and I am not interested
 in other bells and whistles.


 
 DWT is likely faster than SWT , I notice a marginal difference on my local
 machine.
 

 For what? That is the question....
 Each task has its own ideal toolkit. No silver bullet in principle.


 
 Your right, and having DWT as 'The Standard' won't stop people from using
 others.  I think having DWT as a standard is more of a marketing move.
 
 

 Time changed and as do requirements. I've got a lot of customization
 request for example. Having application defined as set of
 HTML/CSS/Script declarations opens it for customizations, extnesions
 and integration with legacy systems.


 
 I think HTMLLayout and Harmonia are simply gorgeous ( I cant find a download
 for harmonia anymore ? http://www.terrainformatica.com/harmonia/ ) , and I
 like the idea behind it. I hope you continue developing harmonia.
 
 Charlie
 
 
 
 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message
 news:ds5scd$1hak$1 digitaldaemon.com...

 "Charles" <noone nowhere.com> wrote in message
 news:ds5b72$124c$1 digitaldaemon.com...

 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.


 Oh, thanks a lot.
 Next question: what applications from the list you are using personally?






 http://www.amazon.com/exec/obidos/search-handle-url/ref=br_ss_hs/103-0362120

 -4087815?platform=gurupa&url=index%3Dstripbooks%3Arelevance-above%26dispat


 ch

 %3Dsearch%26results-process%3Dbin&field-keywords=swt&Go.x=8&Go.y=8

 I think your greatly underestimating SWT.


 Negative.

 SWT is nearly ideal for the task it was designed for -
 extendable IDE environment for Java.

 I am not using it though.
 I need performance at first and I am not interested
 in other bells and whistles.

 I am using native code IDEs if you will ask me.
 For commercial project we did recently -
 Microsoft VisualJ (Visual Studio) - still the best IDE and debugger (deep
 IMHO)
 And GEL for private java projects (http://www.gexperts.com/)


 Out of curiousity, what is your ideal GUI toolkit ?


 For what? That is the question....
 Each task has its own ideal toolkit. No silver bullet in principle.

 For BlockNote[.net] I was using WTL as I had design goal to
 create native Windows application - drop-in replacement of
 notepad.exe and wordpad.exe but for HTML.  So it should
 look natively for windows.

 WTL is just thin set of templates wrapping HWND and using
 native look and feel as much as possible.
 HTML engine in BlockNote by itself is using its own set of classes - its


 own

 toolkit.

 And next version of BlockNote will appear as a set of HTML/CSS/Script
 files running in some "smart client" application I am designing now.
 You may think about http://www.terrainformatica.com/htmlayout/
 as a GUI toolkit for new BlockNote.
 Sort of http://www.terrainformatica.com/htmlayout/images/image5.png

 Time changed and as do requirements. I've got a lot of customization
 request for example. Having application defined as set of
 HTML/CSS/Script declarations opens it for customizations, extnesions
 and integration with legacy systems.

 I extended CSS (cascading style sheets) to serve better
 apllication UI purposes. E.g. simple animation has been added.
 See screenshots http://www.terrainformatica.com/htmlayout/screenshots.whtm
 or download demo from the site.

 Andrew.


 
 


You can get the source through the svn server Andrew has posted there.



 Feb 05 2006



  parent  Hasan Aljudy <hasan.aljudy gmail.com>  writes:


Kyle Furlong wrote:

 Charles wrote:
 

 Oh, thanks a lot.
 Next question: what applications from the list you are using personally?



 I use rssowl.

 And actually I spoke too soon , SWT is not as popular as I thought it 
 was ,
 though I still think its a solid GUI kit.


 I am not using it though.
 I need performance at first and I am not interested
 in other bells and whistles.



 DWT is likely faster than SWT , I notice a marginal difference on my 
 local
 machine.


 For what? That is the question....
 Each task has its own ideal toolkit. No silver bullet in principle.



 Your right, and having DWT as 'The Standard' won't stop people from using
 others.  I think having DWT as a standard is more of a marketing move.



 Time changed and as do requirements. I've got a lot of customization
 request for example. Having application defined as set of
 HTML/CSS/Script declarations opens it for customizations, extnesions
 and integration with legacy systems.



 I think HTMLLayout and Harmonia are simply gorgeous ( I cant find a 
 download
 for harmonia anymore ? http://www.terrainformatica.com/harmonia/ ) , 
 and I
 like the idea behind it. I hope you continue developing harmonia.

 Charlie



 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message
 news:ds5scd$1hak$1 digitaldaemon.com...


 "Charles" <noone nowhere.com> wrote in message
 news:ds5b72$124c$1 digitaldaemon.com...


 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.


 Oh, thanks a lot.
 Next question: what applications from the list you are using personally?






 http://www.amazon.com/exec/obidos/search-handle-url/ref=br_ss_hs/103-0362120 



 -4087815?platform=gurupa&url=index%3Dstripbooks%3Arelevance-above%26dispat 


 ch


 %3Dsearch%26results-process%3Dbin&field-keywords=swt&Go.x=8&Go.y=8

 I think your greatly underestimating SWT.


 Negative.

 SWT is nearly ideal for the task it was designed for -
 extendable IDE environment for Java.

 I am not using it though.
 I need performance at first and I am not interested
 in other bells and whistles.

 I am using native code IDEs if you will ask me.
 For commercial project we did recently -
 Microsoft VisualJ (Visual Studio) - still the best IDE and debugger 
 (deep
 IMHO)
 And GEL for private java projects (http://www.gexperts.com/)


 Out of curiousity, what is your ideal GUI toolkit ?


 For what? That is the question....
 Each task has its own ideal toolkit. No silver bullet in principle.

 For BlockNote[.net] I was using WTL as I had design goal to
 create native Windows application - drop-in replacement of
 notepad.exe and wordpad.exe but for HTML.  So it should
 look natively for windows.

 WTL is just thin set of templates wrapping HWND and using
 native look and feel as much as possible.
 HTML engine in BlockNote by itself is using its own set of classes - its


 own


 toolkit.

 And next version of BlockNote will appear as a set of HTML/CSS/Script
 files running in some "smart client" application I am designing now.
 You may think about http://www.terrainformatica.com/htmlayout/
 as a GUI toolkit for new BlockNote.
 Sort of http://www.terrainformatica.com/htmlayout/images/image5.png

 Time changed and as do requirements. I've got a lot of customization
 request for example. Having application defined as set of
 HTML/CSS/Script declarations opens it for customizations, extnesions
 and integration with legacy systems.

 I extended CSS (cascading style sheets) to serve better
 apllication UI purposes. E.g. simple animation has been added.
 See screenshots 
 http://www.terrainformatica.com/htmlayout/screenshots.whtm
 or download demo from the site.

 Andrew.




 
 You can get the source through the svn server Andrew has posted there.


I looked at Harmonia and I liked the idea, but
1) There doesn't seem to be any documentation.
2) Doesn't work with build; needs make files (IMO, make files for D == 
old-school non-sense).
3) It seems abandoned?

Otherwise, I would love to play with it.



 Feb 05 2006



prev sibling  parent  "Andrew Fedoniouk" <news terrainformatica.com>  writes:


"Charles" <noone nowhere.com> wrote in message 
news:ds5uch$1kdv$1 digitaldaemon.com...

 Oh, thanks a lot.
 Next question: what applications from the list you are using personally?


 I use rssowl.


And how is it? I mean "tactile feelings"?
Compared with let's say RSS Reader
(http://www.rssreader.com/) ?

There is nothing spectacular in UI in average RSS reader to be honest.

Except of things like KlipFolio
http://www.serence.com/site.php?action=ser_screens,kf-1
and as you may see they use their own toolkit.


 And actually I spoke too soon , SWT is not as popular as I thought it was 
 ,
 though I still think its a solid GUI kit.


 I am not using it though.
 I need performance at first and I am not interested
 in other bells and whistles.


 DWT is likely faster than SWT , I notice a marginal difference on my local
 machine.


The same here.

If it would be possible to replace Java in Eclipse by D it will be best
marketing factor you can imagine. But this is impossible in 1:1 fashion.
Java has ClassLoader and uses it intensevely in Eclipse.
ClassLoader as an entity is highly useful feature in Java runtime system.
Especially in plugin system of IDE.
But even compiled in native code (Native Eclipse in Fedora Core 4)
is not demonstrating significant gain. I suspect that something wrong
in principle there. Relying solely on GC as a memory management
can make a bad joke when your code will grow to near 50% of
complexity of Eclipse.


 For what? That is the question....
 Each task has its own ideal toolkit. No silver bullet in principle.


 Your right, and having DWT as 'The Standard' won't stop people from using
 others.  I think having DWT as a standard is more of a marketing move.


Agree.

But SWT when it appeared was "yet another toolkit", not more.
From marketing point of view it was almost nothing.
It started to sound only in Eclipse.
I mean that good IDE for D with debugger
is stronger marketing thing in order of magnitude than any toolkit.
Debugger is the must. IMO (I am not strong in marketing at all).


 Time changed and as do requirements. I've got a lot of customization
 request for example. Having application defined as set of
 HTML/CSS/Script declarations opens it for customizations, extnesions
 and integration with legacy systems.


 I think HTMLLayout and Harmonia are simply gorgeous ( I cant find a 
 download
 for harmonia anymore ? http://www.terrainformatica.com/harmonia/ ) , and I
 like the idea behind it. I hope you continue developing harmonia.


Thanks.

svn://harmonia.dyndns.org  shall work.
If you are using Tortoise SVN you can even put this URL in browser or
in console - it should show content automatically.

I had two projects for Harmonia at that moment but D was
dropped in favor of C++. Sad story for me personally but life is life.

I have plans to return to Harmonia - in particular to replace theme/style
there by simple (very simple in fact) theme engine
capable to also render OS native shapes of controls.
I did this for HTMLayout
http://www.terrainformatica.com/htmlayout/images/themesupport.jpg
http://www.terrainformatica.com/htmlayout/images/systabs.jpg
and it is really simple.

Another task: I have also simple "rich text editor" I did once in Java (AWT 
only)
I would like to port it as it could also serve as source code highlighting 
editor.
A la Scintilla but simpler and compact. And it perfectly fits in D model.

No time line set though...
If someone want to take these tasks - let me know.

Andrew. 



 Feb 05 2006



prev sibling  parent reply Bruno Medeiros <daiphoenixNO SPAMlycos.com>  writes:


Walter Bright wrote:

 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message 
 news:ds1g3o$1d63$1 digitaldaemon.com...

 1) Do nothing and argue that a standard gui is a bad idea.


 Exactly! I don't even know what "standard gui" means.
 Each application (or group of applications) has its own requirement set 
 here.
 "standard" of what for the byte sake?


 
 All standard means is there are is a gui library as part of the D standard, 
 it wouldn't be a separate add-on.
 
 

 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.


 
 Java started out with just AWT. Without AWT, Java would have gotten nowhere. 
 The other gui libraries came along later as the user base expanded. AWT was 
 Java's proverbial "chicken" to bootstrap the process. We need one, too. It 
 isn't like DWT will be the only gui toolkit ever.
 

 The point here - even in Java with its "official
 toolkit" (two of them, btw) in real life you will be forced to use your 
 own at the end.


 
 I'm not a bit surprised. Nobody has figured out the last word in gui 
 toolkits.
 

 So the question - what is this "standard GUI" for?


 
 If you like, think of having a standard gui like DWT as useful for 
 marketing. It *is* a big win for marketing the language. Quite a lot of 
 people think it is necessary before even considering D, therefore it is 
 necessary.
 


Ye, about that... I'm a bit confused on this "standard" GUI thing too. 
What does it mean and entail? Would it be shipped together with Phobos 
in the compiler distribution?
And about those "a lot of people think it is necessary", who are they? 
Do they think D needs a GUI, or do they think D needs a *standard* GUI? 
(because the latter D already has, several)
I do recall some occasional complaints, but honestly, by the way they 
were presented I didn't took them seriously. And I too didn't think you 
would take them seriously Walter (see below).


 Again, solution could be in building "standard GUI" pyramid
 from reusable blocks like Graphics Package, etc.
 Such blocks will have more chance to be a) accepted widely
 b) to be not thrown away if something will go wrong.
 If you wish we can establish sort of working group
 on creation of such D GUI foundation,
 Graphics Package, etc.
 I am short on time a bit now but will try to do something here
 if we need to.


 
 I think you're probably right, and this would be a better long term solution 
 than DWT is, so I encourage you to work on it. But we need something now.
 


We need it now, really? Why?
Of all the problems people have with D: language features (templates, 
ITFI, many more...), fixing/improving the standard library, 
fixing/improving the docs, contributing new stuff(regexps, recls, etc.) 
possibly in-language, toolchain (full-featured IDE/editor, full-featured 
debugger), books in D, and "having a GUI", the GUI one is a superficial 
one.
We already have pretty decent GUI libs and the difference between a GUI 
being official/standard or not could only possibly be in having to 
download and install an additional package besides the compiler, whereas 
the other problems are actually important. They cannot be workedaround 
and will actually require significant work by part of Walter and/or 
someone else in the community. So how can *anyone* call this GUI issue a 
real problem?

I would like the GUI proponents to explain this to me, as the few posts 
about this that I vaguely recall from far ago were simple "D needs a GUI 
too, because I like GUI very much", but no rationale how or why (or even 
explicit mention of the term "standard").

-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to 
be... unnatural."



 Feb 06 2006



 next sibling parent reply Derek Parnell <derek psych.ward>  writes:


On Mon, 06 Feb 2006 23:02:10 +0000, Bruno Medeiros wrote:


 Walter Bright wrote:

 I think you're probably right, and this would be a better long term solution 
 than DWT is, so I encourage you to work on it. But we need something now.




 

 We need it now, really? Why?
 Of all the problems people have with D: language features (templates, 
 ITFI, many more...), fixing/improving the standard library, 
 fixing/improving the docs, contributing new stuff(regexps, recls, etc.) 
 possibly in-language, toolchain (full-featured IDE/editor, full-featured 
 debugger), books in D, and "having a GUI", the GUI one is a superficial 
 one.


Agreed that a standard GUI library is very priority in the TODO list. There
are many higher priority things that we need Walter to do. And some are
real simple (of the low hanging fruit variety). 

e.g. A clean up of the phobos code: correct all the 'module' statements
(including missing ones) and get it to compile with "-w" turned on. Should
take about an afternoon to complete and makes me feel like Walter actually
cares about it.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
7/02/2006 10:30:36 AM



 Feb 06 2006



 next sibling parent  Derek Parnell <derek psych.ward>  writes:


On Tue, 7 Feb 2006 10:36:27 +1100, Derek Parnell wrote:

 

 Agreed that a standard GUI library is very priority in the TODO list. 


but I meant ....

Agreed that a standard GUI library is a very low priority in the TODO list. 

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
7/02/2006 10:38:54 AM



 Feb 06 2006



prev sibling  parent reply "Walter Bright" <newshound digitalmars.com>  writes:


"Derek Parnell" <derek psych.ward> wrote in message 
news:1ohbygoysxj15.1fzj523pfiokn$.dlg 40tude.net...

 e.g. A clean up of the phobos code: correct all the 'module' statements
 (including missing ones) and get it to compile with "-w" turned on. Should
 take about an afternoon to complete and makes me feel like Walter actually
 cares about it.


The -w switch is there to support a different philosophy of programming than 
is used in Phobos. So it's not that I don't care about it, it's that I don't 
agree with it. Not everything in D I agree with <g>. 



 Feb 06 2006



 next sibling parent reply Derek Parnell <derek psych.ward>  writes:


On Mon, 6 Feb 2006 19:23:50 -0800, Walter Bright wrote:


 "Derek Parnell" <derek psych.ward> wrote in message 
 news:1ohbygoysxj15.1fzj523pfiokn$.dlg 40tude.net...

 e.g. A clean up of the phobos code: correct all the 'module' statements
 (including missing ones) and get it to compile with "-w" turned on. Should
 take about an afternoon to complete and makes me feel like Walter actually
 cares about it.


 
 The -w switch is there to support a different philosophy of programming than 
 is used in Phobos. 


"-w"  ==> Explicitness, Obvious Coder Intent ( a.k.a. clarity)
!"-w" ==> Implicitness, Ambiguous Coder Intent ( a.k.a. bug-attractor)

Isn't one of the reasons for need to use the 'alias' statement to remove
some of the implicitness in D?


 So it's not that I don't care about it,


Sorry, but I'm not convinced by that argument. 
* Why are some of the module statements wrong? (I've sent you the list
twice now)
* Why are some module statements missing? (I've also sent you this list)
* Why don't you want others to recompile Phobos using a heightened measure
of caution (ie "-w" switch)


 it's that I don't agree with it. 


The "it" being what? Explicit and unambiguous code?


 Not everything in D I agree with <g>.


I should hope not!

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
7/02/2006 2:55:10 PM



 Feb 06 2006



  parent reply "Walter Bright" <newshound digitalmars.com>  writes:


"Derek Parnell" <derek psych.ward> wrote in message 
news:kd76gxwx1ay2.19m4wymne8pm$.dlg 40tude.net...

 * Why are some of the module statements wrong? (I've sent you the list
 twice now)


Sloth on my part.


 * Why are some module statements missing? (I've also sent you this list)


Sloth on my part for the ones in std. For the ones in internal, they are 
irrelevant, because those modules are not meant to ever be imported.


 * Why don't you want others to recompile Phobos using a heightened measure
 of caution (ie "-w" switch)


In the previous long, and heated, discussions on this issue, I argued 
passionately that the -w style code reduces readability, maintainability, 
and reliability. I don't think there's anything to be added to that.

This current thread only reinforces my opinion that the mere existence of 
warnings is a mistake in any language, as it causes unresolvable debates 
about "is this code right or wrong?" 



 Feb 07 2006



 next sibling parent  Kramer <Kramer_member pathlink.com>  writes:


In article <dsai30$2eim$3 digitaldaemon.com>, Walter Bright says...

"Derek Parnell" <derek psych.ward> wrote in message 
news:kd76gxwx1ay2.19m4wymne8pm$.dlg 40tude.net...

 * Why are some of the module statements wrong? (I've sent you the list
 twice now)


Sloth on my part.


 * Why are some module statements missing? (I've also sent you this list)


Sloth on my part for the ones in std. For the ones in internal, they are 
irrelevant, because those modules are not meant to ever be imported.


 * Why don't you want others to recompile Phobos using a heightened measure
 of caution (ie "-w" switch)


In the previous long, and heated, discussions on this issue, I argued 
passionately that the -w style code reduces readability, maintainability, 
and reliability. I don't think there's anything to be added to that.

This current thread only reinforces my opinion that the mere existence of 
warnings is a mistake in any language, as it causes unresolvable debates 
about "is this code right or wrong?" 



So why not instead treat the compiler -w option as a LINT like tool.  I know
it's *not* LINT, but maybe it's just a terminology thing that's hanging things
up.  Treat -w like LINT and allow the compiler to compile through the
'warnings'.  Maybe instead of 'warnings', they should be 'code that you are
highly advised to look at, because the compiler doesn't agree with you'.

I'm not trying to be sarcastic.  If the term 'warnings' has such an ingrained
meaning for everyone, then call it something else.  As a side-effect -- granted
it's not a full-blown LINT tool -- it's kind of nice to have *some* of that
functionality in the compiler.

Just my (naive as they may be) thoughts.

-Kramer



 Feb 07 2006



prev sibling next sibling parent reply Kramer <Kramer_member pathlink.com>  writes:


In article <dsai30$2eim$3 digitaldaemon.com>, Walter Bright says...

"Derek Parnell" <derek psych.ward> wrote in message 
news:kd76gxwx1ay2.19m4wymne8pm$.dlg 40tude.net...

 * Why are some of the module statements wrong? (I've sent you the list
 twice now)


Sloth on my part.


 * Why are some module statements missing? (I've also sent you this list)


Sloth on my part for the ones in std. For the ones in internal, they are 
irrelevant, because those modules are not meant to ever be imported.


 * Why don't you want others to recompile Phobos using a heightened measure
 of caution (ie "-w" switch)


In the previous long, and heated, discussions on this issue, I argued 
passionately that the -w style code reduces readability, maintainability, 
and reliability. I don't think there's anything to be added to that.

This current thread only reinforces my opinion that the mere existence of 
warnings is a mistake in any language, as it causes unresolvable debates 
about "is this code right or wrong?" 



So why not instead treat the compiler -w option as a LINT like tool.  I know
it's *not* LINT, but maybe it's just a terminology thing that's hanging things
up.  Treat -w like LINT and allow the compiler to compile through the
'warnings'.  Maybe instead of 'warnings', they should be 'code that you are
highly advised to look at, because the compiler doesn't agree with you'.

I'm not trying to be sarcastic.  If the term warnings has such an ingrained
meaning for everyone, then call it something else.  As a side-effect -- granted
it's not a full-blown LINT tool -- it's kind of nice to have *some* of that
functionality in the compiler.

Just my (nieve as they may be) thoughts.

-Kramer



 Feb 07 2006



  parent reply "Walter Bright" <newshound digitalmars.com>  writes:


"Kramer" <Kramer_member pathlink.com> wrote in message 
news:dsalta$2ivu$1 digitaldaemon.com...

 So why not instead treat the compiler -w option as a LINT like tool.  I 
 know
 it's *not* LINT, but maybe it's just a terminology thing that's hanging 
 things
 up.  Treat -w like LINT and allow the compiler to compile through the
 'warnings'.  Maybe instead of 'warnings', they should be 'code that you 
 are
 highly advised to look at, because the compiler doesn't agree with you'.


The trouble with that is it sounds good on paper, but in practice those 
warnings scroll up and off the screen, and are missed. 



 Feb 07 2006



  parent reply Derek Parnell <derek psych.ward>  writes:


On Tue, 7 Feb 2006 13:51:05 -0800, Walter Bright wrote:


 "Kramer" <Kramer_member pathlink.com> wrote in message 
 news:dsalta$2ivu$1 digitaldaemon.com...

 So why not instead treat the compiler -w option as a LINT like tool.  I 
 know
 it's *not* LINT, but maybe it's just a terminology thing that's hanging 
 things
 up.  Treat -w like LINT and allow the compiler to compile through the
 'warnings'.  Maybe instead of 'warnings', they should be 'code that you 
 are
 highly advised to look at, because the compiler doesn't agree with you'.


 
 The trouble with that is it sounds good on paper, but in practice those 
 warnings scroll up and off the screen, and are missed.


What sort of console software do you use? I use Windows XP cmd.exe with the
buffer set to 9999 lines, and I've never had warnings etc... scroll off the
screen. And if one does, you can redirect to a file and examine them at
leisure.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
8/02/2006 12:30:54 PM



 Feb 07 2006



  parent reply "Walter Bright" <newshound digitalmars.com>  writes:


"Derek Parnell" <derek psych.ward> wrote in message 
news:adnet1wo97n0$.fruquqppxjn$.dlg 40tude.net...

 On Tue, 7 Feb 2006 13:51:05 -0800, Walter Bright wrote:

 The trouble with that is it sounds good on paper, but in practice those
 warnings scroll up and off the screen, and are missed.


 What sort of console software do you use? I use Windows XP cmd.exe with 
 the
 buffer set to 9999 lines, and I've never had warnings etc... scroll off 
 the
 screen. And if one does, you can redirect to a file and examine them at
 leisure.


Oh, I know how to do both of those things. The trouble is, when you're doing 
a long compile, unless you see it on the screen you don't think to go look 
at a log file or whatever. Having the build not complete means you can't 
overlook it. 



 Feb 07 2006



 next sibling parent  Derek Parnell <derek psych.ward>  writes:


On Tue, 7 Feb 2006 20:20:29 -0800, Walter Bright wrote:


 The trouble is, when you're doing 
 a long compile, unless you see it on the screen you don't think to go look 
 at a log file or whatever. Having the build not complete means you can't 
 overlook it.


It seems we have different work practices. When I compile, I start from the
first compiler message and work down the list, so I always see them all. I
always compile with "-w" and a clean compile to me means that there are no
compiler messages, and that is not the same as getting an executable built.
After dealing with the compiler messages, I then start from the first
linker message and work down that list. So again, I don't miss any. The
thought of 'not thinking to look at a log file or whatever' is a
manifestation of mediocracy and/or carelessness which I try to avoid.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
8/02/2006 4:40:55 PM



 Feb 07 2006



prev sibling  parent  Sean Kelly <sean f4.ca>  writes:


Walter Bright wrote:

 
 Oh, I know how to do both of those things. The trouble is, when you're doing 
 a long compile, unless you see it on the screen you don't think to go look 
 at a log file or whatever. Having the build not complete means you can't 
 overlook it. 


If I'm building with non-terminal warnings I'll usually just grep the 
output to track down anything relevant.  Heck, I'll even do this for 
fatal build errors on large projects as it's not uncommon to have a 
thousand lines or so of junk following the message I care about.  I 
would like to believe that those who enable warnings also care enough to 
check them, but treating them as errors certainly offers some 
encouragement :-)


Sean



 Feb 07 2006



prev sibling  parent  Derek Parnell <derek psych.ward>  writes:


On Tue, 7 Feb 2006 03:05:14 -0800, Walter Bright wrote:


 "Derek Parnell" <derek psych.ward> wrote in message 

 * Why don't you want others to recompile Phobos using a heightened measure
 of caution (ie "-w" switch)


 
 In the previous long, and heated, discussions on this issue, I argued 
 passionately that the -w style code reduces readability, maintainability, 
 and reliability. I don't think there's anything to be added to that.


But I do <g>.  I have a different opinion from your opinion. My opinion is
that in those cases where the compiler makes an assumption of my
intentions, I can reduce potentially incorrect assumptions if I annotate my
code with explicit instructions to the compiler about my actual intentions.

So when I code 

   int a; 
   long b;
   . . . 
   a = b; 
 
Instead of the compiler assuming I meant ...

   a = cast(int)b;

with the "-w" switch I could be alerted to this compiler assumption and
recode it to be exactly explicit. Maybe I would code it as ...

   if (b > a.max )
      throw (SomeERROR);
   a = cast(int)b;

or maybe ...

   long a;
   long b;
   . . .
   a = b;

or maybe ..., well you get the picture. There could be any number of
alternatives that are *not* what the compiler assumed on my behalf.


 This current thread only reinforces my opinion that the mere existence of 
 warnings is a mistake in any language, as it causes unresolvable debates 
 about "is this code right or wrong?"


I am *NOT* talking about right or wrong, or even "errors". I just simply
want to know where it is that the compiler is assuming what my intentions
might have been so that I can recode it to be explicit. Nothing whatsoever
to do with right or wrong, legal or illegal, etc...

If you are concerned about the term "warning", then for Bob's sake change
the terminology. I don't care that much about what term you are using for
this concept.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
8/02/2006 12:06:35 PM



 Feb 07 2006



prev sibling  parent reply Bruno Medeiros <daiphoenixNO SPAMlycos.com>  writes:


Walter Bright wrote:

 "Derek Parnell" <derek psych.ward> wrote in message 
 news:1ohbygoysxj15.1fzj523pfiokn$.dlg 40tude.net...

 e.g. A clean up of the phobos code: correct all the 'module' statements
 (including missing ones) and get it to compile with "-w" turned on. Should
 take about an afternoon to complete and makes me feel like Walter actually
 cares about it.


 
 The -w switch is there to support a different philosophy of programming than 
 is used in Phobos. So it's not that I don't care about it, it's that I don't 
 agree with it. Not everything in D I agree with <g>. 
 
 


Whoa, am I reading this right? I didn't know this. Somebody should have 
told me this sooner, as, although very disturbing, it explains a whole 
lot. I was wondering myself why the hell didn't Phobos compile with -w, 
so now I know. It also explains why the -w feature is pretty much *broken*.

As for whether or not one should use warnings, I pretty much agree with 
Derek in his Explicit/Obvious vs Implicit/Ambiguous comment. I mean, how 
can sloth be a programming philosophy?
I don't know what more I can say about the use of warnings, I have the 
feeling it wont make a difference. I can only note that warnings have 
been present in the development philosophies of C-languages since the 
older days, to the present, ubiquitous even in modern languages like 


As for whether how the warnings features should work, now here's the 
critical, poignant thing: how can you Walter, since you don't agree with 
the use of the warnings feature, be entitled to say _how_ should the 
warnings feature work at all?? It doesn't make sense. You are entitled 
to argue why you don't think warnings should exist or be used, no more.
If I had known this beforehand I wouldn't have written a point about why 
warnings should not halt compilation, or why warnings scrolling off the 
console is not a problem.
It's like, for example, a person who intrinsically doesn't agree with 
vi's editing model (or with LISP languages, or whatever.), trying to 
argue how it (they) should work. It makes no sense such arguing.

-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to 
be... unnatural."



 Feb 08 2006



  parent  "Walter Bright" <newshound digitalmars.com>  writes:


"Bruno Medeiros" <daiphoenixNO SPAMlycos.com> wrote in message 
news:dscmct$1ck3$1 digitaldaemon.com...

 As for whether how the warnings features should work, now here's the 
 critical, poignant thing: how can you Walter, since you don't agree with 
 the use of the warnings feature, be entitled to say _how_ should the 
 warnings feature work at all??


It's inescapable, because I do the work to implement it. Inevitably, 
decisions must be made, documentation must be written, etc.

But you're right. I believe warnings are a mistake, which makes me the wrong 
person to go about implementing them. There's no reason you have to put up 
with this. Ben Hinkle has written a D front end toolkit, from which you can 
take the D front end sources that come with DMD and build the front end. 
With it, you can build any tool you like based on it with little effort. You 
are free to make a Dlint, and have it analyze the source code in any way you 
wish. You are entitled to make all the decisions as to its behavior, because 
you'll be the one doing the work.

I believe I've stated more than once my full endorsement for such a project 
(even though you don't need my approval). It's a good idea. Allowing people 
the freedom to make their own D source code analyzing tools was one of the 
motivating reasons for releasing the D front end as open source. 



 Feb 08 2006



prev sibling  parent  nick <nick_member pathlink.com>  writes:


In article <ds8kd6$r1b$1 digitaldaemon.com>, Bruno Medeiros says...


We need it now, really? Why?
Of all the problems people have with D: language features (templates, 
ITFI, many more...), fixing/improving the standard library, 
fixing/improving the docs, contributing new stuff(regexps, recls, etc.) 
possibly in-language, toolchain (full-featured IDE/editor, full-featured 
debugger), books in D, and "having a GUI", the GUI one is a superficial 
one.
We already have pretty decent GUI libs and the difference between a GUI 
being official/standard or not could only possibly be in having to 
download and install an additional package besides the compiler, whereas 
the other problems are actually important. They cannot be workedaround 
and will actually require significant work by part of Walter and/or 
someone else in the community. So how can *anyone* call this GUI issue a 
real problem?

I would like the GUI proponents to explain this to me, as the few posts 
about this that I vaguely recall from far ago were simple "D needs a GUI 
too, because I like GUI very much", but no rationale how or why (or even 
explicit mention of the term "standard").


Having the default gui saves people the trouble of having to do research and
find the best one.

With that said, I think that an IDE is the biggest showstopper in the
foreseeable future. Many tasks don't require a gui, but almost everyone wants to
avoid the command line(ok, some 1337 linux people like it).

Of course, having a non-finalized language spec seems pretty problematic as
well... but it may be a good idea to make some hard choices and freeze the
language spec soon. There can always be a D1.1 and D 1.2 and so on; features can
be removed and inserted. (Hey, we've got the deprecate keyword!)

So, basically I agree with you.


-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to 
be... unnatural."





 Feb 06 2006



prev sibling  parent reply Sean Kelly <sean f4.ca>  writes:


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



 Feb 04 2006



 next sibling parent  "Andrew Fedoniouk" <news terrainformatica.com>  writes:


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



 Feb 04 2006



prev sibling  parent  "Charles" <noone nowhere.com>  writes:


 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


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





 Feb 05 2006



prev sibling  parent  Bruno Medeiros <daiphoenixNO SPAMlycos.com>  writes:


Walter Bright wrote:

 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message 
 news:ds10up$14av$1 digitaldaemon.com...

 Forget about STL and boost. There is no practical GUI  toolkit in the wild
 using them anyway.  (This fact speaks for itself)


 
 I know. I have a suspicion that both are evolutionary dead ends. Your fact 
 is evidence for that, as well as the failure of any other language to pick 
 up those features. 
 
 


Whoa, huh...? STL is an evolutionary dead end and no other languages 
have picked it up? Doesn't the STL include mainly generic containers? 
Then, how is it that that has not been incorporated in other languages?

-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to 
be... unnatural."



 Feb 06 2006