[andy]

Java uses UTF-16 everywhere, so SWT obviously does too. With D we get the choice: wchar[] is directly synonymous with Java's string class, but the common convention seems to be char[].

So... which should SWT use?

(maybe it would be worthwhile to make a string alias after all)
_________________
"Complacency is a far more dangerous attitude than outrage." - Naomi Littlebear

[brad]

Eesh. I am responsible for the char[] everywhere in DWT, but I tend to agree with you on the alias. We may have run into this without your heads-up when we tried to do multi-language support.

I wouldn't mind going through and changing out the char[] to String (or string?) and aliasing wchar[]. I've just sent a PM to JJR to see about getting his progress checked into SVN and then we can get it done.
_________________
I really like the vest!

[JJR]

Like I told Brad, I'm nervous about checking the my pieces into SVN right now because the directory structure is different than what's currently in there, and I've approached a few things differently in several files. Maybe we can talk about what should be done here.

I've got the basics of dwt.graphics and dwt.widgets layed out. Non-implemented dwt.graphics modules (with some contained classes inserted) are currently compilable without errors. So really all it needs is for people to start implementing it. I hesitate to send this to SVN too because I'm expecting a number of changes to the event system to take place yet. This will need to be done either during or before implementation of that directory proceeds. This has yet to be agreed upon. I imagine, for the most part, this should not stop us from starting implementation; Andy seems to be making headway on this, and I'd like to see what he's done.

UTF 16 seems to be commonly considered an odd-ball font set. Perhaps we should do either UTF32 or UTF8 (default). The current char[] use that Brad referred too isn't so bad. There is a String class included with the D port (who did this one again?), but I ran into difficulty using it because the toString methods in the SWT classes conflict with those contained in the D String class (Object and String toString conflict or somthing, I can't remember). We could consider an alias but let's also consider that we are making a D language toolkit. We may decide to just drop the String class and it's associated Java legacy.... we should agree on this early because the String class is a standard across the SWT source.

If people are interested in helping porting, here's a list of things that need to be done:

Desicions to be made:

1) String verses char[]
2) Delegate/event system (currently being brainstormed)
3) Error/Exception system (straight across translation of Java version?)
4) Threading (see Java Runnable and related classes)

Implementaton:

1) dwt.graphics modules (implementation started)

Andy's working on this?

2) dwt.widget modules (working on non-implementation classes)

3) *** dwt.internal.win32 ***

This should be straightforward work but very time consuming. It will be an important bases for getting the higher level widgets working. Remember to use the a windows import to access platform data-types.

4) *** Linux gtk+ version internals ? ***

Whoever's interested in looking into this as well.... likely to be tedious work as well, but straight forward.

5) dwt.events (yet to decide on how events are implemented). Listeners/Adaptors currently removed from this directory in preparation for simpler event type.

6) dwt.utils -- d specific imports used in porting of SWT

7) other less important libraries to ba added later: printer, browser, accessibility, etc

Feel free to comment...

I want to stress that it will be hard to get very far in this port unless clear decisions are made about certain items in this project that will make up the internal mechanisms of DWT. Specifically, it is imperative that a proper event model be agreed upon and implemented before we get into this too far (or else we'll be frustated to know end later....)

- John

[JJR]

If anybody does decide to start actual implementation of a module in one of dwt.graphics, dwt.widgets, or dwt.internal.win32, it would be useful if which module is being worked on is announced here.

There are a few choice BIG modules that could keep anybody busy. Some the most critical modules are

dwt.widgets.widget
dwt.widget.display
dwt.wdiget.shell
dwt.widgets.control
dwt.graphics.device

Most of these depend on a proper event system and an implemented dwt.internal.win32.*

Have at them, if you want

I also believe we should implement a "few" classes "well" instead of "many" classes "poorly." I think attention to detail is more important than massive progress in module conversions.

[JJR]

Now after looking at the past DWT project stuff, I realize Brad or somebody already made some significant headway in porting over the internal.win32 stuff (I forgot how much porting that guy had done on the last version). That's great.... I guess when I start to my new source directory updated, I'll bring in some of those files.

Once I get it moderately orgainzed, I'll probably go ahead and apply the changes to subversion so that everybody can get synced up.

I've also started adding the CPL copyrights, cut and pasted from the original Java files. It should go in every D module. I also made a little additional separate comment giving the projects name and website.

Later,

John

PS....

*** MY POSTS are getting off topic.... do we want to move the last 3? ***