|
Archives
D Programming
D
D.gnu
digitalmars.D
digitalmars.D.bugs
digitalmars.D.dtl
digitalmars.D.dwt
digitalmars.D.announce
digitalmars.D.learn
digitalmars.D.debugger
C/C++ Programming
c++
c++.announce
c++.atl
c++.beta
c++.chat
c++.command-line
c++.dos
c++.dos.16-bits
c++.dos.32-bits
c++.idde
c++.mfc
c++.rtl
c++.stl
c++.stl.hp
c++.stl.port
c++.stl.sgi
c++.stlsoft
c++.windows
c++.windows.16-bits
c++.windows.32-bits
c++.wxwindows
digitalmars.empire
digitalmars.DMDScript
|
digitalmars.D - DWT - standard D gui?
↑ ↓ ← → "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?
↑ ↓ ← → 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
↑ ↓ ← → "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)
↑ ↓ ← → 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
↑ ↓ ← → "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
↑ ↓ ← → 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
↑ ↓ ← → 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.
↑ ↓ ← → 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?
I'm trying to reconcile #1 and #6 above. Do we use Kris's translation
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
↑ ↓ ← → 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?
I'm trying to reconcile #1 and #6 above. Do we use Kris's translation
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
↑ ↓ ← → "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.
↑ ↓ ← → 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.. :)
↑ ↓ ← → 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
↑ ↓ ← → 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?
↑ ↓ ← → "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
automated translation to work, with the addition of a few hand-coded
where
needed. This would take advantage of the full field of experience
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
much
automation as is prudent (following the 80/20 rule) will help ensure
health
of a D SWT port. This way, the library can more easily track changes
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
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
translate the code in as straightforward a manner as possible. There
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
ported too?
↑ ↓ ← → "Kris" <fu bar.com> writes:
"pragma" <pragma_member pathlink.com> wrote ...
I'm trying to reconcile #1 and #6 above. Do we use Kris's translation
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
↑ ↓ ← → "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.
↑ ↓ ← → 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.
Zz
↑ ↓ ← → 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.
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.
↑ ↓ ← → =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
kris wrote:
[...], but Java readily lends
itself to mechanical conversion.
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
↑ ↓ ← → 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?
↑ ↓ ← → 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?
↑ ↓ ← → 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 +/
↑ ↓ ← → 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.
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.
↑ ↓ ← → 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
↑ ↓ ← → =?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...
The class hierarchy is ported over from C#, which isn't too bad either.
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://wxnet.sourceforge.net/docs.html (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.
Bero did most of the heavy lifting for wxD, porting the C# classes over.
(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.
(basically it was just missing since it was harder to do in C#)
HTML support is already included, in the current wxD release.
http://wxd.sourceforge.net/HtmlHelp.png (using native renderer)
↑ ↓ ← → "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
↑ ↓ ← → =?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
↑ ↓ ← → 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?
↑ ↓ ← → =?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
↑ ↓ ← → 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/).
↑ ↓ ← → =?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.
↑ ↓ ← → 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.
↑ ↓ ← → =?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
↑ ↓ ← → =?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
↑ ↓ ← → 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?
↑ ↓ ← → 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/
↑ ↓ ← → 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
↑ ↓ ← → 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.
↑ ↓ ← → 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.
↑ ↓ ← → 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
↑ ↓ ← → 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
↑ ↓ ← → "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.
↑ ↓ ← → 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.
--
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to
be... unnatural."
↑ ↓ ← → "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.
↑ ↓ ← → "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.
↑ ↓ ← → "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
↑ ↓ ← → 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
↑ ↓ ← → "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++?"
↑ ↓ ← → 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.
↑ ↓ ← → 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.
↑ ↓ ← → 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?
↑ ↓ ← → 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
↑ ↓ ← → 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 +/
↑ ↓ ← → =?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...
↑ ↓ ← → 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.
↑ ↓ ← → 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.
↑ ↓ ← → "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
from being used in any way. However, having a default gui that comes
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.
↑ ↓ ← → nick <nick.atamas gmail.com> writes:
Charles wrote:
because SWT is a large toolkit that has severe issues.
What issues ?
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.
↑ ↓ ← → "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.
↑ ↓ ← → "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.
↑ ↓ ← → 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/
↑ ↓ ← → "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.
Isn't Swing tightly controlled by Sun? Anyone have a copy of the license for
it?
↑ ↓ ← → 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
↑ ↓ ← → =?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
↑ ↓ ← → "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?
↑ ↓ ← → "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
↑ ↓ ← → 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
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
↑ ↓ ← → 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
↑ ↓ ← → "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.
↑ ↓ ← → "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.
↑ ↓ ← → 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.
↑ ↓ ← → "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
↑ ↓ ← → "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.
↑ ↓ ← → "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 :)
↑ ↓ ← → 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.
↑ ↓ ← → 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.
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.
↑ ↓ ← → 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.
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
↑ ↓ ← → 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.
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
↑ ↓ ← → "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.
↑ ↓ ← → 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.
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.
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
↑ ↓ ← → "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.
↑ ↓ ← → "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.
↑ ↓ ← → 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.
My #1 point is that SWT is just a horrible option. I used it at work and
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.
↑ ↓ ← → "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.
My #1 point is that SWT is just a horrible option. I used it at work and 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.
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.
↑ ↓ ← → 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/
↑ ↓ ← → 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
↑ ↓ ← → 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
↑ ↓ ← → =?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
↑ ↓ ← → 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
↑ ↓ ← → 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
↑ ↓ ← → =?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
↑ ↓ ← → "Walter Bright" <newshound digitalmars.com> writes:
Can we move this discussion over to digitalmars.D.dwt?
↑ ↓ ← → 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.
↑ ↓ ← → "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.
↑ ↓ ← → 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
↑ ↓ ← → 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!
↑ ↓ ← → 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-----
↑ ↓ ← → 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
↑ ↓ ← → "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?
↑ ↓ ← → 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/
↑ ↓ ← → "Charles" <noone nowhere.com> writes:
My #1 point is that SWT is just a horrible option.
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
no?
That's right. A *standard* component of D needs to be usable by
projects without needing to pay license fees. That would be no problem
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.
My #1 point is that SWT is just a horrible option. I used it at work and
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.
↑ ↓ ← → =?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.
↑ ↓ ← → 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
↑ ↓ ← → "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.
↑ ↓ ← → =?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
the class hierarchy over from Qt# and the wrappers over from QtC
(a generated sublayer inside of Qt# that wraps the C++ in extern "C",
Seems that they have switched over to some XML-based SWIG workalike)
From the Qt# home page, they say there are 476 classes converted...
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
↑ ↓ ← → "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?
↑ ↓ ← → "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?
↑ ↓ ← → "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
↑ ↓ ← → 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.
↑ ↓ ← → "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.
↑ ↓ ← → =?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.
So I chose wxD. Even with the "weird mix" of C++ and C#, that it has.
--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...
↑ ↓ ← → "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
↑ ↓ ← → 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.
↑ ↓ ← → "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>.
↑ ↓ ← → 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
↑ ↓ ← → "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)
↑ ↓ ← → 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
↑ ↓ ← → "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]
↑ ↓ ← → "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
↑ ↓ ← → "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
↑ ↓ ← → "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.
↑ ↓ ← → "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
↑ ↓ ← → "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.
↑ ↓ ← → 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:
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.
↑ ↓ ← → 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
↑ ↓ ← → 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
↑ ↓ ← → "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.
↑ ↓ ← → 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.
--
UB
↑ ↓ ← → "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.
That's where things are going.
↑ ↓ ← → 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
↑ ↓ ← → "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.
↑ ↓ ← → 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.
↑ ↓ ← → 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
↑ ↓ ← → 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
updating that one in light of Java 1.5 and C# 2.0 (or even 3.0))
--
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to
be... unnatural."
↑ ↓ ← → "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
↑ ↓ ← → "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.
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.
↑ ↓ ← → "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
↑ ↓ ← → "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.
↑ ↓ ← → 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
↑ ↓ ← → "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.
Application module is #2
And after that we can define
OsWidgets module which will contain wrappers
for native OS "controls" - edit boxes, comboboxes, etc.
OsWidgets is #3
"Harmonia" (or some other name) Module will
use Graphics and Application modules but will
not contain references to OsWidgets module.
"Harmonia" (windowless, lightweight, declarative, ?
module) is #4
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.
↑ ↓ ← → 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
↑ ↓ ← → 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.
↑ ↓ ← → 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
↑ ↓ ← → 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.
↑ ↓ ← → 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)
Note - All widgets have been implemented in C# and render themselves
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
↑ ↓ ← → "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
↑ ↓ ← → 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...
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."
↑ ↓ ← → "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.
↑ ↓ ← → 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...
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 )
↑ ↓ ← → 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
↑ ↓ ← → 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."
↑ ↓ ← → "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."
↑ ↓ ← → "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>
↑ ↓ ← → "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.
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
↑ ↓ ← → 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.
↑ ↓ ← → "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
↑ ↓ ← → "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
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
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
SWT first.
:) Mea culpa, this phrase:
"Swing and SWT were built on top of AWT." is not strictly valid in terms
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
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
and written by the ex-SmallTalk team, partly in protest of the serious
(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
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
port to D is a notable catalyst. Contrary to your own public opinion,
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
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
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
as "D satndard GUI" implies look in the future too.
Andrew Fedoniouk.
http://terrainformatica.com
↑ ↓ ← → "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.
↑ ↓ ← → "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?
-4087815?platform=gurupa&url=index%3Dstripbooks%3Arelevance-above%26dispat
%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
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.
↑ ↓ ← → 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.
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.
Next question: what applications from the list you are using personally?
-4087815?platform=gurupa&url=index%3Dstripbooks%3Arelevance-above%26dispat
%3Dsearch%26results-process%3Dbin&field-keywords=swt&Go.x=8&Go.y=8
I think your greatly underestimating SWT.
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 ?
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
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.
↑ ↓ ← → 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?
-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 ?
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.
↑ ↓ ← → "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.
↑ ↓ ← → 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.
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.
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.
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."
↑ ↓ ← → 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
↑ ↓ ← → 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
↑ ↓ ← → "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>.
↑ ↓ ← → 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
↑ ↓ ← → "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?"
↑ ↓ ← → 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
↑ ↓ ← → 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
↑ ↓ ← → "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.
↑ ↓ ← → 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
↑ ↓ ← → "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.
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.
↑ ↓ ← → 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
↑ ↓ ← → 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
↑ ↓ ← → 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
↑ ↓ ← → 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
Java and C#, so how about it? Are *all* these people wrong??
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."
↑ ↓ ← → "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.
↑ ↓ ← → 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."
↑ ↓ ← → 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
↑ ↓ ← → "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.
↑ ↓ ← → "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
awful to me , and C# is a 'too verbose' unportable java )
Microsoft has tried to be everything but a software company , and I for one
am looking forward to whats next ( hopefully google OS !).
"Sean Kelly" <sean f4.ca> wrote in message
news:ds37rt$2ld1$1 digitaldaemon.com...
Andrew Fedoniouk wrote:
I don't understand where this "standard GUI" bright idea comes from.
Even Java has no single toolkit: AWT and Swing, SWT plus 3 or 4 more.
Part of that is for historical reasons, as the first model didn't fly so
they created a new one.
The advantage to me of having a "standard" toolset (GUI included) is
that it allows me to write code that has a pretty reasonable chance of
compiling and running with few or no changes on more than one platform.
It also makes it a bit less likely that support for these tools will
be suddenly dropped a year later in favor of something new (Microsoft
being the poster child for such behavior). As maintenance takes time
and money, it's nice to have some assurances.
But I agree that this isn't always practical, and even with software
support guarantees there's no saying the underlying architecture won't
change in a way that renders the design meaningless. I think this is
the problem that a slow-moving process like C/C++ standardization faces.
(I've never seen real application using Swing, btw)
In .NET situation is similar: Microsoft is dropping WinForms in favour
of Avalon foundation now.
Trust Microsoft to deprecate an API before it's even been released. I
have a sneaking feeling, however, that the face of Windows will change
significantly in the next few years. They've bet the bank on the
success of .NET/CLI.
Sean
↑ ↓ ← → 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."
|
|
Home
| Search
| C & C++
| D
| DMDScript
| News Groups
| index
| prev
| next
