www.digitalmars.com         C & C++   DMDScript  

D - Active Projects

reply "C" <dont respond.com> writes:
I was just wondering what everyone else is working on.  I think it would be
cool to have a refrence , so were not duplicating each other and stuff :).

Im working on Windy as you might know ( GUI toolkit ).  I'm also going to
start a mysql module soon.

You guys ?

C
Jan 09 2004
next sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
 I was just wondering what everyone else is working on.  I think it would
be
 cool to have a refrence , so were not duplicating each other and stuff :).

 Im working on Windy as you might know ( GUI toolkit ).  I'm also going to
 start a mysql module soon.

 You guys ?
Matthew: For the foreseeable future (next 3 months): 1. I've written the MmFile (memory mapped file) and ExeModule (dynamic lib loader) modules, and they're with Walter ATM. It's my understanding that he's busy with his presentation so 0.78 might be some while. I'd like to get them out sometime soon, so that people can give me feedback, since each was done in half a day, and there may well be more features that can be easily and orthogonally added. I'm hoping my friend Greg can help with these, as he's interested in getting into D, but he's busy as well at the moment. 2. I'll be working with Walter (he'll be the much-needed compiler/language guru) on DTL in Feb/March, once the book deadline's past. The plan is to do a bit of a Stepanov and Lee in the first instance, and just get on with it in private. There are several reasons for this is (i) I work fast alone and time will be pressing, and (ii) I'm a real f-wit when it comes to discussing high-level things in writing, resulting in my getting unproductively confused (typical mentally challenged picture thinker). But the main reason is that if there are separate attempts going on, as I assume there are, then each will not pollute the other. I think in the early stages it'll be good to get separate, and potentially unique, ideas for the DTL, and then when each is at a cogent stage they can be presented to the community and well-criticised. Then the best parts can be fed from to form a final, world-beating, template library, with all the necessary support from the compiler. Walter and I've said we'd both like a template library that's more powerful, efficient and simple than STL, Boost, STLSoft, or any of the C++ libs. In the dim and distant future (3-24 months): 1. I'd like to see a neat and macro free equivalent to ATL for COM programming. It'd be good to rewrite the shell-extensions (http://shellext.com/) in D at some point. :) 2. I'd like to see D become the best language for writing Python extensions. Same goes for Perl and Java. 3. I'd like to see a Visual Studio.NET plug-in editor for D. 4. I'd like to see DIDE and leds have a shared pluggable architecture 5. I'd like to see the D compiler have a pluggable architecture, and would love to write DLint (or should that be MDLint?) and DStrip plug-ins for that. 6. I plan to write a book on D sometime in the non-too-distant future.
Jan 09 2004
prev sibling next sibling parent reply Cloud9 Virtual <cloud9virtual yahoo.com> writes:
Greetings. First post, but I've been following the group for some time.
My interest with D is primarily as an embedded systems language. To that 
end at least two things need to happen:
- integration with the GCC backend so we get access to the embedded 
targets used in the industry; someone on D.gnu is looking into that (as 
have I).
- the garbage collector needs a real-time variant. I am currently 
studying the Metronome garbage collector, part of IBM's Jikes JVM. 
Hopefully I will produce a D version soon enough.

Alex M.

C wrote:
 I was just wondering what everyone else is working on.  I think it would be
 cool to have a refrence , so were not duplicating each other and stuff :).
 
 Im working on Windy as you might know ( GUI toolkit ).  I'm also going to
 start a mysql module soon.
 
 You guys ?
 
 C
 
 
Jan 09 2004
parent "Walter" <walter digitalmars.com> writes:
"Cloud9 Virtual" <cloud9virtual yahoo.com> wrote in message
news:bto931$ggi$1 digitaldaemon.com...
 Greetings. First post, but I've been following the group for some time.
 My interest with D is primarily as an embedded systems language. To that
 end at least two things need to happen:
 - integration with the GCC backend so we get access to the embedded
 targets used in the industry; someone on D.gnu is looking into that (as
 have I).
 - the garbage collector needs a real-time variant. I am currently
 studying the Metronome garbage collector, part of IBM's Jikes JVM.
 Hopefully I will produce a D version soon enough.
Cool! Keep us informed of the progress.
Jan 10 2004
prev sibling next sibling parent reply Brad Anderson <brad sankaty.dot.com> writes:
1.  I was attempting to write a D port of Jalopy, a source code formatter, and 
it looked doable for a while.  Then I realized how dependent it was upon ANTLR, 
a lexer/parser written in Java.  So it quickly turned into two ports.  I am 
still toying with porting lex/yacc or ANTLR first, and then getting back to 
Jalopy.  I guess I could kick the tires on std.regexp and do the lexer/parser, 
although my programming skills are intermediate at best.

2.  I am investigating porting SWT to D to have a GUI that would use native 
widgets on the host OS when possible, and implemented widgets otherwise.  IBM 
has had great success with this library, its primary use being Eclipse IDE.  I 
know this is YAGUI (Yet another GUI) - however I want a platform-independent
GUI 
without having to distribute GTK+ or any other library on Win32.

If anyone else is working on similar tools, let this thread know...

Brad


C wrote:

 I was just wondering what everyone else is working on.  I think it would be
 cool to have a refrence , so were not duplicating each other and stuff :).
 
 Im working on Windy as you might know ( GUI toolkit ).  I'm also going to
 start a mysql module soon.
 
 You guys ?
 
 C
 
 
Jan 20 2004
parent reply Ant <Ant_member pathlink.com> writes:
In article <buka0h$12k4$1 digitaldaemon.com>, Brad Anderson says...
2.  I am investigating porting SWT to D to have a GUI that would use native 
widgets on the host OS when possible, and implemented widgets otherwise.  IBM 
has had great success with this library, its primary use being Eclipse IDE.  I 
know this is YAGUI (Yet another GUI) - however I want a platform-independent
GUI 
without having to distribute GTK+ or any other library on Win32.
Before you start that maybe you could influence us to change to SWT instead of wxWindows. maybe it's better! we are not married to wxWindows. SWT looks very good actually. As a more recent toolkit it has all the probability of being better. (the wx Project probably will not have a GTK soon. I thought we were going to do the native windows and one X11 (or universal) to start with.) Will you be interested in join us if we change to SWT? What do you say guys is SWT better then wxWindows (I'm telling you, it might be - not that I looked in detail to any... ;) these projects are huge (unless you have full time for it) so 4/1 is better then (3+1)/2. Ant
Jan 20 2004
next sibling parent reply Brad Anderson <brad sankaty.dot.com> writes:
It is nothing more than a "gut" feel on SWT.  You touched on some of the
issues. 
    (More recent toolkit, heavy support from IBM).

