• Robby <robby.lansaw gmail.com> Mar 03 2008
• Frank Benoit <keinfarbton googlemail.com> Mar 03 2008
• Robby <robby.lansaw gmail.com> Mar 03 2008
• Frank Benoit <keinfarbton googlemail.com> Mar 03 2008
• Frank Benoit <keinfarbton googlemail.com> Mar 03 2008
• John Reimer <terminal.node gmail.com> Mar 03 2008

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.
 


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.
 


 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.
 


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