TODO?

[Robby]

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