[Ant]

JJR wrote:
swt-pisrc.zip


ah! there it is!

so now we can compare the 2 versions:
(*.java files only)
7 files specific to GTK
2 files spedific to Windows
70 files different on GTK --- Windows
206 files identical on GTK --- Windows

the different files are all on the packages:
accessibility (1)
awt (1)
browser (1)
dnd (11)
graphics (11)
internal (2)
printing (2)
programs (1)
widgets (40)

(adds up to about 70)

probably some will have a lot of changes, some just a few.
but for consistency all those 70 should be like Andy's dfbth
Code:

[brad]

This sounds okay, but I think that all of the widgets should be implemented the same (maybe we're saying the same thing). Aren't the main differences in internal? Those seem to be the calls to the native methods on each platform. os.d has most of them for Win32. I am surprised to see the 40 different files in Widgets, but I haven't looked through the linux files yet. I hope that's where there are few differences, and most of the differences are in internal and graphics. Am I making sense? I thought that SWT abstracts its way up from internal (native calls) all the way up through graphics, and then to very generalized widgets.

My point is that I agree with you on making them consistent with Andy's lib, but I am assuming (maybe incorrectly) that SWT already did that. Calling button in SWT should do the appropriate native call in internal/xxx/os - I could be wrong.

Ant, I wouldn't discourage you from going off in a direction for a little while. If it seems worthwhile, keep going and we'll take a look at what you've done.
_________________
I really like the vest!

[Ant]

[JJR]

Ok, it's finally dawned on me....

I think what he's saying is that there are plenty of differences outside of the internal directory contrary to what we thought. If that's the case, I'm kind of stumped as to why SWT is supposed to be so great... Let me think this through...

70 differences in the high level interface is not what I expected for a toolkit that's supposed to hide the OS differences in the name of portability. But then I suppose most of those differences are not visibile to most of the programs using the toolkit. So portability is not in this kit, but in the software designed to use the kits features. I can see why this kit was especailly useful for Java which has much lower risk of implementing platform specific code in the applications that use the kit (because of the VM). D programmers will be more prone to make non-portable dwt applications, I think.

In SWT, widgets may be implemented differently per platform (and the internal OS functionality basically allows the toolkit to organize those differences clearly and properly); but beyond that, each widget still has to be set up in this kit fairly specificly per operating system. It appears Ant was right afterall.

I guess it should have been obvious when we saw that the kit was supplied in two completely different zip files for gtk and win32.

The portability is in the apps using the kit, not the kit itself:

In apps using the kit, we can make common calls on win32 and linux to say:

widget1.setKeyState(data);

Both OS's share the same call... but this call is implemented slightly differently on linux and win32 (just an example) because they may take more or fewer OS calls to do the same thing internally.

So basically we haven't a huge advantage with porting SWT other than these reasons:

1) it's a popular and proven kit
2) the design is already laid out for us
3) it implements native widget interface for each OS
4) the cross-platform organization and details have already been worked out, for the most part in the source.

Though not impossible, it will be a challenge to integrate versioning information throughout the kit. Perhaps Ant is right about separating the two. Otherwise porting is porting. So I guess we have our work cut out for us. Ah heck, it'll be a good project anyway. It's funny, though, that none of this occurred to me until now.

Thanks, Ant, for bringing up the subject.

[JJR]

Now I realize the widget.setKeyState() method was not a very good example (since it's probably a very simple non-OS dependent call), but hopefully you get my point.

[Ant]

[JJR]

Ant,

Vascillating is my specialty

I very likely got carried away with my pessimism. You are right that we probably can integrate the two versions into a common source. I was just a little distraught to find out the differences weren't just localized to the "internal" packages as I originally thought.

As long as we have a game plan, things should go fine...

Later,

John

[Ant]

[Ant]

[brad]

Yep... just like internal is already set up. I think this will work. Ant, are you making any progress at all? I'm bummed because work is extremely busy. I was hoping to have time this week to work with you because you're on vacation, but it was not to be.
_________________
I really like the vest!

[brad]

On Friday I get a new laptop and I'll make it dual boot to XP and Gentoo linux. I can then switch back and forth to do DWT development.
_________________
I really like the vest!

[JJR]

Ant,

[JJR]

I'm hoping to be more involved in this project at the end of this month. My courses should be done by then.

[Ant]

[Ant]