BCS schrieb:
> http://svn.dsource.org/projects/dwt-win/ amI missing
> 

yes, you missed the hg (mercurial) part :)

BCS wrote:

> 
> I can't seem to check it out.
> 
> http://svn.dsource.org/projects/dwt-win/ amI missing
> 

Well, first, you need mercurial (hg) to check out the repository.

We moved away from svn because mercurial provides excellent support for distributed repository maintenance.

Once you have the hg package for win32, you do:

hg clone http://hg.dsource.org/projects/dwt-win dwt-win

(where dwt-win is the name of the destination directory)

You will need to download the hg win32 port from here:

http://www.selenic.com/mercurial/wiki/index.cgi/WindowsInstall

I really don't like the confusing number of choices there are mercurial packages for win32.  But take your pick and get it set up by following the instructions on that page.

For dwt-win, I should have provided information on the project wiki giving instructions on how to do this.  I'll try to add that information soon.

Also, be aware that little of the win32 port of dwt has been done yet. So there's not much in the repository at this point, let alone anything working.  If you want to lend me a hand, I'd very much appreciate it.

-JJR

Reply to John,

> BCS wrote:
> 
>> I can't seem to check it out.
>> 
>> http://svn.dsource.org/projects/dwt-win/ amI missing
>> 
> Well, first, you need mercurial (hg) to check out the repository.
> 
> We moved away from svn because mercurial provides excellent support
> for distributed repository maintenance.
> 
[...]
> For dwt-win, I should have provided information on the project wiki
> giving instructions on how to do this.  I'll try to add that
> information soon.

Ideally, I should be able to tell from the front page or one "oh-duh" click away what downloading it will take. Something like some easy to find verbiage along the line of "Download with /Mercurial/ from...."

> 
> Also, be aware that little of the win32 port of dwt has been done yet.
> So there's not much in the repository at this point, let alone
> anything working.  If you want to lend me a hand, I'd very much
> appreciate it.
> 
> -JJR
> 

Is there any other way to get it? I don't think installing another source control system is going to happen any time soon. tarballs would work for me considering I'm not going to be doing dev (I have enough trouble using GUI API's, I don't even want to think about writing one)

BCS wrote:
> Reply to John,
> 
>> BCS wrote:
>>
>>> I can't seem to check it out.
>>>
>>> http://svn.dsource.org/projects/dwt-win/ amI missing
>>>
>> Well, first, you need mercurial (hg) to check out the repository.
>>
>> We moved away from svn because mercurial provides excellent support
>> for distributed repository maintenance.
>>
> [...]
>> For dwt-win, I should have provided information on the project wiki
>> giving instructions on how to do this.  I'll try to add that
>> information soon.
> 
> Ideally, I should be able to tell from the front page or one "oh-duh" click away what downloading it will take. Something like some easy to find verbiage along the line of "Download with /Mercurial/ from...."
> 


Yes, I agree.  I should have done this.


>>
>> Also, be aware that little of the win32 port of dwt has been done yet.
>> So there's not much in the repository at this point, let alone
>> anything working.  If you want to lend me a hand, I'd very much
>> appreciate it.
>>
>> -JJR
>>
> 
> Is there any other way to get it? I don't think installing another source control system is going to happen any time soon. tarballs would work for me considering I'm not going to be doing dev (I have enough trouble using GUI API's, I don't even want to think about writing one)
> 
> 


At this point, since there is nothing working to "get", I don't think we'll provide a tarball of any sort.  But perhaps once things start building properly, we should consider making releases available in an alternative package.  This makes sense.  We'll need some storage options that, at this point, I don't think mercurial provides, but perhaps the Trac system does. I'll have to investigate the options.

-JJR

John Reimer wrote:

> 
> 
> At this point, since there is nothing working to "get", I don't think we'll provide a tarball of any sort.  But perhaps once things start building properly, we should consider making releases available in an alternative package.  This makes sense.  We'll need some storage options that, at this point, I don't think mercurial provides, but perhaps the Trac system does. I'll have to investigate the options.
> 


Let me just clarify here... I'm referring to the dwt-win project (since I know that dwt-linux is working right now).  Either way, we should investigate a way of packaging working releases, eventually.

-JJR

Reply to John,

