I have some ample spare time coming in the next few weeks to start, then hobby time from there on, and before I dug into the port, I'm curious on a few things.

I take it ticketing isn't being used as of yet [1]. Which considering the depth of the project I'm assuming it's hack till it works for now. No dramas. However,

What has and hasn't been done? What is everyone heading into? The blessing of a decentralized SCM is that everyone can do what they want with ease. The curse is that without solid communication there seems like there could be quite a bit of possible toe stepping going on.

So as an outsider wanting in, what has and hasn't been worked on thus far? Meaning, if you could write 5 things that you know *has* to be done, what would they be? And what is everyone working on, I'd love to help, but I really don't want to duplicate effort.

I caught the bundles mention in the wiki, we're sending them to where?

If you have particulars in the port that you need done but in the middle of something else, feel free to throw them up, these are things that I'm interested in doing.
-
I would like to start going behind the work involved and start seeing what needs to be done to start pulling in SWT's 3.4 changes. SWT having a 12-18 month release schedule means that it'll be stable for quite some time. Also, traditionally there isn't any changes between milestones in regards to the api itself, just feature adding and implementation/bug fixing. So I don't think it'll be all that fluid.

It should also keep dwt up to speed. So there isn't always a situation where features are being chased. By time DWT is up to snuff and considered something of a 1.0 will be about the time 3.4 will be out of milestone phase and be considered final. This has the added benefit that it means there is another 12-18 months to have to worry about catching up all over again.
-
Performance/API/Testing/Documentation

There's something to be said about SWT's API. While crufty compared to what it could be, it allows inherited documentation and examples. However, the actual underlying implementation could use some solid clean up to get the java'isms out. (Dynamic arrays, default argument values, etc could be used quite a bit. Structs could be used quite liberally where "class is all we have in java land" etiquette is used).

But I would like to clean up/discuss underlying changes once we're aware that the ported code works. Obviously this is a down the road thing.

That being said, I think it would be a solid idea to do some unit testing on things that can be blackboxed into tests. Obviously with the massive scale that is SWT unit testing across the board would be a massive and frankly hard task at hand. But anything that can be blackboxed (ie, not have functionality spread across 16 classes) and gets some performance/d'ism treatment should get some unit tests. Following Tango's approach to unit testing seems sound.

I don't think that changing the api would be wise on it's own, but it may be worthwhile to create a d wrapper that overlaps dwt to clean up the implementation would be worthwhile.
-
Nebula ports
I don't know the opinion on the nebula project from a dwt point of view, but I would like to start working on porting it over. I'm assuming it's going to be a dwt-addon.
-
Is an OSGI port being considered? It's not directly related, but is needed for JFace IIRC. I don't have any idea how hard it would be to do in D with it's limited reflective abilities, but I do know of an objective-c implementation. So I'm assuming it's possible.

[1] http://www.dsource.org/projects/dwt/report/1

Ok, it's getting late. Just wanted to get a feel of what needed to be done, and what people were working on so I can get involved without tripping.

-Robby

Hi Robby,

nice to see you again. I wanted to contact you on your last questions about SWT, but it seems my mail went to spam?

At the moment I think doing duplicated effort is not really the problem :)
But to be sure, you can make a ticket in the related *sub*-projects and say in the text that you want to do this task. Perhaps you can inform or talk with me per mail or in IRC #dwt. Tasks that come to my mind:

dwt-win:
dwt.widgets.DirectoryDialog
dwt.program.Program

dwt-linux:
dwt.widgets.DateTime
dwt.program.Program

dwt-samples:
PaintExample
LayoutExample
(Custom)ControlExample Set/Get Api

If you have something to contribute, please see
http://www.dsource.org/projects/dwt/wiki/Contribution

SWT 3.4 is no issue at the moment. First we want to have DWT 3.3 running with all widgets stable and with the installation problems solved and more examples.

We do /not/ want to get the java'ism out. Instead we explicitely want to stay as near as possible at the java implementation. The reason is, that later merges are far easier done. Certainly in some cases this is not possible and in other cases we want additionally methods, that is OK.

Unittests:
Unittest are available in the SWT project. So this can be a good starting point.

Nebula:
Porting nebula could be done in the dwt-addons project. Is the license of nebula ok with doing this?

OSGi:
OSGi is used for plugins in Java and relies on its own class loaders.
Perhaps it can be omitted when using a fixed composition of components at compile time.

Frank

Comments inline Frank

Frank Benoit wrote:
> Hi Robby,
> 
> nice to see you again. I wanted to contact you on your last questions about SWT, but it seems my mail went to spam?

It must have, I ran through the gmail account and nothing resulted. So I'm assuming spam and gone. Not sure why though, but it shouldn't happen again.

I just caught your message to my post on this very effort a month or so ago. The topic went largely off original topic so I quit following it, then your message seemed to pop up a few days later.

Though the result of that topic was that they decided to go with xulrunner, sadly enough. (can explain why if need be, though largely off topic).

Though I have a hobby project that I'd love to do in 'dwt'. statistical analysis on baseball data.
see http://blog.palantirtech.com/2007/09/11/palantir-screenshots/ for a program that carries a lot of commonality that I'm looking towards.

> At the moment I think doing duplicated effort is not really the problem :)
> But to be sure, you can make a ticket in the related *sub*-projects and say in the text that you want to do this task. Perhaps you can inform or talk with me per mail or in IRC #dwt. Tasks that come to my mind:
> 
> dwt-win:
> dwt.widgets.DirectoryDialog
> dwt.program.Program

