Friday, May 8, 2009

Strategy, and what I'm finding out

Warning: Extremely Boring, Project-Specific Post

So, my strategy for my GSoC project is going to simultaneously encompass two approaches: top-down and bottom-up. The top-down approach would have me re-use the pre-existing code as a starting point as much as possible. The bottom-up approach would have me start from scratch. I think the success of my project depends on me embracing both: I should try to understand the code as much as possible in order to maximally reuse it. At the same time, said code appears to be in a rather broken state, so I need to forge ahead and dolve problems in my own way. It would be really nice if the code was not in a broken state, though, as I can see where my contribution would slot right in. Oh well...

Here's what I've determined so far. The goal of this phase of the project is to use GWT to implement the SWT API, so that GWT may then be used to compile any Java code that targets SWT down to JavaScript. It appears that the work that has been done so far has been to implement this API for most of the SWT controls. A notable exception to this is the GraphicsContext (GC) API. This is where my contribution would slot in, if any of the previous work was functioning correctly.

The best place to zoom in on this is org.eclipse.swt.e4.examples/dojo/controlexample/controlexample.gwt.xml. This top-level GWT module illustrates what other projects I would likely need to depend on, and where the GWT modules have been inserted into that project structure.

<!-- //////// FIXED PATHS //////// -->
<!-- Inherit the SWT-Dojo libs and the SWT common libs -->
<inherits name="org.eclipse.swt.swtlibs"/>

<!-- Inherit the base Dojo libs -->
<inherits name="dojoLib"/>

<!-- Inherit the SWT javascript libs, css styles, etc. -->
<inherits name="resources"/>

<!-- Inherit + java.lang emulated libs. -->
<inherits name="JCL"/>
<inherits name="extended_JCL"/>
<inherits name="extended_js_JCL"/>

<!-- Inherit the core Web Toolkit stuff. -->
<inherits name=''/>
<!-- //////// FIXED PATHS //////// -->

<!-- Specify the app entry point class. -->
<entry-point class="org.eclipse.swt.examples.controlexample.Main"/>


So, basically, we're pulling in the SWT lib, dojo, some resources, classes for custom JRE emulation, and GWT core. Pretty straightforward so far. There's an ant build.xml file that accompanies this which sets up the appropriate classpath and runs the GWT compiler against the module. If I was using the GWT plugin for Eclipse, I imagine that I could do away with the ant script and simply press the GWT compile button to begin compilation.

So, that part is fine.

It gets more complicated, though, when you drill down into the above modules. I spent the first week-and-ahalf of this project trying to make sense of the *JCL modules, before finally deciding that they were, in actual fact, in a disfunctional state. See, for example, the swtlibs.gwt.xml module:

<source path=""/>
<source path="events"/>
<source path="graphics"/>
<source path="layout"/>
<source path="widgets"/>
<source path="dnd"/>
<source path="printing"/>
<source path="animation"/>
<source path="accessibility"/>
<source path="custom"/>
<source path="graphics2"/>
<source path="internal"/>
<source path="net"/>

These might appear to be relative paths, but they are not, because the directory structure in which they find themselves is as follows:


By process of elimination, it appears that they are referencing libs in the org.eclipse.swt project.

jacob@jacob-laptop:~/workspace/eclipse$ find -name layout
./org.eclipse.swt/Eclipse SWT/common/org/eclipse/swt/layout

That's the only folder named "layout" in the entire workspace.

There's a bunch more strangeness here involving importing the project, which I'll cover in a later blog post.

No comments:

Post a Comment