July 29th, 2009

How to Use Foxit PDF Reader 3.0 on Ubuntu 8.04 under Wine

I figured out how to set up and run Foxit PDF Reader on Ubuntu 8.04 a little while ago, and I’m just now writing it down. Foxit works extraordinarily well under Wine: displaying documents, editing PDF form fields, annotating documents, and printing to a USB printer all worked for me out of the box. There are certain tricky things involved in setting it up, though, hence this How To blog post.

First, download Foxit. The Foxit Windows installer didn’t work for me, but fortunately Foxit offers a .zip which contains the application frozen into a single Windows executable. Here’s a direct link at the time of this writing:

Unzip the executable and put it somewhere in your home directory where it won’t be touched, for example, ~/apps/.

You’re now going to make a small shell script to run Foxit under Wine. Copy the following text into a file on your PATH, and make the file executable. I put it in /usr/bin/foxit.


#got code to test whether path is absolute, here:


PATH_TO_FOXIT="/home/jacob/apps/Foxit Reader.exe"

case $1 in

/*) absolute=1 ;;

*) absolute=0 ;;


if [ "$absolute" = "1" ]; then

#we assume that root is mounted at Z: as is default on most wine distro

wine "$PATH_TO_FOXIT" "Z:/$1"


wine "$PATH_TO_FOXIT" "$1"


This shell script is smart enough that it will actually take arguments that you pass to it on the command line, and pass it into the Foxit executable. This makes it possible open a PDF in Foxit from the command line, e.g.

jacob@jacob-laptop:~$ foxit Documents/Research/papers_to_read/MDAUML.pdf &

You should now be able to open PDF’s in Nautilus by right-clicking the PDF and choosing Open With -> Open With Other Application -> Use a Custom Command -> {type in “/usr/bin/foxit” and click “Open”}. PDF files should now open automatically in Foxit when you open them from Nautilus.

Finally, you can configure Firefox to open PDF’s in Foxit whenever you download a new PDF. Just go to Edit -> Preferences -> Applications -> {type “pdf” into the search bar} -> {under the dropdown menu, select “Use other …”} -> {select file “/usr/bin/foxit” and click “Open”}. Note that this doesn’t fully change the default PDF reader for Firefox, as, for example, when you open a PDF from the Download dialog, it will still open in Evince, the GNOME default. I, unfortunately, haven’t found a way to change this behaviour, and I’d be very grateful for any comments anyone might have on this.

July 26th, 2009

SVG Development with GWT 2 – Well that worked

July 25th, 2009

SVG Development with GWT 1

In order for me to fulfill my project’s goal of implementing the retained-mode graphics API of Draw2d in terms of the retained-mode API of SVG, I need to be able to develop SVG using GWT. I remain confident that this is feasible, but it has been nontrivial to set up.

I was originally going to use a GWT library called Tatami, the role of which is to expose much of the functionality of the Dojo JavaScript toolkit to Java, including the excellent, cross-browser dojox.gfx retained-mode graphics API. Unfortunately, Tatami turned out to be unsuitable right out of the gate, as its graphics API does not allow the developer to assign event listeners to individual objects, only to the top-level canvas. I have no idea why they chose to impose this restriction, as setting event listeners on individual objects is an extremely common pattern in retained-mode graphics API’s (certainly in Draw2d), and, from a technical standpoint, dojox.gfx allows event listeners to be attached to individual canvas objects, so there shouldn’t have been any massive technical barriers to implementing it. In any case, this restriction made Tatami unsuitable for this project out of the box, and so I began investigating alternatives.

I’ve since been investigating the feasibility of scripting pure SVG using GWT. The first possibility I looked into was using GWT’s DOM API to manipulate SVG.

The initial consideration was what kind of document would I use to deliver the SVG content? There roughly three possibilities for displaying SVG on the web today, and they are:
1. Via a pure SVG document
2. XHTML document with inline SVG; or an XHTML document with SVG embedded via the object or iframe tags
3. HTML4 document with embedded SVG via the object or iframe tags

HTML5 documents will also allow SVG inlining (without even needing to use XML namespaces!), but I don’t think that there are any browsers that currently support this, so I didn’t consider this.

What I found was that options 1 and 2 were not feasible, as GWT threw JavaScript exceptions while being loaded in these documents, so that left only option 3.

Option 3 proved to be problematic as well. In principal, what should have occurred was to have the object tag reference an SVG document in its data attribute, and then set an onload event listener on the object tag. Once the object tag has finished loading, then it would be possible to script its DOM via the object tag’s contentDocument property. Setting a load listener on a document before scripting its DOM is a very common pattern in web front-end programming, and so I assumed that this would be straightforward to implement with GWT.

Not so. GWT, unfortunately, doesn’t support setting event listeners on DOM nodes! I couldn’t believe this, because it is such a basic, fundamental feature of HTML DOM, but it’s true. I think the motivation for this is that GWT would prefer that you use its built-in widgets rather than low-level DOM. In any case, the effect of this is that it is not possible to listen for an onload event on a document simply using GWT’s implemnetation of DOM, so I couldn’t script the SVG DOM inside the object tag out of the box with GWT.

I found other problems with GWT’s DOM implementation as well. To begin, it does not implement the standard Java interfaces published by the W3C (distributed by the Apache XML Commons). This is problematic because SVG has its own DOM, and while it is not necessary to use it (you can script everything in terms of the standard XML DOM), it would be beneficial to use the SVG DOM in development. Because of the way GWT’s DOM has been implemented, it cannot be easily extended to make use of the standard W3C interfaces for SVG.

With these two shortcomings in mind, it seemed that the solution was to actually create a full DOM implementation for GWT in a way that used the standard W3C interfaces. The gwt-dom project started to do this back in 2007, but stopped development after GWT 1.5 included a DOM implementation. On the project page, they say that the project has been made “completely obsolete” by GWT 1.5, but I disagree, as there is still a need for a standards-compliant DOM implementation in GWT, at the very least in order to fulfill the needs of this project. Still, it makes sense to reuse as much of GWT’s DOM implementation as possible: it’s less work for me to implement and maintain.

To achieve this, my solution has been to use the Adapter Pattern as follows: create DOM implementation classes that extend the standard w3c.dom.* interfaces; these DOMImpl classes compose a type <T extends> object, and the DOMImpl classes delegate to this object whenever possible; where not possible, they use JSNI. In this manner, it is mostly possible to delegate to GWT DOM, while exposing a standards-compliant API to DOM that uses w3c interfaces, and I don’t have to hack on the GWT core. The gwt-dom project actually has provided a good foundation for this work, as it uses a similar pattern to achieve. One improvement that I have made to gwt-dom is to use Java 5 type annotations so that, rather than simply having each DOM implementation class compose a JavaScriptObject, the wrapped object is a and thus may be specified as far as is practical (for example to a, and thus we can have fairly deep integration with GWT. But, overall, I have been able to reuse most of the code in gwt-dom.

There have been some problems so far with this approach so far, but I think this is mostly me tripping over the me tripping over Java’s type system. I often need to convert between arbitrary objects that implement DOM interfaces, and GWT DOM objects, and this can be a bit tricky. I have a solution, but it’s an ugly one, and I’m hoping to find a better way. I’ll post more about this later.

So, my status is as follows: I have HTML DOM scripting working, and I’m now hooking up events. After that, it should be possible to test scripting of SVG content, and I will hopefully be able to start programming against it with respect to Draw2d very soon.

I’m not to sure where this work is going to live when I’m done… upstream in the now-defunct gwt-dom project? I may try to contact the author and see what he thinks.

July 8th, 2009

Initial Exploration of Draw2d on GWT/SVG

It’s been some time since I updated this blog. The short story is, I made some progress with Java2Script, and produced a small prototype of SWT GC on HTML Canvas, which you can see here.

Unfortunately, when trying to compile the next level of the stack, Draw2d, I ran into low-level compiler bugs. I’m continuing to work with the Java2Script developers on these issues, but I don’t really feel like I’m in a position to fix or work around bugs in the Java2Script compiler, so my mentor and I have been discussing alternative strategies.

One such alternative is to start a level higher up the SWT/Draw2d/GEF stack, at the Draw2d layer, and attempt to implement the Draw2d API in terms of SVG or dojox.gfx, and use GWT to compile it. This is very interesting to me for a number of different reasons, so I’ve been drilling down into it. Here is what I have initially determined about the feasibility of this project:

The main problem with this strategy is that the architecture of Draw2d encourages the use of an immediate-mode graphics API, exposed by the org.eclipse.draw2d.Graphics class, which is just a thin wrapper over GC’s immediate-mode API.

The way Draw2d encourages the use of this API is by way of subclassing the Figure class. Figure subclasses implement, among other things, the paint or paintFigure methods, which get passed a Graphics instance, and use that instance for drawing. I think the whole process is that LightweightSystem sets up UpdateManager, which knows when to call the Figure’s paint method.

This is a problem, because if Draw2d is to be implemented in terms of SVG (or some other browser-based, retained-mode graphics API, e.g. VML), it can’t be implemented in terms of an immediate-mode API.

In my opinion, this is a limitation in Draw2d’s architecture with regard to our intentions, and I should note that it could have been easily avoided by making Figure protected. This would have forced everything outside of Draw2d to only use the API exposed by Draw2d. Now, however, there’s external code that depends on being able to subclass Figure.

Less code than you might think, though. Here are all of the classes in GEF and GEF examples that extend Figure:

org.eclipse.gef.editpolicies - src - org.eclipse.gef



org.eclipse.gef.examples.flow.figures - src - org.eclipse.gef.examples.flow

SubgraphFigure - src - org.eclipse.gef.examples.flow


org.eclipse.gef.examples.logicdesigner.figures - src - org.eclipse.gef.examples.logic



org.eclipse.gef.handles - src - org.eclipse.gef


org.eclipse.gef.internal.ui.palette.editparts - src - org.eclipse.gef








org.eclipse.gef.internal.ui.rulers - src - org.eclipse.gef




RulerFigure - src - org.eclipse.gef



So, not that many, and nothing from any of the GEF examples. So implementing Draw2D in terms of SVG may not be a perfect fit, but it might still be OK. Basically, the solution would be to limit usage of the Draw2d API only to those Figures that are declared in Draw2d (e.g. org.eclipse.draw2d.Triangle), and to those that are declared in GEF. Here’s how we would then proceed:

Each class that implements Figure would keep a private member which is basically an SVG handle, which maps it into SVG. Or, if we don’t want a direct dependency on SVG, we can make it even more abstract and just create an INativeGraphicsAdapter interface, then implement classes that basically just a wrap around a handle to the native JS object, exposed via JSNI. Unfortunately, dependency injection is not an option here because Draw2d’s figure API doesn’t support it and we can’t change it. Messing with the class hierarchy (specializing for a particular implementation of this interface), is also not an option. So it seems as though we’ll have a strong dependency on some implementation class. I can’t see a way around this right now, unfortunately… But maybe the solution is in GWT’s deferred binding technique. I’ll research this more and see. For the moment, I’ll continue to think in terms of having a direct reference to a wrapped native SVG DOM node handle, because it’s easier to think about.

The way it would then work is, for each Figure concrete subclass, either in the constructor, or in some init() method, an SVG DOM node gets created, but does not get added to the Document. The IFigure.add() method would add the node in DOM. IFigure.dispose would remove it. All operations in the IFigure API would then get mapped onto whatever native operations on the SVG DOM node are required.

Also note that even though SVG does not natively include a concept of asynchronous updates (where you make a number of updates to a Figure, and it gets applied later on, asynchronously), it would still be possible to make use of this pattern by taking advantage of the fact that we have an extra API wrapping the native SVG. The way this would work is we implement the Command pattern, such that for most operations on IFigure, we create a command and save it in a private queue on each Figure object, and then wait until UpdateManager calls paint to flush all of the operations in the queue.

And that’s it.

We will also have some SWT requirements to satisfy, but I expect these to be very minimal, and now that I have a deeper understanding of SWT, I feel I should be able to spec these out fairy quickly and easily.

May 31st, 2009

Initial Exploration of Java2Script

For reasons I will better explain later I have been investigating alternatives to GWT. In particular, I spent the last week working with Java2Script. Here are my initial impressions of this project:

First, what it is: Java2Script fulfills a greatly similar role to GWT, in that it acts as a Java-to-JavaScript language compiler. It provides a similar emulation layer for the core JRE class library. Additionally, where GWT provides its own custom widget toolkit API, Java2Script provides an emulation layer for SWT. Java2Script is, in fact, older than GWT. It seems to be less focused on optimizing for performance, and as such allows for such things as dynamic class-loading, a by-design limitation of GWT.

Java2Script only has a few developers, and I think only one main one (Zhou), but so far, I have been very impressed at how supportive and responsive they have been. My first task was to attempt to compile the draw2d API, such that it was able to load without errors. In attempting to accomplish this task, I discovered several bugs in the j2s compiler. I reported them, and within a day or two, Zhou had published fixes. Zhou and the other developers have also been very supportive in terms of offering me guidance with respect to my particular project. And so, by Saturday evening, I had accomplished the first task I set out: the draw2d Hello World example successfully compiled and loaded in the browser. It didn’t do anything, but that is to be expected as GC is currently only implemented as stub code.

The next step is to get simple examples of GC working. I don’t have a clear idea of how I will accomplish this, yet, as most patterns of using GC rely on setting a Paint event listener on a SWT widget, and using the GC returned on the event. The browser, unfortunately, doesn’t expose a native Paint event (only Firefox 3 nightlies, at the moment, as far as I know) so I’ll have to find another way to accomplish this. In any case, I have a thread going on this, some sample code to work from, and a good dialogue in progress with one of the developers, so I’m optimistic that I will get a reduced example of GC working by the end of this coming week.

May 20th, 2009

Primitive Tooling

I don’t know that I’m such a big fan of IDE’s. They seem to run counter to the Unix Philosophy, which is to have a large number of small tools that do one specific thing, and do it very well. These small tools are all bound together through dead simple, absolutely standard and rock-solid message-passing interfaces (stdin, stdout, stderr; all parameters are Strings). A big IDE that attempts to do everything and the kitchen sink often just feels like the wrong level at which to be working. Certainly, for my current project, being strongly bound to Eclipse for development has so far been counterproductive. This is because the GWT-Eclipse tooling is not yet matured… which is to say that the GWT module concept is really very different from the basic Java package concept, and this is a gap that the current tooling does not yet bridge. The result, for me at least, has been a great deal of confusion. Then again, I’m attempting to use GWT for things for which it was never intended to be used ;)

In any case, it has felt very good to ditch the IDE for a while and return to my humble yet powerful development tools: GNU Screen, Vim, Bash and Ant. I won’t describe here what these tools are or how to use them; this is covered very well in other places. But I will post a nice screenshot of my current desktop, which I feel is very close to complete User Interface zen:

One component currently missing from my toolbox is a good, preferably console-based file managers. I don’t really have very strong preferences with regard to file managers, but I really should, because there are many times when I could really use some powerful features. I just haven’t quite figured out what those are yet. Vi keybindings are a major plus, though. That rules out the famous midnight commander, unfortunately, as its keybindings are not configurable. Really, it only leaves two options: vifm, and a Vim plugin called VimExplorer. vifm was quite nice, a nice solid little file manager with vi-like keybindings. Unfortunately, it had some trouble installing on Ubuntu Hardy, and it was just different enough to what I was used to with a proper Vim instance to be annoying. That left me VimExplorer. I was a bit wary of this, because it hadn’t been updated since 2007, and the last update was to fix a critical bug that could cause data loss. But I installed it, tried it out, and found it to be quite good. It gives you a small file manager instance that lives right inside of vim. All of your vim skills then can be applied to managing files, including: regular expression search, macros, manipulating vim windows and buffers, and using “!” to trigger shell scripts. There’s something really great about being about to just say “yy” and then “p” to copy and paste a file. Same for move and delete.

Unfortunately, I still feel like this tool is lacking. 90% of what I do when developing is in done in just a few files and directories. What I want is to be able to just type the name of a file on my filesystem (e.g. “Accessibility.gwt.xml”), and immediately have an editor up for that file. The system should behave intelligently when there are naming collisions. I believe that GNOME-Do might actually be able to do this, and I should look into that. For the most part though, I think most of this could be accomplished by just tagging certain files or directories as favorites, and maintaining a simple hash to map short variable names to long paths. In any case, I’m continuing to iterate on this component of my set of simple tools.

May 20th, 2009

Convergence 1

Warning: Extremely Boring, Project-Specific Post

I worked really hard today, and I have lots to report. I started at 6:30am and worked straight through on GSoC until about 7:30pm. I also spent some time investigating alternate tooling, and I’ll talk a bit about this in another post.

So, to recap, we have this stack: Demos/GEF/Draw2d/SWT/JRE. The goal of this week is to get Draw2d to compile under GWT. After that, I’ll have to try to get it to run, but for now, I’m just concerned with getting it to compile. This, of course, means figuring out what Draw2d’s dependencies are in SWT and the JRE, and where they are not satisfied, writing out stub code and small TODO comments. Also, I will atempt, where possible, to reuse the existing, non-functional code from the previous project that used GWT to compile SWT to js.

To summarize my experiences of today: JRE == SUCCESS, SWT == FAIL.

First some background: GWT already provides some JRE emulation, but it is not sufficient to compile the SWT codebase. To get SWT to compile, one must at least implement certain stub interfaces that GWT does not provide. There are additional issues, such as reflection, that may be more serious, and I’ll talk about those in a later post. The extension to the GWT emulation classes live in the project org.eclipse.swt.e4.jcl. Left over from the previous project were three GWT modules which I was never able to compile. Additionally, it was unclear to me how these modules were supposed to compile, as they used the GWT module “source” tag, rather than the “super-source” tag, which, according to all of the documentation I have read, is what one is supposed to use when implementing JRE classes.

Today, I successfully compiled the previous project’s JCL classes. In order to accomplish this, I applied Technique 1 from my previous post, which is to say, I added a prefix (“e4″) to the JCL packages, where before there was no prefix, and I used <super-source path=”e4″/> in my GWT modules. I had to futz a bit to discover in which order I should import the modules, but after that, they compiled without complaint, w00t

//TODO: insert complete project structure here

Note that, since yesterday, I have been developing this prototype outside of the Eclipse environment. My toolset has consisted of GNU Screen, Vim, a Vim plugin called VimExplorer, and Ant. This has allowed me to ignore all of the IDE-specific confusion that I have so far encountered. My next post will be about my experiences using some of these tools.

I was feeling very optimistic after succeded in getting JCL to compile, so I set it as my goal to get the necessary SWT libraries to compile as well. Unfortunately, I failed in this task, because, I believe, I took the wrong approach. The approach I took was to attempt to reuse directly the SWT emulation classes left over from the previous project, just as I reused the previous project’s JCL classes. Unfortunately, these SWT emulation classes had many missing dependencies. My strategy was to just keep hacking on it (adding in missing classes, stub methods, etc.), until the thing worked. I spent most of the afternoon working on this, probably about 4 hours. Ultimately, I ended up pulling in most of the code in “org.eclipse.swt/Eclipse SWT/common”. I didn’t get to the end of the dependency chain, but I think I got far enough along to recognize a trend that I wasn’t happy with, namely, pulling in dependencies that in turn rely on other dependencies, etc. It should be a major priority to limit dependencies, because the more deps I cut out, the less complex my project will be. Given that this project is still at the prototyping stage, reducing complexity is of critical importance.

Note that I also tried compiling “org.eclipse.swt/Eclipse SWT/common”, but this pulled in some native code which GWT was unhappy with. So, I really do need to be selective.

The alternative to today’s approach is to start at the top of the stack (work top-down) and discover what the dependencies are for the Draw2d demos; then, find out what the dependencies are for Draw2d; then, very carefully, attempt to pull in those deps from org.eclipse.swt, or stub them out. I intend to use Doxygen to figure out the complete dependency chain. This will be tomorrow’s work.

May 19th, 2009

Summary of Some of the Pecularities Involving GWT Eclipse Tooling and Super-Source

I’ve been having some difficulties figuring out how to use the super-source tag for GWT’s module files. See the following forum posts for more background on this:

In short, there is a kind of impedance mismatch between the functionality that GWT provides the functionality that GWT’s Eclipse tooling provides, at least with respect to super-source. Here’s my understanding of how all of this breaks down:

1. You can use a package structure in which the native packages you would like to emulate (e.g. java.*) are prefixed by some other package (e.g. So you might have a project structure that looks like this:





Your GWT module super-source tag would then use path=”hack”.
The package declaration in your emulated Java classes would then say “” (no hack prefix!).

The Pros: This works great in both GWT hosted mode and compiled mode.
The Cons: The Eclipse IDE will think that something is wrong with your package declaration (it thinks it should be, and will give you errors.

2. You can use a package structure which does not use prefixed packages. So, you have something like:





Your GWT module super-source tag would then use path=””.
The package declaration in your emulated Java classes would then say “”, as per normal.

You then have two further possibilities:

2.a. Put super/ on the Eclipse build path.

The Pros: GWT Compilation mode works, and the Eclipse IDE doesn’t throw errors regarding packaging.
The Cons: GWT Hosted mode fails, ostensibly because it’s using the incorrect Java classes. In fact, I’m not really sure why GWT Hosted mode fails with this setup, but it surely does.

2.b. Do not put super/ on the Eclipse build path.

The Pros: GWT Hosted mode works (although you must set the runtime classpath to point to whatever dependencies TestSuper has; you set this as an Eclipse run configuration), and the Eclipse IDE doesn’t throw errors.
The Cons: GWT Compiled mode fails for the Eclipse GWT tooling, if you have projects that import this project, because the super/ folder is not on the Eclipse build path. If you were using Ant, this would not be a problem, because you can simply set the build-time classpath, but it does not seem to be possible to do this yet with the Eclipse tooling. Also, because super/ is not on the build path, you don’t get all of the advantages of the Java tooling that you would normally get from Eclipse.
Workaround: Use ant within Eclipse to Compile, and use regular GWT for Hosted mode.

It’s important to point out that all of these issues are related to the GWT Eclipse tooling, not GWT itself. Nevertheless, for my project, I am strongly dependent on Eclipse, so it is necessary for me to find the best way to resolve these issues. I’m not 100% certain about this, but at the moment, I feel like my best option is to go with option 2.b., so to stay in Eclipse, but move all of the build logic to Ant.

May 9th, 2009

Top-Down 2

Warning: Extremely Boring, Project-Specific Post

Onto the next puzzle: I’m trying to compile without importing any JCL code, in order to find out what JRE code needs to be emulated that is not covered by GWT. I’m getting this very peculiar output:

Buildfile: /home/jacob/workspace/gsoc-phase-1/org.eclipse.swt.e4.examples/dojo/build.xml



WARNING: '' is deprecated and will be removed in a future release.

Use '' instead.

(To disable this warning, pass as a JVM arg.)

Compiling module controlexample

Refreshing module from source

Validating newly compiled units

Removing units with errors

[ERROR] Errors in 'file:/home/jacob/workspace/gsoc-phase-1/org.eclipse.swt/Eclipse%20SWT/common/org/eclipse/swt/internal/image/'

[ERROR] Line 294: The method getProperty(String) is undefined for the type System


Why on earth is the GWT compiler trying to go inside of org.eclipse.swt/Eclipse SWT/common/org/eclipse/swt/internal?

May 9th, 2009

Top-Down 1

Warning: Extremely Boring, Project-Specific Post

Moving forward. In the post before my last post, I mentioned the swtlibs.gwt.xml file which was confusing me. Here it is again:


<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"/>

<script src="swt/loading.js"/>


The thing that was confusing me was the path entries. One would assume that they are relative paths… and I’ve now decided that, in fact, they are. First of all, the GWT documentation makes it pretty clear that this is the case:

<source path="path" /> : Each occurrence of the tag adds a package to the source path by combining the package in which the module XML is found with the specified path to a subpackage. Any Java source file appearing in this subpackage or any of its subpackages is assumed to be translatable. The <source> element supports pattern-based filtering to allow fine-grained control over which resources get copied into the output directory during a GWT compile.

But this was nonobvious in this case, because all of the paths referenced except for graphics and widget, are not accessible as relative paths. One could interpret them as being poorly-documented indicators of “future work”, but only if the it was certain that the GWT compiler wasn’t doing something clever like pulling in other, actual SWT folders on the classpath, that have the same name; for this to be true, the GWT compiler needed to be silently ignoring the missing referenced paths. To test this, I set up a sample GWT project with a source package that does exist. I also added a reference to a source package that did not exist:

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE module PUBLIC "-//Google Inc.//DTD Google Web Toolkit 1.6.4//EN" "">

<module rename-to='test'>

<!-- Inherit the core Web Toolkit stuff. -->

<inherits name=''/>

<!-- Inherit the default GWT style sheet. You can change -->

<!-- the theme of your GWT application by uncommenting -->

<!-- any one of the following lines. -->

<inherits name=''/>

<!-- <inherits name=''/> -->

<!-- <inherits name=''/> -->

<!-- Other module inherits -->

<!-- Specify the app entry point class. -->

<source path="exists"/>

<source path="doesnotexist"/>

<source path="client"/>

<entry-point class=''/>


End result: the Java classes in subpackage exists were found usable in both hosted mode and compiled mode. The compiler just ignored the reference to a package that did not exist.

So what does all of this finally mean for my project? It shows me the scope of the SWT emulation that they had at one point presumably been working. At the very least, it sets an upper bound on the work that was done in this regard: emulation of graphics and widgets package. That’s all. But they were aiming to emulate the entire SWT library.

With that in mind, I dug a bit deeper into the widgets package. As expected, there were a bunch of methods using JSNI. Not the nicest JavaScript code… But I won’t criticize it to much, as I understand that it never got past the prototype phase.

This work is licensed under GPL - 2009 | Powered by Wordpress using the theme aav1