> dwt-linux:
> dwt.widgets.DateTime
> dwt.program.Program
> 
> dwt-samples:
> PaintExample
> LayoutExample
> (Custom)ControlExample Set/Get Api
> 
> If you have something to contribute, please see
> http://www.dsource.org/projects/dwt/wiki/Contribution

I've read it and everything seems reasonable. And I'll look into those controls and see what dent I can put into them. Just realized that tango current isn't exactly current. So I have to download it from svn and build, sigh.

Consider that a running list. If there's any isolated files that you'd rather not dig into, feel free to post.

> SWT 3.4 is no issue at the moment. First we want to have DWT 3.3 running with all widgets stable and with the installation problems solved and more examples.

Fair enough, when I was investigating a few months ago I found that a lot, if not all of the changes between 3.4 and 3.3 were *additions* to the api, rather than code conflicts. A lot of it was more in path to additions of platforms than anything else. Which here would be a seperate subproject all together.

Though I fully get the idea of make 3.3 work, then go to 3.4. I just don't think it'll be as much of a headache long term as it seems like it could be. And when you're basing it off of milestones, it won't be a true moving target. (Matter in fact, I would hazard to guess that moving to d2.0 would be a hell of a lot more work than moving from 3.3 to 3.4)

> 
> We do /not/ want to get the java'ism out. Instead we explicitely want to stay as near as possible at the java implementation. The reason is, that later merges are far easier done. Certainly in some cases this is not possible and in other cases we want additionally methods, that is OK.
> 
I'm /not/ talking about removing the event listener model, or anything of the like. In that regard, that's what I meant by keeping the API true to SWT. What I'm talking about is removing a lot of the java cruft that d by design doesn't have to accept. Since you're quite aware of the implementation, I'm sure you've seen several places where structs would make more sense than classes, using dynamic arrays over array caching techniques. Using scope would also be of benefit.

Now, I'm not advocating changing everything within dwt so that it smells like d. I get that there are wins when you keep the api the same. I also get that when you update compared to a new milestone in swt, you don't want to be in a situation where you're searching for where the changes would be. However, there are some patterns/approaches that could use some d lovin'.

A lot of this is wind before the storm. I'm fairly in tune with the implementation under the api, so I'm shooting from the hip so to speak. I'm just trying to get a general feel for what will and will not be accepted back into the main tree.

Because the work I'm interested in doing long term is size, memory usage, and performance wins.

> Unittests:
> Unittest are available in the SWT project. So this can be a good starting point.
> 
Right
> Nebula:
> Porting nebula could be done in the dwt-addons project. Is the license of nebula ok with doing this?
> 
yeah, I believe they're under the epl. since they are a incubator project.
> OSGi:
> OSGi is used for plugins in Java and relies on its own class loaders.
> Perhaps it can be omitted when using a fixed composition of components at compile time.
> 
Yeah, I believe there was a d based plugin framework at one time? Not sure. Though I'll admit this is probably a long ways off (at least on my time scale).


> Frank

At the end of the day, that list was meant to come across as things I'd like to work on short to long term. Not necessarily griping  about the state of things, or trying to swing direction. I just think that there could be some size wins off the top, and with d's gc the way it is, there's some considerable memory footprint wins that could be in the pipeline.

But I'll try to show those wins with code, rather than keep spilling about it here and go from there perhaps. Now back to getting it to build...

-Robby

instead of tango svn you can now use the new tango release 0.99.5.

Frank Benoit schrieb:
> instead of tango svn you can now use the new tango release 0.99.5.

dwt-linux:
dwt.widgets.DateTime
dwt.program.Program

is done

Robby wrote:

> 
> At the end of the day, that list was meant to come across as things I'd like to work on short to long term. Not necessarily griping  about the state of things, or trying to swing direction. I just think that there could be some size wins off the top, and with d's gc the way it is, there's some considerable memory footprint wins that could be in the pipeline.
> 
> But I'll try to show those wins with code, rather than keep spilling about it here and go from there perhaps. Now back to getting it to build...
> 
> -Robby


You have some good points. I think we can makes some wins with dwt size optimization especially and perhaps some better d translation where appropriate (incidentally, in some situations this is already done out of necessity).  I think this just requires more discussion; so as you start playing with the port, please feel free to offer some detailed suggestions.  I think dwt can improve in a number of ways.

Naturally, the emphasis has been on keeping the port as similar to the SWT as possible because this greatly reduces the porting work load. But, at some point, we may decide what other systematic D language mechanisms may prove useful to DWT.

One example of a simple improvement would be translating all instances of "public static const int" to an D enum type for library size optimization (although the size reduction may not be all that significant).  The java const ports straight across to D but is entirely suboptimal for DWT because it unnecessarily bloats the D object file with symbols. A better translation would be to use a manifest constant in the form of an "enum". Furthermore this will eventually ease the port to D 2.0 at some point.

There are still other improvements that I'd like to see. As you mentioned, I do believe adoption of D dynamic arrays may be useful in several situations.  Although in others, the dwthelper utilities implement java equivalent array copies which is arguably better than using dynamic arrays because many of the instances represent overlapping copies (which D arrays don't do).

Concerning struct uses, I'm not aware of too many situations where this may be useful.  We've already converted some of the simpler POD to structs because they were merely copies of internal platform ones.  But there may be some lingering situations still available.  One I can immediately think of is GLData... there may be several others that I haven't thought of.

Suggestions are welcome.

-JJR