The Visual Editor

The Visual Editor is moving to new software on a new server. I will leave this server up for a few weeks. Unfortunately, permalinks will break, but all the interesting old content has been migrated to the new server.

Why? Because I want a better platform than just a blog to talk about E4…

The new URL is:

http://www.coconut-palm-software.com/the_new_visual_editor/

The new RSS feed is here.

I can’t believe how long it’s been since I’ve posted! Wow. Guess time flies when you’re having fun, which I’ve been having a lot of lately. My new contract is to help make RCP the de facto standard graphical interface platform worldwide at a major Fortune 500 firm… But on to the good stuff…

Yesterday, Doug Schaefer wondered aloud how to unit test GUIs without some sort of robot. Short answer: with JUnit, like you’ve been doing all along, and a simple coding convention.

First, the coding convention:

• Always, always, always, create your user interface inside a Composite. Then you can instantiate your Composite inside a View, inside an Editor, or inside a Shell running inside a JUnit test.

Second, how to test it:

Create an abstract subclass of TestCase, say SWTTestCase.

Make your SWT graphical unit tests extend SWTTestCase. You will now have a shiny new Shell in your unit test at the beginning of each test method courtesy of the inherited #setUp() method.

If you followed convention #1, you can now instantiate your user interface inside this shell, poke data into it, fire events at it, and run asserts against it.

Here are some notes to get you started:

• Since you have direct access to the controls in your Composite through its API, your unit tests are fully refactorable, unlike most robot-oriented test scripts.
• There’s nothing wrong with calling #setText() directly on controls rather than simulating typing, unless the thing you’re testing depends on keystrokes being received one at a time. With this approach, you get the benefit of being able to intelligently use your controls’ API to set up your tests rather than having to alwys poke at them from the UI.
• Having said that, it’s nice to have #type(String), #type(char), and #type(int swtKeyCode) methods. You don’t need them often, but when you need them, you need them badly.
• Similarly, variations on #mouseClick(int button, …) are useful.

Examples of this sort of unit test can be found in the JFace Data Binding test plug-ins. We’re also using this style of GUI unit testing successfully at my client.

Areas where we’ve had trouble is in getting the various #type() methods right. Currently, some versions of #type() work but some don’t, and this is a road less traveled in the SWT API, so help on Google and in the Eclipse newsgroup archives has not been easy to find. I would love to hear from someone who has successfully implemented all three versions of #type() listed above.

Lastly, I am not sure how to make this solution scale up to the level of integration tests. This is an interesting open question I’d love to hear from people about.

I’m excited for a lot of cool new features in DTP, WTP, and BIRT!

(And don’t forget about Eclipse Data Binding.)

A few minutes ago, Boris Bokowski marked bug 154132 — “JFace Data Binding” recently renamed “Eclipse Data Binding” as FIXED/VERIFIED. This marks the last step in shipping our initial version of Eclipse Data Binding.

I’d like to publicly thank everyone who made this possible: Gili Mendel and the Visual Editor team for helping get this started, Boris Bokowski and Brad Reynolds, the other two committers on the project, and the many other contributors who have helped out on the newsgroups, and have sent feedback, bug reports, and patches.

Eclipse’s community is truly what makes Eclipse great!

Linux just works. And when it breaks I can fix it.

I just got a new Windows machine on Monday. It is already beginning to die the inevitable death of a thousand cuts.

I installed Fedora Core 6 on my Sony laptop two weeks ago. I’ve had two hiccups along the way, but they were both simple to fix, after a brief Google session.

1. The only thing that didn’t work out of the box was the wireless. Googling on the error message immediately gave me simple instructions for fixing it. (I just had to install a driver package for my Intel chipset; no compiling necessary.)
2. This week I used GParted (the open-source equivalent to Partition Magic) to resize my partitions. In the process, I physically changed the location of the swap partition on the hard drive, which broke the hibernate feature (which uses the swap partition as its hibernate data area). Again, a few minutes Googling the hibernate feature’s error message revealed what was broken and one command typed as root fixed it.

On the other hand, I bought a new HP desktop box with Windows XP preinstalled just 5 days ago. Windows already is starting to break.

1. When I click Start>>Shutdown and choose either “Turn off the computer” or “Restart”, Windows does nothing. It only works the second time I make the menu choice. This behavior is consistent. I’ve googled various combinations of “Windows won’t shut down”, and can’t find this exact problem anywhere to be able to fix it. In addition to the stock software, I’ve added Java, Eclipse, OpenOffice, Cygwin, and SQLYog. The only new device driver is the US Robotics driver for the USB wireless stick.

The score: Linux 2, Windows 0. Adjusting for amount of time owned: Linux 4, Windows 0.

My laptop’s hardware is exceptionally well-supported under Linux. Laptops with other chipsets won’t be this easy. In general, laptops built around Intel’s integrated display and wireless chipsets seem to work with the least amount of hassle. However, my experience is that the general principle here still holds. Once you get Linux running, it stays running, usually without your even thinking about it. If you’re running a more bleeding edge distribution like Fedora, you might occasionally have stuff to fix. But mostly it Just Works.

Windows invariably dies the death of a thousand cuts. No matter what you do.

For those interested in BIRT, Actuate will be hosting a follow-up webinar to the one they did last month. This one looks to be of a more commercial bent, but really could be useful if you are looking to adopt BIRT now or in the future. Here are the details:

Open Source Reporting Series

Seminar 2: Technical Demonstration

The benefits of deploying BIRT reports on the Actuate iPortal

Date: Thursday, 24th May 2007

Time: 3:00pm to 4:00pm (UK Time) – [10am EST and 7am PST]

Link: http://www.actuate.com/uk/info/online207birtwebsemforums.asp

This Web Seminar will walk you through how to Quickly Deploy BIRT Reports and Deliver Flexible End User Reporting.

Watch a detailed technical demonstration and discussion on the benefits of deploying BIRT reports on the Actuate iPortal. Further learn how certain reporting requirements can benefit from enhancing BIRT with iServer reporting technology from Actuate Corporation, the main sponsors of BIRT.

Several times, folks have blogged (primarily at EclipseZone) about the demise of funding for the Visual Editor Project team and the challenges that leaves us with:

• Lack of Eclipse 3.3 compatibility
• No support for new SWT and JFace features
• No support for Eclipse Data Binding

One thing I think would be productive to discuss out in the open is: “Candidly, what can we learn from the Visual Editor experience?” To get things started, here is my list. If folks want to reply/expand on this, please email me directly and I’ll paste followups into the bottom of this message.

• I’d like to see a much smaller, simpler, more easily hackable code base.
• The Visual Editor team never managed to fully document its APIs. This prevented a vibrant 3rd party addin market from forming.
• Without simple 3rd party addins, it’s really hard to get outside committers. The lack of committers outside the core team is one primary reason the project is where it is today.

Of course, this is no way meant to disparage the excellent work that the Visual Editor core team did. They wrote some awesome code. But I think it’s clear that we need a candid, open, healthy discussion of what we can do better in the future to try to prevent this sort of thing from happening again.

What do you have to add?

Awhile back I blogged that db4objects’ new EPL, ASF, etc… compatible license would help to spur adoption of this important new technology, and it appears that this was correct. Since this licensing change, db4objects has been adopted by several important open-source projects. A few were listed in the db4objects newsletter (quoting from the newsletter):

0f46f2f8802374b23ece2e2f72b01cb5

The team at RSSOwl tested many DB solutions before making their final verdict: “We have to thank db4o for allowing us to use it in our open source project. We have gone through months of trying different DB-solutions (including JDBC and JPA), but db4o looks like the solution we were always looking for in terms of easiness and performance!” says Benjamin Pasero, RSSOwl project lead.

While I expect that Hibernate and enterprise databases will remain the tools of choice in enterprise applications, packaged software and embedded applications with requirements for a tiny, lightweight, small-footprint database will likely find that tools like db4objects are a really nice fit for their requirements.

Full disclosure: While I worked as a db4objects employee awhile back, I have no continuing financial stake in their success.

For folks interested in learning more about BIRT, I received a kind email from Stuart Scott of Actuate with the following information on an upcoming BIRT webinar:

Jason Weathersby will be presenting a detailed technical demonstration and discussion on the benefits of Open Source BIRT next week, and in light of your post I thought this might be of interest to you and to your readers. This will be an online web seminar, below are a few details and a link where you can sign up should this be of interest.

Date: Wed, 28th March 2007

Time: 3:00pm to 4:00pm (UK Time) – [7am PST and 10am EST]

Link: http://www.actuate.com/uk/info/wsemq107emeabirtonline.asp

This Web Seminar will walk through the BIRT architecture, with a focus on the APIs and extensions that allow quick integration and customisation. Jason will provide a full technical demonstration focusing on how to build 100% pure Java reports based on the Eclipse platform. The aim is to provide a clear understanding of the benefits of using BIRT, including:

o BIRT Reusability – Using Templates and Libraries to maximise report reusability.

o BIRT Designer – Key features and functions available to the Report Designer.

o BIRT APIs – Integrating your report designs using the Report, Design & Chart Engine APIs.

o Deployment – Deploying BIRT to a J2EE or Eclipse RCP application.

BIRT is one of those projects I’ve been keeping my eye on ever since it was founded. Actuate definitely knows what they’re doing in the reporting business and it made sense that they should be able to create a great open-source reporting product. The question in my mind has always been if they can create a great community.

The word on the street at EclipseCon has been that the BIRT community has finally started coming into its own; recently I had a chance to use BIRT on my current project and find out for myself.

So far, the results have been very positive. In less than a day, I was able to create a modestly sophisticated report. The options for integrating BIRT into an application are numerous, and the most important thing: Birt is well documented and so far everything has worked exactly as documented, the first time, with zero fiddling around on my part.

As one used to literally fighting with other Java-based reporting solutions for days on end, this has come as a true breath of fresh air. Further, when I had questions, they were answered promptly and correctly by newsgroup staff.

You just can’t ask for more than that.

Kudos to the BIRT team!

Note to folks thinking about using BIRT: I bought both BIRT books at EclipseCon and they were more than worth the investment. The information you need is available on the web site and on the Wiki, but you’ll find it much faster and more easily if you buy the books.

Note to Greg at Addison-Wesley who’s been pestering me to write him a book: you’re always asking what books I’ve read that are great technical books. So far, both BIRT books are up there. Maybe they’re not superstar books like the Camel book on Perl or the “pickaxe” book on Ruby, but they are very well written, with lots of helpful illustrations at just the right places.