> John Reimer wrote:
> 
>> At this point, since there is nothing working to "get", I don't think
>> we'll provide a tarball of any sort.  But perhaps once things start
>> building properly, we should consider making releases available in an
>> alternative package.  This makes sense.  We'll need some storage
>> options that, at this point, I don't think mercurial provides, but
>> perhaps the Trac system does. I'll have to investigate the options.
>> 
> Let me just clarify here... I'm referring to the dwt-win project
> (since I know that dwt-linux is working right now).  Either way, we
> should investigate a way of packaging working releases, eventually.
> 
> -JJR
> 

is there a linux tar-ball?

BCS wrote:
> Reply to John,
> 
>> John Reimer wrote:
>>
>>> At this point, since there is nothing working to "get", I don't think
>>> we'll provide a tarball of any sort.  But perhaps once things start
>>> building properly, we should consider making releases available in an
>>> alternative package.  This makes sense.  We'll need some storage
>>> options that, at this point, I don't think mercurial provides, but
>>> perhaps the Trac system does. I'll have to investigate the options.
>>>
>> Let me just clarify here... I'm referring to the dwt-win project
>> (since I know that dwt-linux is working right now).  Either way, we
>> should investigate a way of packaging working releases, eventually.
>>
>> -JJR
>>
> 
> is there a linux tar-ball?
> 
> 


No, not yet. :)

BCS wrote:

> [...]
>> For dwt-win, I should have provided information on the project wiki
>> giving instructions on how to do this.  I'll try to add that
>> information soon.
> 
> Ideally, I should be able to tell from the front page or one "oh-duh" click away what downloading it will take. Something like some easy to find verbiage along the line of "Download with /Mercurial/ from...."
> 

I've updated the dwt-win front page.

doob wrote:

> Frank Benoit wrote:
>> doob schrieb:
>>> This is great news and I would be happy to help. I can help testing both the linux and windows version. Any plans on an osx version?
>>
>> No plans for OSX for now. Doing this means to do the whole port again, because OSX will use the native widget from OSX and so its implementation is very different from the gtk/win.
>>
>> But, if you want to start this, you are welcome. I can assist with some swt specific knowledge and experience how to do the porting efficient.
> 
> I thought it was quite a big different between win and gtk and that it also would about be that to osx.

One of the problems when doing native Mac OS X support for the
other two SWT ports (DWT/3.0 and Tioport/3.2) was interfacing
with the system headers for either of Carbon or Cocoa frameworks.

First was converting the headers to D (either all of it, or just
"extern" the snippets needed) and second was shipping this API
conversion in some format that doesn't violate Apple copyrights.

For SWT this is solved by a) using C so they can link directly
to the system headers by #include and b) getting Apple consent.
DWT would probably also have to solve both issues for Mac OS X ?

wxD works around this problem by using C++ to access the system
headers, and by not needing to ship any GUI system API interfaces.
And besides, it just uses the wxWidgets libraries to handle that...

--anders

PS. Same goes for the Code::Blocks support, which also uses C++.
    (i.e. instead of porting C::B over to D, it just extends it
    using C++ and the Squirrel scripting language for D support)

    Like http://wxd.sourceforge.net/wxd-codeblocks-wizard.png

Anders F Björklund wrote:
> doob wrote:
> 
>> Frank Benoit wrote:
>>> doob schrieb:
>>>> This is great news and I would be happy to help. I can help testing both the linux and windows version. Any plans on an osx version?
>>>
>>> No plans for OSX for now. Doing this means to do the whole port again, because OSX will use the native widget from OSX and so its implementation is very different from the gtk/win.
>>>
>>> But, if you want to start this, you are welcome. I can assist with some swt specific knowledge and experience how to do the porting efficient.
>>
>> I thought it was quite a big different between win and gtk and that it also would about be that to osx.
> 
> One of the problems when doing native Mac OS X support for the
> other two SWT ports (DWT/3.0 and Tioport/3.2) was interfacing
> with the system headers for either of Carbon or Cocoa frameworks.
> 
> First was converting the headers to D (either all of it, or just
> "extern" the snippets needed) and second was shipping this API
> conversion in some format that doesn't violate Apple copyrights.
> 
> For SWT this is solved by a) using C so they can link directly
> to the system headers by #include and b) getting Apple consent.
> DWT would probably also have to solve both issues for Mac OS X ?
> 


The SWT team needed Apple consent to use the C system headers? :(

-JJR