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

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

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

The license is the Common Public License for the Java code.  We get #1 and #2 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
> 
> 

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

"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

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

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

Brad Anderson wrote:
> The license is the Common Public License for the Java code.  We get #1 and #2 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.

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/

> 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