[jcesar]

Just stumbled upon #WT wich is a SWT port to the C# language. Win32 for the moment, it seems. I thought this would interest the project developers.

The website is: http://www.sharpwt.net/
_________________
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS$ d- s+:+ a-- C++> ULS++ P++ L+> !E W+++ N+ o? K? w++>
O---@ M V? PS+ PE Y+ PGP t+ 5- X+++@ R- tv+(++) b++> DI!
D++> G e+> h-- r- y+
------END GEEK CODE BLOCK------

[JJR]

Thanks, this could be quite useful. I appreciate this.

Later,

John

[JJR]

Sharp WT is interesting and may prove to be a useful reference. Unfortunately, the project uses plenty of C#isms (suprise, surprise), a language I'm not familiar with. Some are easily understandable, other things I think are plane ugly, others are cryptic.

I also noticed that Sharp WT takes a number of huge digressions from the SWT implementation of certain object/features (which is fine, just harder to follow after heavy study of Java SWT internals). Events and widgets are implemented quite differently. This may indicate that a careful disection and reimplementation of SWT in D (particularly events/dispatchers) to a more D savy methodology may be possible by a shrewd and experienced programmer.

That I cannot do on my own, I'm afraid. As it stands it would take very careful study and preparation to make more D-like changes. At my current level of knowledge, I can only progress properly if I follow mostly java style model. I'm afraid to do more lest I ruin the current model. This project is a big one for me, and I'm doing my best to get a grasp of the internals as it is .

As for the forward reference issues: most appear quite easily removeable with the internal class import method as suggested by Ant. As needed I've started adding required contained objects to the class definitons (partial implementation) to invite more forward referencing issues. So far not much to worry about. I think this method can progress effectively to the end (ie empty classes, partial implementation) with few issues. It should leave a adequate start for further implementation with no real worries of further forward references (because all required objects will have been added to the classes and test compiled already; what's left is just normal implementation programming).

The hard part naturally will be desired model changes (DWTerror, events, dispatchers, etc). I can implement in simple form, but it may be far from preferable to the power programmers. Ideas, help, and implementation by the more talented, then, is always welcome. Meanwhile, my slow progression with this project is accounted for by a need to study more details about SWT features/operation. Not much point in me changing things around if I don't understand how it works completely and thoroughly first.

Later,

John

[andy]

Regarding that...

dwt.internal.win32.forward is no longer needed at all as of DMD 0.54 or thereabouts. (I forget which exactly)

I've been hacking up dwt.graphics lately. I'll send you changes when it compiles. (or when I pull the last of my hair out in frustration, but it's leaning toward the former)
_________________
"Complacency is a far more dangerous attitude than outrage." - Naomi Littlebear

[JJR]

I haven't looked at win32.forward or know how it relates to this, but I know there are a lot of SWT files that can be eliminated for DWT.

If you can get dwt.graphics classes working, you will have made a huge contribution to the project. I've compiled that directory successfully with the empty classes (partial implementation actually; they include a number of contained classes as I mentioned earlier). I still have a few more classes to insert within some of the modules to complete the test. But it should be a good bases to move on with.

Let me know how it goes. Also let me know if I can help if you are having problems with forward references.

Thanks,

John

[andy]

win32.forward was used to resolve all the forward reference probsems within the package. win32.forward depended on nothing; other modules depended on it instead of each other.

Recently, the issue was alleviated within the compiler, but it only catches two-way interdependance. (where A needs B and B needs A) dwt.graphics is much more intricate, unfortunately.
_________________
"Complacency is a far more dangerous attitude than outrage." - Naomi Littlebear

[JJR]

Ah I see now, I never dealt with the win32.forward issues before. I do remember almost pulling my hair out with frustration while working out forward reference issues in both widgets and graphics packages. Indeed, those ones were much more intricate. Forward references were related to higher degree of separation, as you mention.

I never resolved them completely at the time, but I do think there is a way to fix them now. I noticed, though, that there is still no way to "single" compile these files without running into these issues; but no matter because dmd works great with multi file compiles. At present, I'm going to continue to build up the graphics modules. So far so good.

At least the update compiler has fixed some simpler issues; that would be significant enough.

[andy]

I think I have all the dwt.graphics stuff worked out, actually. With any luck, I'll get the rest of the compile errors worked out today. (all that's left is lots of char/wchar mismatches, uncommenting pieces of the OS class and so forth)

Also, for a good time, check http://andy.tadan.us/callback.d out. (generated with http://andy.tadan.us/make_callback.d.py)
_________________
"Complacency is a far more dangerous attitude than outrage." - Naomi Littlebear

[JJR]

[andy]

It's a port of swt.internal.callback. SWT implements it in C++, using a bit of macro wizardry to generate pretty much the same code. Since D has no preprocessor, and I wasn't exactly willing to type all that out, I wrote a python script to do the same.
_________________
"Complacency is a far more dangerous attitude than outrage." - Naomi Littlebear

[JJR]

Ahhh... I see now. I haven't paid much attention to that part of SWT, so I'm a little clueless about how this works.

I missed the callback.c and callback.h files altogether. I should have had them available for a reference in the project. It's good that you sorted that out with a simple automated solution.