SWT-4D will need to wrap GTK for the *nix world (like SWT does), so in a sense, 
we would be replacing DUI with SWT-4D/GTK, and making the calls to native Win32 
have the same wrappers.

I have thought that maybe DUI's wrappers of GTK could be modified to use native 
Win32 calls and then we have the beginnings of a platform independent GUI. 
Then 
we've created a third option in addition to wxWindows and SWT.  But I'm pretty 
sure that the Eclipse/SWT group at IBM has had experience far beyond GTK/linux 
and Windows, as has wxWindows with their long history.  So I lean toward one of 
the existing two, and for some reason I lean further toward SWT.

One reason may be that it's in Java, a language far easier for me to port to D 
than C++.  (By the way, we are talking about a port to D, right?  I wouldn't be 
interested in wrapping the Java and requiring a JVM.)  That just has to do with 
my skill set.  The C portion of SWT source has to do with the JNI/native calls, 
and the meat of SWT is in the Java classes.  D doesn't need JNI, except to wrap 
the calls in an *.h file.

I am only investigating SWT, but everything looks favorable.  I haven't 
downloaded SWT's Linux/GTK source yet, but the Win32 source makes a lot of 
sense, and looks like it could be moved to D.  If you want to research SWT
more, 
that would be great.  And I'll definitely join you and help however I can...

Cheers,
Brad



Ant wrote:

 In article <buka0h$12k4$1 digitaldaemon.com>, Brad Anderson says...
 
2.  I am investigating porting SWT to D to have a GUI that would use native 
widgets on the host OS when possible, and implemented widgets otherwise.  IBM 
has had great success with this library, its primary use being Eclipse IDE.  I 
know this is YAGUI (Yet another GUI) - however I want a platform-independent
GUI 
without having to distribute GTK+ or any other library on Win32.
Before you start that maybe you could influence us to change to SWT instead of wxWindows. maybe it's better! we are not married to wxWindows. SWT looks very good actually. As a more recent toolkit it has all the probability of being better. (the wx Project probably will not have a GTK soon. I thought we were going to do the native windows and one X11 (or universal) to start with.) Will you be interested in join us if we change to SWT? What do you say guys is SWT better then wxWindows (I'm telling you, it might be - not that I looked in detail to any... ;) these projects are huge (unless you have full time for it) so 4/1 is better then (3+1)/2. Ant
Jan 20 2004
next sibling parent Brad Anderson <brad sankaty.dot.com> writes:
Further, nobody is talking about XUL.  That's the XML User Interface Language 
that was used to build Mozilla, Firebird, Thunderbird, etc.  Maybe we strap a 
parser onto some code and go to work implementing XUL-4D.

See here for info:

http://www.mozilla.org/projects/xul/
http://luxor-xul.sourceforge.net/talk/vanx-mar-2003/slides.html#rich-41  (but 
look at the whole page, as it discusses SWT, wxWindows, Qt, etc...)

BA





Brad Anderson wrote:

 It is nothing more than a "gut" feel on SWT.  You touched on some of the 
 issues.    (More recent toolkit, heavy support from IBM).
 
 SWT-4D will need to wrap GTK for the *nix world (like SWT does), so in a 
 sense, we would be replacing DUI with SWT-4D/GTK, and making the calls 
 to native Win32 have the same wrappers.
 
 I have thought that maybe DUI's wrappers of GTK could be modified to use 
 native Win32 calls and then we have the beginnings of a platform 
 independent GUI.  Then we've created a third option in addition to 
 wxWindows and SWT.  But I'm pretty sure that the Eclipse/SWT group at 
 IBM has had experience far beyond GTK/linux and Windows, as has 
 wxWindows with their long history.  So I lean toward one of the existing 
 two, and for some reason I lean further toward SWT.
 
 One reason may be that it's in Java, a language far easier for me to 
 port to D than C++.  (By the way, we are talking about a port to D, 
 right?  I wouldn't be interested in wrapping the Java and requiring a 
 JVM.)  That just has to do with my skill set.  The C portion of SWT 
 source has to do with the JNI/native calls, and the meat of SWT is in 
 the Java classes.  D doesn't need JNI, except to wrap the calls in an 
 *.h file.
 
 I am only investigating SWT, but everything looks favorable.  I haven't 
 downloaded SWT's Linux/GTK source yet, but the Win32 source makes a lot 
 of sense, and looks like it could be moved to D.  If you want to 
 research SWT more, that would be great.  And I'll definitely join you 
 and help however I can...
 
 Cheers,
 Brad
 
 
 
 Ant wrote:
 
 In article <buka0h$12k4$1 digitaldaemon.com>, Brad Anderson says...

 2.  I am investigating porting SWT to D to have a GUI that would use 
 native widgets on the host OS when possible, and implemented widgets 
 otherwise.  IBM has had great success with this library, its primary 
 use being Eclipse IDE.  I know this is YAGUI (Yet another GUI) - 
 however I want a platform-independent GUI without having to 
 distribute GTK+ or any other library on Win32.
Before you start that maybe you could influence us to change to SWT instead of wxWindows. maybe it's better! we are not married to wxWindows. SWT looks very good actually. As a more recent toolkit it has all the probability of being better. (the wx Project probably will not have a GTK soon. I thought we were going to do the native windows and one X11 (or universal) to start with.) Will you be interested in join us if we change to SWT? What do you say guys is SWT better then wxWindows (I'm telling you, it might be - not that I looked in detail to any... ;) these projects are huge (unless you have full time for it) so 4/1 is better then (3+1)/2. Ant
Jan 20 2004
prev sibling next sibling parent reply Andy Friesen <andy ikagames.com> writes:
Brad Anderson wrote:

 It is nothing more than a "gut" feel on SWT.  You touched on some of the 
 issues.    (More recent toolkit, heavy support from IBM).
 
 SWT-4D will need to wrap GTK for the *nix world (like SWT does), so in a 
 sense, we would be replacing DUI with SWT-4D/GTK, and making the calls 
 to native Win32 have the same wrappers.
