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