www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.dwt - TODO?

reply Robby <robby.lansaw gmail.com> writes:
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
Mar 03 2008
parent reply Frank Benoit <keinfarbton googlemail.com> writes:
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
Mar 03 2008
parent reply Robby <robby.lansaw gmail.com> writes:
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
Mar 03 2008
next sibling parent reply Frank Benoit <keinfarbton googlemail.com> writes:
instead of tango svn you can now use the new tango release 0.99.5.
Mar 03 2008
parent Frank Benoit <keinfarbton googlemail.com> writes:
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
Mar 03 2008
prev sibling parent John Reimer <terminal.node gmail.com> writes:
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
Mar 03 2008