This is an awesome idea. I've since learned that GTK takes a very.... unique approach to grouping and arranging widgets. For one, I can't for the life of me find *any* way to simply set the position/size of a UI element. While it's commendable that GTK+ takes the layout manager notion to this extent, it makes wrapping it and win32 a serious pain. For this reason, converting DUI to call win32 instead of GTK would be difficult. Now it's apparent why this crossplatform GUI thing is so hard. ;) (it's all GTKs fault!) -- andy
Jan 20 2004
parent reply Ant <duitoolkit yahoo.ca> writes:
On Tue, 20 Jan 2004 18:09:42 -0800, Andy Friesen wrote:

 Brad Anderson wrote:
 
 
 This is an awesome idea.  I've since learned that GTK takes a very.... 
 unique approach to grouping and arranging widgets.
I fond it natural and familiar!?... Maybe I on the past I used the same toolkit the designer of GTK did.
 For one, I can't for 
 the life of me find *any* way to simply set the position/size of a UI 
 element.
I'm still looking for the xtToolkit way; I think is the best: you just say this widget goes to the left or that and the other goes bellow that one over there...
 While it's commendable that GTK+ takes the layout manager 
 notion to this extent, it makes wrapping it and win32 a serious pain.
 
 For this reason, converting DUI to call win32 instead of GTK would be 
 difficult.
If DUI get's extremelly popular someone will do it (not me:)
 
 Now it's apparent why this crossplatform GUI thing is so hard. ;)
That's why we are going to base the work on some proven existing one. In your GUI you have 2 complete independent implementations of your API.
 
 (it's all GTKs fault!)
??? So, do we think that SWT deserves a look right. (I kinda don't like the look of wxWindows web page and the demos are crappy). Again without looking in detail seems to me that wxWindows is more like a cross platform "environment" and SWT a cross platform GUI toolkitk. It's confusing seeing ODBC as part of wxWindows... I wanna look in more detail to wxWindows and SWT. (but leds is is dragging me away) Ant
Jan 20 2004
parent Andy Friesen <andy ikagames.com> writes:
Ant wrote:
 On Tue, 20 Jan 2004 18:09:42 -0800, Andy Friesen wrote:
 
This is an awesome idea.  I've since learned that GTK takes a very.... 
unique approach to grouping and arranging widgets.
I fond it natural and familiar!?... Maybe I on the past I used the same toolkit the designer of GTK did.
I'm not judging, I just mean that it's very different from most everything else I've used.
 
For one, I can't for 
the life of me find *any* way to simply set the position/size of a UI 
element.
I'm still looking for the xtToolkit way; I think is the best: you just say this widget goes to the left or that and the other goes bellow that one over there...
wx does quite a lot of work to make GTK+ behave like the other implementations. (not the least of which is the custom GtkPizza widget)
 
Now it's apparent why this crossplatform GUI thing is so hard. ;)
That's why we are going to base the work on some proven existing one. In your GUI you have 2 complete independent implementations of your API.
Yup. I never expected to get anywhere. I'm just prototyping for my own amusement. (by the way, I intentionally took exactly the same approach as SWT)
 
(it's all GTKs fault!)
???
That was a joke. ;)
 
 So, do we think that SWT deserves a look right.
 (I kinda don't like the look of wxWindows web page and the demos
 are crappy).
 
SWT already looks like the better choice to me. D has more in common with Java than it does C++. The similarities run deep enough that the conversion would be pretty easy. (large amounts of it could be automated) -- andy
Jan 20 2004
prev sibling next sibling parent reply John Reimer <jjreimer telus.net> writes:
On Tue, 20 Jan 2004 17:15:07 -0600, Brad Anderson wrote:

 It is nothing more than a "gut" feel on SWT.  You touched on some of the
 issues.
     (More recent toolkit, heavy support from IBM).
 
 SWT-4D will need to wrap GTK for the *nix world (like SWT does), so in a
 sense, we would be replacing DUI with SWT-4D/GTK, and making the calls to
 native Win32 have the same wrappers.
 
 I have thought that maybe DUI's wrappers of GTK could be modified to use
 native Win32 calls and then we have the beginnings of a platform
 independent GUI.  Then we've created a third option in addition to
 wxWindows and SWT.  But I'm pretty sure that the Eclipse/SWT group at IBM
 has had experience far beyond GTK/linux and Windows, as has wxWindows with
 their long history.  So I lean toward one of the existing two, and for
 some reason I lean further toward SWT.
 
 One reason may be that it's in Java, a language far easier for me to port
 to D than C++.  (By the way, we are talking about a port to D, right?  I
 wouldn't be interested in wrapping the Java and requiring a JVM.)  That
 just has to do with my skill set.  The C portion of SWT source has to do
 with the JNI/native calls, and the meat of SWT is in the Java classes.  D
 doesn't need JNI, except to wrap the calls in an *.h file.
 
 I am only investigating SWT, but everything looks favorable.  I haven't
 downloaded SWT's Linux/GTK source yet, but the Win32 source makes a lot of
 sense, and looks like it could be moved to D.  If you want to research SWT
 more, that would be great.  And I'll definitely join you and help however
 I can...
 
 Cheers,
 Brad
After a basic investigation of SWT, I have to admit that it looks promising, probably much more promising than wxWindows. The C++ code in wxWindows along with it's religious use of macros makes it a difficult port to D. It's possible, but not easy. SWT uses JNI to connect to platform specific C code. It looks like it is designed to do what we really wanted to do with D. If we could do a D version of SWT, it likely would be a much easier port than wxWindows. The similarities between D and Java are extremely useful in this case (garbage collection, programming style) as was mentioned. I guess my question is, developing ease aside, what would attract more D users? Is SWT as popular as wxWindows? Would the general consensus within the D community be to use one over the other? Since SWT is java oriented thing, I don't know if C++ developers would even be interested in it (as a way to attract them to the D language). On the other hand, perhaps we just need to take the plunge, and get a good solid, crossplatform GUI library implemented. One modeled after SWT might be a good bet. So what would we call it? DWT? :-) Later, John
Jan 20 2004
parent reply Ant <duitoolkit yahoo.ca> writes:
On Tue, 20 Jan 2004 19:40:34 -0800, John Reimer wrote:

 On Tue, 20 Jan 2004 17:15:07 -0600, Brad Anderson wrote:
 
 It is nothing more than a "gut" feel on SWT.  You touched on some of the
 issues.
     (More recent toolkit, heavy support from IBM).
 
 SWT-4D will need to wrap GTK for the *nix world (like SWT does), so in a
 sense, we would be replacing DUI with SWT-4D/GTK, and making the calls to
 native Win32 have the same wrappers.
 
 I have thought that maybe DUI's wrappers of GTK could be modified to use
 native Win32 calls and then we have the beginnings of a platform
 independent GUI.  Then we've created a third option in addition to
 wxWindows and SWT.  But I'm pretty sure that the Eclipse/SWT group at IBM
 has had experience far beyond GTK/linux and Windows, as has wxWindows with
 their long history.  So I lean toward one of the existing two, and for
 some reason I lean further toward SWT.
 
 One reason may be that it's in Java, a language far easier for me to port
 to D than C++.  (By the way, we are talking about a port to D, right?  I
 wouldn't be interested in wrapping the Java and requiring a JVM.)  That
 just has to do with my skill set.  The C portion of SWT source has to do
 with the JNI/native calls, and the meat of SWT is in the Java classes.  D
 doesn't need JNI, except to wrap the calls in an *.h file.
 
 I am only investigating SWT, but everything looks favorable.  I haven't
 downloaded SWT's Linux/GTK source yet, but the Win32 source makes a lot of
 sense, and looks like it could be moved to D.  If you want to research SWT
 more, that would be great.  And I'll definitely join you and help however
 I can...
 
 Cheers,
 Brad
After a basic investigation of SWT, I have to admit that it looks promising, probably much more promising than wxWindows. The C++ code in wxWindows along with it's religious use of macros makes it a difficult port to D. It's possible, but not easy. SWT uses JNI to connect to platform specific C code. It looks like it is designed to do what we really wanted to do with D. If we could do a D version of SWT, it likely would be a much easier port than wxWindows. The similarities between D and Java are extremely useful in this case (garbage collection, programming style) as was mentioned. I guess my question is, developing ease aside, what would attract more D users? Is SWT as popular as wxWindows? Would the general consensus within the D community be to use one over the other? Since SWT is java oriented thing, I don't know if C++ developers would even be interested in it (as a way to attract them to the D language). On the other hand, perhaps we just need to take the plunge, and get a good solid, crossplatform GUI library implemented. One modeled after SWT might be a good bet. So what would we call it? DWT? :-)
very well said. I don't believe there are many project using SWT What's the license on SWT? (One detail I just saw on SWT it uses the beloved listener interfaces. we would probably change the entire event processing (?)) A couple of (almost random selected) SWT links (go to IBM.com and search for SWT): http://www-106.ibm.com/developerworks/opensource/library/os-ecgui1/ http://www-106.ibm.com/developerworks/java/library/j-nativegui2/ (DWT as name is awfull) Ant
Jan 20 2004
parent reply "Walter" <walter digitalmars.com> writes:
"Ant" <duitoolkit yahoo.ca> wrote in message
news:pan.2004.01.21.03.44.02.162329 yahoo.ca...
 What's the license on SWT?
That's the first thing to check. If it doesn't have a compatible license, there's no point in looking at it any further. It must be one of: 1) public domain 2) copyrighted, but freely modifiable and redistributable for any purpose 3) GPL
Jan 22 2004
next sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Walter wrote:

 "Ant" <duitoolkit yahoo.ca> wrote in message
 news:pan.2004.01.21.03.44.02.162329 yahoo.ca...
 
What's the license on SWT?
That's the first thing to check. If it doesn't have a compatible license, there's no point in looking at it any further. It must be one of: 1) public domain 2) copyrighted, but freely modifiable and redistributable for any purpose 3) GPL
Not really. AFAIK it is quite possible to implement the same interface as long as neither implementation or documentation is copied from the other. An example is Coin (www.coin3d.org) that is an implementation of the Open Inventor API. The rights to the name is owned by a totally different company. My impression is that TGS (todays owners of Open Inventor) sees SIM's Coin as healthy competition. Coin from SIM and Open Inventor from TGS is fully compatible (except where they have some differing extra features). When it comes to SWT, it isn't even the same language and the problem should be even less. Of course, IBM is a huge company and might think in other ways than TGS. Lars Ivar Igesund
Jan 22 2004
parent "Walter" <walter digitalmars.com> writes:
"Lars Ivar Igesund" <larsivar igesund.net> wrote in message
news:bup1o3$2k3i$1 digitaldaemon.com...
 Not really. AFAIK it is quite possible to implement the same interface
 as long as neither implementation or documentation is copied from the
 other.
True, that's called a "clean room" implementation. It's not worth the bother, though, if the original meets one of those 3 requirements.
Jan 23 2004
prev sibling next sibling parent reply Brad Anderson <brad sankaty.dot.com> writes:

from below, but I'm not sure why it has to be the GPL.

Also, I don't know if we have to use the CPL if we rewrite the entire thing in
D 
code.  We would not be changing/modifying any of their Java code.  We could 
choose any number of licenses to use.  I would probably just continue on using 
the CPL, and at the same time, give credit to the original contributors of the 
SWT Java code as providing us with a framework / starting point.

But I'm not a lawyer.

BA

Walter wrote:
 "Ant" <duitoolkit yahoo.ca> wrote in message
 news:pan.2004.01.21.03.44.02.162329 yahoo.ca...
 
What's the license on SWT?
That's the first thing to check. If it doesn't have a compatible license, there's no point in looking at it any further. It must be one of: 1) public domain 2) copyrighted, but freely modifiable and redistributable for any purpose 3) GPL
Jan 22 2004
next sibling parent reply J C Calvarese <jcc7 cox.net> writes:
Brad Anderson wrote:


 
 Also, I don't know if we have to use the CPL if we rewrite the entire 
 thing in D code.  We would not be changing/modifying any of their Java 
 code.  We could choose any number of licenses to use.  I would probably 
 just continue on using the CPL, and at the same time, give credit to the 
 original contributors of the SWT Java code as providing us with a 
 framework / starting point.
 
 But I'm not a lawyer.
I'm not a lawyer either, but it seems to me that what you're talking about doing (some sort of port) would be considered a "derivative". Thus, the GUI library itself would have to be open source (the Common Public License in particular). "Contributions do not include additions to the Program which: (i) are separate modules of software distributed in conjunction with the Program under their own license agreement, and (ii) are not derivative works of the Program." http://www.opensource.org/licenses/cpl.php But commercial applications ("separate modules") could utilitize this SWT-based library without going open source ("their own license agreement"). I should probably stop now, since I'm already in over my head. :) Another fun link: http://sourceforge.net/projects/libswt
 
 BA
 
 Walter wrote:
 
 "Ant" <duitoolkit yahoo.ca> wrote in message
 news:pan.2004.01.21.03.44.02.162329 yahoo.ca...

 What's the license on SWT?
That's the first thing to check. If it doesn't have a compatible license, there's no point in looking at it any further. It must be one of: 1) public domain 2) copyrighted, but freely modifiable and redistributable for any purpose 3) GPL
-- Justin http://jcc_7.tripod.com/d/
Jan 22 2004
parent Brad Anderson <brad sankaty.dot.com> writes:
 I'm not a lawyer either, but it seems to me that what you're talking 
 about doing (some sort of port) would be considered a "derivative". 
 Thus, the GUI library itself would have to be open source (the Common 
 Public License in particular).
Yeah, I was going to mention that it would be a derivative work. I have no problem making this library open source.
 "Contributions do not include additions to the Program which: (i) are 
 separate modules of software distributed in conjunction with the Program 
 under their own license agreement, and (ii) are not derivative works of 
 the Program."
 http://www.opensource.org/licenses/cpl.php
 
 But commercial applications ("separate modules") could utilitize this 
 SWT-based library without going open source ("their own license 
 agreement").  
I would think that if they change the code to suit their needs (i.e. a derivative work of the original), that they would have to put their changes back in the public domain. But just using it would be no problem. We'll most likely need to consult a lawyer if the effort looks like it could be feasible and we have momentum... BA
Jan 22 2004
prev sibling parent "Walter" <walter digitalmars.com> writes:
"Brad Anderson" <brad sankaty.dot.com> wrote in message
news:bup242$2kgr$1 digitaldaemon.com...

 from below, but I'm not sure why it has to be the GPL.
We need one of the three, not all of them.
 Also, I don't know if we have to use the CPL if we rewrite the entire
thing in D
 code.  We would not be changing/modifying any of their Java code.  We
could
 choose any number of licenses to use.  I would probably just continue on
using
 the CPL, and at the same time, give credit to the original contributors of
the
 SWT Java code as providing us with a framework / starting point.

 But I'm not a lawyer.
Doing a line by line translation of the code makes it a derived work, subject to the original copyright.
Jan 23 2004
prev sibling parent Andy Friesen <andy ikagames.com> writes:
Walter wrote:
 "Ant" <duitoolkit yahoo.ca> wrote in message
 news:pan.2004.01.21.03.44.02.162329 yahoo.ca...
 
What's the license on SWT?
That's the first thing to check. If it doesn't have a compatible license, there's no point in looking at it any further. It must be one of: 1) public domain 2) copyrighted, but freely modifiable and redistributable for any purpose 3) GPL
I would argue that SWT would be useless to us if it was GPL. D needs a toolkit for everybody, not just open source developers. (of course, this is a nonissue, as SWT is not GPL) -- andy
Jan 22 2004
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Brad Anderson" <brad sankaty.dot.com> wrote in message
news:bukd2i$17hb$1 digitaldaemon.com...
 One reason may be that it's in Java, a language far easier for me to port
to D
 than C++.
I never thought about that. It might even be possible to do machine translation of Java to D. (Of course, that wouldn't help with the differences in the underlying runtime libraries, and one has to be careful that the Java code being translated is public domain or freely redistributable or GPL.)
  (By the way, we are talking about a port to D, right?
Yes.
  I wouldn't be
 interested in wrapping the Java and requiring a JVM.)
I doubt many would be interested in the results of that, either <g>.
Jan 22 2004
parent reply Ant <Ant_member pathlink.com> writes:
In article <buougc$2f48$1 digitaldaemon.com>, Walter says...
"Brad Anderson" <brad sankaty.dot.com> wrote in message
news:bukd2i$17hb$1 digitaldaemon.com...
 One reason may be that it's in Java, a language far easier for me to port
to D
 than C++.
I never thought about that. It might even be possible to do machine translation of Java to D. (Of course, that wouldn't help with the differences in the underlying runtime libraries,
maybe creating String and Vector classes (maybe a couple more, Array template class?) would be easier then doing some complex conversion. (will D purists complain?) then just add "alias bit boolean;" and rename to .d, should compile. Ant
Jan 22 2004
next sibling parent reply Brad Anderson <brad sankaty.dot.com> writes:
It's not quite that easy...  I'm trying to get the interfaces and abstract
class 
calls correct with all of the objects currently (in our port of SWT to D). 
Things like:

    public class Canvas extends Composite {}

becomes

    public class Canvas: Composite {}

and I have no idea what to do with:

    public abstract class Control extends Widget implements Drawable {}

Any thoughts?

BA


Ant wrote:

 In article <buougc$2f48$1 digitaldaemon.com>, Walter says...
 
"Brad Anderson" <brad sankaty.dot.com> wrote in message
news:bukd2i$17hb$1 digitaldaemon.com...

One reason may be that it's in Java, a language far easier for me to port
to D
than C++.
I never thought about that. It might even be possible to do machine translation of Java to D. (Of course, that wouldn't help with the differences in the underlying runtime libraries,
maybe creating String and Vector classes (maybe a couple more, Array template class?) would be easier then doing some complex conversion. (will D purists complain?) then just add "alias bit boolean;" and rename to .d, should compile. Ant
Jan 22 2004
next sibling parent "Carlos Santander B." <carlos8294 msn.com> writes:
"Brad Anderson" <brad sankaty.dot.com> wrote in message
news:bupcdr$3v1$1 digitaldaemon.com...
| It's not quite that easy...  I'm trying to get the interfaces and abstract
class
| calls correct with all of the objects currently (in our port of SWT to D).
| Things like:
|
|     public class Canvas extends Composite {}
|
| becomes
|
|     public class Canvas: Composite {}
|
| and I have no idea what to do with:
|
|     public abstract class Control extends Widget implements Drawable {}
|
| Any thoughts?
|
| BA
|

I believe it'd be:

public abstract class Control : Widget , Drawable {}

-----------------------
Carlos Santander Bernal
Jan 22 2004
prev sibling parent Ant <Ant_member pathlink.com> writes:
In article <bupcdr$3v1$1 digitaldaemon.com>, Brad Anderson says...
It's not quite that easy...
you whish... ;)
 I'm trying to get the interfaces and abstract class 
calls correct with all of the objects currently (in our port of SWT to D). 
Things like:

    public class Canvas extends Composite {}

becomes

    public class Canvas: Composite {}

and I have no idea what to do with:

    public abstract class Control extends Widget implements Drawable {}

Any thoughts?
The abstract classes are going to be a problem. The D abstract classes are still a mistery to me, I thing the java abstract classes work better. Other people have reported issues with D abstract classes. (At the first sign of trouble with abstract classes on my D projects I just do an empty implementations of the methods. That works for small projects, we need real abstract classes on D.) I expected abstract classes to be all over... the "extend, implement" are part of a simple conversion: `replace all "extends" with ":"` `replace all "implements" with ","` of course it's not that simple either (what if there is no "extends") but that's why we still have a job (the lucky ones)! I'm dreaming that my leds D parser can easelly be modified to parse java; then we would say "save as D" :) Actually I can't think of any java construct that cannot be handled by my parseD... oh yea: {} static initilization blocks. And of course the parser is not married to leds. When I started it it was suppose to be flexible for most "{" languages but some uggly patches got in... I was going to review the properties UI on leds today, maybe I'll look into the parser instead... (hmmm... if I do the properties UI I can do a usable leds release...) Ant (vaporware? like the windows version of leds, sorry...) http://leds.sourceforge.net
Jan 22 2004
prev sibling parent "Walter" <walter digitalmars.com> writes:
"Ant" <Ant_member pathlink.com> wrote in message
news:bup1eo$2jj6$1 digitaldaemon.com...
 In article <buougc$2f48$1 digitaldaemon.com>, Walter says...
"Brad Anderson" <brad sankaty.dot.com> wrote in message
news:bukd2i$17hb$1 digitaldaemon.com...
 One reason may be that it's in Java, a language far easier for me to
port
to D
 than C++.
I never thought about that. It might even be possible to do machine translation of Java to D. (Of course, that wouldn't help with the differences in the underlying runtime libraries,
maybe creating String and Vector classes (maybe a couple more, Array template class?) would be easier then doing some complex conversion. (will D purists complain?) then just add "alias bit boolean;" and rename to .d, should compile.
A proper D conversion should at least make the effort to replace the String class with D char arrays <g>.
Jan 23 2004
prev sibling next sibling parent reply John Reimer <jjreimer telus.net> writes:
Ok, I guess you guys are discussing the possibility of dropping wxWindows
for SWT.  Keep discussing it a little bit more before you do, please.  It
would be nice to see both sides of the argument.  I'll take a peek at SWT
since I have little knowledge of it (other than having played with
Eclipse).  The interface looks good.  It's developed in Java, you say?
Does it have it's own widget set or does it interface to an underlying
platform API? Unfortunately I'm not a Java developer and don't much like
Java. But since there appear to be more people interested in this port
than wxWindows, it's really hard to argue against it.


On Tue, 20 Jan 2004 22:55:31 +0000, Ant wrote:

 In article <buka0h$12k4$1 digitaldaemon.com>, Brad Anderson says...
2.  I am investigating porting SWT to D to have a GUI that would use
native widgets on the host OS when possible, and implemented widgets
otherwise.  IBM has had great success with this library, its primary use
being Eclipse IDE.  I know this is YAGUI (Yet another GUI) - however I
want a platform-independent GUI without having to distribute GTK+ or any
other library on Win32.
Before you start that maybe you could influence us to change to SWT instead of wxWindows. maybe it's better! we are not married to wxWindows. SWT looks very good actually. As a more recent toolkit it has all the probability of being better. (the wx Project probably will not have a GTK soon. I thought we were going to do the native windows and one X11 (or universal) to start with.) Will you be interested in join us if we change to SWT? What do you say guys is SWT better then wxWindows (I'm telling you, it might be - not that I looked in detail to any... ;) these projects are huge (unless you have full time for it) so 4/1 is better then (3+1)/2. Ant
Jan 20 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
My undoubtedly unpopular opinion:

I think that the GUI should _never_ be in the standard library, and that
there should _always_ be at least two competing GUI libraries. Otherwise,
stagnation beckons.



"John Reimer" <jjreimer telus.net> wrote in message
news:pan.2004.01.21.02.23.37.232507 telus.net...
 Ok, I guess you guys are discussing the possibility of dropping wxWindows
 for SWT.  Keep discussing it a little bit more before you do, please.  It
 would be nice to see both sides of the argument.  I'll take a peek at SWT
 since I have little knowledge of it (other than having played with
 Eclipse).  The interface looks good.  It's developed in Java, you say?
 Does it have it's own widget set or does it interface to an underlying
 platform API? Unfortunately I'm not a Java developer and don't much like
 Java. But since there appear to be more people interested in this port
 than wxWindows, it's really hard to argue against it.


 On Tue, 20 Jan 2004 22:55:31 +0000, Ant wrote:

 In article <buka0h$12k4$1 digitaldaemon.com>, Brad Anderson says...
2.  I am investigating porting SWT to D to have a GUI that would use
native widgets on the host OS when possible, and implemented widgets
otherwise.  IBM has had great success with this library, its primary use
being Eclipse IDE.  I know this is YAGUI (Yet another GUI) - however I
want a platform-independent GUI without having to distribute GTK+ or any
other library on Win32.
Before you start that maybe you could influence us to change to SWT instead of wxWindows. maybe it's better! we are not married to wxWindows. SWT looks very good actually. As a more recent toolkit it has all the probability of being better. (the wx Project probably will not have a GTK soon. I thought we were
going
 to do the native windows and one X11 (or universal) to start with.)

 Will you be interested in join us if we change to SWT?

 What do you say guys is SWT better then wxWindows (I'm telling you, it
 might be - not that I looked in detail to any... ;)

 these projects are huge (unless you have full time for it) so 4/1 is
 better then (3+1)/2.

 Ant
Jan 20 2004
next sibling parent Ant <duitoolkit yahoo.ca> writes:
On Wed, 21 Jan 2004 15:00:16 +1100, Matthew wrote:

 My undoubtedly unpopular opinion:
 
 I think that the GUI should _never_ be in the standard library,
I thing you're right. The idea is to create something that would be widelly used for D GUI development and that attracts support from many developers. How is distributed is irrelevant. If it has quality it will be used and DM will endorse it. (hey, even DUI has a link from the D pages ;)
 and that
 there should _always_ be at least two competing GUI libraries.
 Otherwise, stagnation beckons.
You can always start your own;) (that why I'm gonna start the D++ project it's a joke) DUI is here to stay, don't worry. Already has (almost complete) support to Linux and Windows. (but still is going to have a major change on the event processing) Ant http://dui.sourceforge.net
Jan 20 2004
prev sibling next sibling parent John Reimer <jjreimer telus.net> writes:
On Wed, 21 Jan 2004 15:00:16 +1100, Matthew wrote:

 My undoubtedly unpopular opinion:
 
 I think that the GUI should _never_ be in the standard library, and that
 there should _always_ be at least two competing GUI libraries. Otherwise,
 stagnation beckons.
 
 
The GUI in the standard library? I don't think that was our intention. I may have slipped and made it sound that way earlier. All we want to do is make a good crossplatform GUI toolkit for D. Where it goes can be decided later. I guess some competition would be very good, yes. But at this point there aren't an over abundance of developers to try developing different GUI toolkits. One good solid kit would be nice for now with several people contributing. Otherwise, we still have DUI and DIG. Our main goal, so I thought, was to develop a comprehensive, well-supported, crossplatform library for D, something it does not have at the moment (DUI comes closest). This library could, at some point perhaps, be included as an extra with the compiler suite (it doesn't have t be THE standard library, though). This library should provide an interface that should compile without changes on either platform. wxWindows almost achieves this goal for C++. That's why it was one of my first interests as a port. But C++ does not translate well to D, so it may not be a wise initial task to take on. Not without experienced help at least. I may play with it a bit behind the scenes for interest sake, but I still want to see a main GUI project come to fruition. Later, John
Jan 20 2004
prev sibling next sibling parent Georg Wrede <Georg_member pathlink.com> writes:
In article <buktia$212c$1 digitaldaemon.com>, Matthew says...
My undoubtedly unpopular opinion:
Er, let's change that to 'controversial'. :-)
I think that the GUI should _never_ be in the standard library, and that
there should _always_ be at least two competing GUI libraries. Otherwise,
stagnation beckons.
You're absolutely right, on both accounts. However, we do need a gui that comes with at least Digital Mars D, and which has precisely the same API on both Windows and Linux. And, while DMD is not Open Source, the GUI should be. (I think Walter would okay this?) As to stagnation, while you're right there too, I think it is a matter of _perceived_ competition. For the time being, the D community perceives other languages that have GUI libraries, as competition. Later, when D gets established, stagnation becomes a risk unless we then have more than one GUI. Also, we do not have to, and actually should not, divide our powers between GUIs right now! We are too few to pull it off. If all goes like we wish, then by this time next year, D has a large enough following that we will see another port emerge anyhow. This would give us more than one good, working, GUI by the time any risk for GUI stagnation would emerge.
Jan 21 2004
prev sibling parent "Walter" <walter digitalmars.com> writes:
"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:buktia$212c$1 digitaldaemon.com...
 My undoubtedly unpopular opinion:

 I think that the GUI should _never_ be in the standard library,
I agree. That said, I still think a GUI should ship with D as an add-on.
 and that
 there should _always_ be at least two competing GUI libraries. Otherwise,
 stagnation beckons.
As many as D users want to create! The thing SWT may have going for it over wxWindows is it may be far easier to do a D conversion of it. I looked over the wxWindows source, and while fortunately it doesn't mire itself in weird C++-isms, it will require a lot of hand work. The conversion of memory management to garbage collection comes to mind, along with being careful not to goof up other resource management.
Jan 22 2004
prev sibling parent reply Ilya Minkov <minkov cs.tum.edu> writes:
Ant wrote:
 (the wx Project probably will not have a GTK soon.
 I thought we were going to do the native windows and one X11
 (or universal) to start with.)
Ur, what? wxWindows compiles using DMC++, and there were plans on wrapping it using SWIG. This would make all wxWindows ports available at once and with no effort. Wrapping instead of porting. Btw, to drop an idea: to have a lightweight GUI working right off and easy to port, FLTK has the best architecture and shoud be a snap to port *completely*. However, it's by its sole idea program-drawn, not OS or underlying toolkit! Skinning is done easily, attempts to "native" look are bound to have "the Swing problem" multiplied by 10! -eye
Jan 23 2004
parent Ant <Ant_member pathlink.com> writes:
In article <burnut$vst$1 digitaldaemon.com>, Ilya Minkov says...
Ant wrote:
 (the wx Project probably will not have a GTK soon.
 I thought we were going to do the native windows and one X11
 (or universal) to start with.)
Ur, what?
Out of context. I meant "our" wx project. But after all seems that's the most recent idea is to wrap GTK in SWT talk.
Btw, to drop an idea: to have a lightweight GUI working right off and 
easy to port, FLTK has the best architecture and shoud be a snap to port 
*completely*. However, it's by its sole idea program-drawn, not OS or 
underlying toolkit! Skinning is done easily, attempts to "native" look 
are bound to have "the Swing problem" multiplied by 10!
There are many toolkits out there... probable more toolkits then people able to work on them on D. Ant
Jan 23 2004
prev sibling parent reply "Kris" <someidiot earthlink.net> writes:
A couple of years back I wrote a standalone Java servlet-server; totally
secure and faster than anything else available. I've been thinking about
porting this to D (perhaps using the OpenD.org Sockets package), if there's
not already something similar?

What do you think -- a servlet-style HTTP server in D, for D?

- Kris


"C" <dont respond.com> wrote in message
news:btnk5a$2hrc$1 digitaldaemon.com...
 I was just wondering what everyone else is working on.  I think it would
be
 cool to have a refrence , so were not duplicating each other and stuff :).

 Im working on Windy as you might know ( GUI toolkit ).  I'm also going to
 start a mysql module soon.

 You guys ?

 C
Feb 20 2004
next sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
Excellent! Do it.

I'll be happy to review it when you're done.




"Kris" <someidiot earthlink.net> wrote in message
news:c1646d$164u$1 digitaldaemon.com...
 A couple of years back I wrote a standalone Java servlet-server; totally
 secure and faster than anything else available. I've been thinking about
 porting this to D (perhaps using the OpenD.org Sockets package), if
there's
 not already something similar?

 What do you think -- a servlet-style HTTP server in D, for D?

 - Kris


 "C" <dont respond.com> wrote in message
 news:btnk5a$2hrc$1 digitaldaemon.com...
 I was just wondering what everyone else is working on.  I think it would
be
 cool to have a refrence , so were not duplicating each other and stuff
:).
 Im working on Windy as you might know ( GUI toolkit ).  I'm also going
to
 start a mysql module soon.

 You guys ?

 C
Feb 20 2004
prev sibling parent reply Brad Anderson <brad sankaty.dot.com> writes:
Kris wrote:
 A couple of years back I wrote a standalone Java servlet-server; totally
 secure and faster than anything else available. I've been thinking about
 porting this to D (perhaps using the OpenD.org Sockets package), if there's
 not already something similar?
 
 What do you think -- a servlet-style HTTP server in D, for D?
<drool> I think this would be fantastic project. I'd like to help, but I'm busy on other things at the moment. I will, however, join Matthew in offering review and testing. D Server Pages or DSP </drool>
Feb 21 2004
parent reply "Kris" <someidiot earthlink.net> writes:
DSP huh?  Funny, I was (ESP) thinking the same thing .... that's a cool name
Brad :-)

Didn't Nicholas Wirth once say "designing a Language is easy, but coming up
with a great name is really hard" ?

- Kris


"Brad Anderson" <brad sankaty.dot.com> wrote in message
news:c18vgh$9tr$1 digitaldaemon.com...
 Kris wrote:
 A couple of years back I wrote a standalone Java servlet-server; totally
 secure and faster than anything else available. I've been thinking about
 porting this to D (perhaps using the OpenD.org Sockets package), if
there's
 not already something similar?

 What do you think -- a servlet-style HTTP server in D, for D?
<drool> I think this would be fantastic project. I'd like to help, but I'm busy
on
 other things at the moment.  I will, however, join Matthew in offering
review
 and testing.

 D Server Pages or DSP

 </drool>
Feb 22 2004
parent reply Brad Anderson <brad sankaty.dot.com> writes:
Yeah, I'm really *original*.  All by myself, I came up with the name for the 
port of SWT to D:  dwt

I think I've found my calling :D  - Anyone else out there need a name for their 
project?  Bring it on.

BA

Kris wrote:

 DSP huh?  Funny, I was (ESP) thinking the same thing .... that's a cool name
 Brad :-)
 
 Didn't Nicholas Wirth once say "designing a Language is easy, but coming up
 with a great name is really hard" ?
 
 - Kris
 
 
 "Brad Anderson" <brad sankaty.dot.com> wrote in message
 news:c18vgh$9tr$1 digitaldaemon.com...
 
Kris wrote:

A couple of years back I wrote a standalone Java servlet-server; totally
secure and faster than anything else available. I've been thinking about
porting this to D (perhaps using the OpenD.org Sockets package), if
there's
not already something similar?

What do you think -- a servlet-style HTTP server in D, for D?
<drool> I think this would be fantastic project. I'd like to help, but I'm busy
on
other things at the moment.  I will, however, join Matthew in offering
review
and testing.

D Server Pages or DSP

</drool>
Feb 22 2004
parent reply J C Calvarese <jcc7 cox.net> writes:
Brad Anderson wrote:

 Yeah, I'm really *original*.  All by myself, I came up with the name for 
 the port of SWT to D:  dwt
 
 I think I've found my calling :D  - Anyone else out there need a name 
 for their project?  Bring it on.
 
 BA
Ben Hinkle is looking for a name to his compiler that hooks up to GCC: http://www.digitalmars.com/drn-bin/wwwnews?D.gnu/462. I think there have been some good suggestion so far, but he hasn't named a winner yet. -- Justin http://jcc_7.tripod.com/d/
Feb 22 2004
parent reply Brad Anderson <brad sankaty.dot.com> writes:
J C Calvarese wrote:

 Brad Anderson wrote:
 
 Yeah, I'm really *original*.  All by myself, I came up with the name 
 for the port of SWT to D:  dwt

 I think I've found my calling :D  - Anyone else out there need a name 
 for their project?  Bring it on.

 BA
Ben Hinkle is looking for a name to his compiler that hooks up to GCC: http://www.digitalmars.com/drn-bin/wwwnews?D.gnu/462. I think there have been some good suggestion so far, but he hasn't named a winner yet.
I've been watching, but you've taken all of the ones I might have used. I'm such a blatant acronym whore.
Feb 22 2004
parent reply J C Calvarese <jcc7 cox.net> writes:
Brad Anderson wrote:
 J C Calvarese wrote:
 Brad Anderson wrote:
[snip]
 I think I've found my calling :D  - Anyone else out there need a name 
 for their project?  Bring it on.

 BA
Ben Hinkle is looking for a name to his compiler that hooks up to GCC: http://www.digitalmars.com/drn-bin/wwwnews?D.gnu/462. I think there have been some good suggestion so far, but he hasn't named a winner yet.
I've been watching, but you've taken all of the ones I might have used. I'm such a blatant acronym whore.
I think the challenge is threefold: 1. There's an obvious reluctance to reuse an existing name or a name that's too similar (can we call it "dig"? D Interface to GCC). 2. The desire for shortness (who wants to type "OPENSOURCEDFRONTTOGCC" to invoke their favorite compiler?). 3. A sensical name is better than nonsense (let's call it "marmalade" just because it's fun to say). -- Justin http://jcc_7.tripod.com/d/
Feb 22 2004
parent C <dont respond.com> writes:
On Sun, 22 Feb 2004 13:13:55 -0600, J C Calvarese <jcc7 cox.net> wrote:

Marmalade IS fun to say!  I change my vote.

C

 Brad Anderson wrote:
 J C Calvarese wrote:
 Brad Anderson wrote:
[snip]
 I think I've found my calling :D  - Anyone else out there need a na=
me =
 for their project?  Bring it on.

 BA
Ben Hinkle is looking for a name to his compiler that hooks up to GC=
C: =
 http://www.digitalmars.com/drn-bin/wwwnews?D.gnu/462.

 I think there have been some good suggestion so far, but he hasn't =
 named a winner yet.
I've been watching, but you've taken all of the ones I might have =
 used.  I'm such a blatant acronym whore.
I think the challenge is threefold: 1. There's an obvious reluctance to reuse an existing name or a name =
 that's too similar (can we call it "dig"? D Interface to GCC).

 2. The desire for shortness (who wants to type "OPENSOURCEDFRONTTOGCC"=
=
 to invoke their favorite compiler?).

 3. A sensical name is better than nonsense (let's call it "marmalade" =
 just because it's fun to say).
-- = Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Feb 22 2004