At http://blog.cypal-solutions.com/2008/05/to-view-or-not-to-view.html, Prakash describes the following distinctions between views and editors:

• Editors contribute to the global action bars, and views to its local action bar.
• In the layout, editors have a special place called editorArea where all the editors will go. Views can go anywhere else, including fast views, detachable ones, etc.

He also points out that it's a common misconception that views don't support the save action. The save action will be enabled for a view if it implements ISaveablePart.

To me, this isn't the crux of the issue, however.

The only real difference between a view and an editor is that there is exactly 1 editor area and once visible, it is always visible even if no editors are open.

When would one care?

If your application has an open/edit/close life cycle (even if saving is implicit), the thing you edit probably should be an editor.

For example, in an order entry application, the order editor probably should be an Eclipse Editor, not a View. The thing that opens the order editor will likely be a View (or maybe another Editor, depending on the application).

If you try to make the thing you open, edit, and close into a view, then if the user closes all of the “editing views”, the space occupied by the view stack will disappear.

But if you make it an editor, then the editor area will remain even when all currently-opened editors are closed. This way it will be obvious to the user that s/he can still open a new thing to edit.

Use an editor for things you want the user to be able to open, edit, and close. And if it's reasonable, design your application around this user interface idiom since Eclipse supports it well.

Use a View as a device for browsing the things you can edit and/or for supplying additional information about the thing currently being edited.

In The Web 2.0 - or are we going the wrong way?, Tom accurately compares Web 2.0 with 3270 (and 5250) terminals of yesteryear and wonders aloud if Web 2.0 is really the right way to go technically with E4.

This is a good question. What is the right way to go, both politically and technically?

The way I look at it, the following forces are shaping the industry's solution to this problem:

• Low-touch deployment model. Web pages load fast into the browser. Hot-deploy changes to the server and clients automatically pick them up.
• Install the client once. Desktops are very expensive to install and maintain. The web browser is already on literally every desktop out there, courtesy of Microsoft and the Mozilla Foundation. Adobe Flash is nearly ubiquitous too.
• A rich experience is preferred. Google search will probably remain a Web 1.0 application. But for anything much more complicated than this, the world is moving toward a richer Internet experience.

Given these realities, let's list the technical means for deploying rich Internet applications and then draw some conclusions about good places to consider investing in E4.

• AJAX-based Web 2.0 applications.
• Flash-based applications.
• Java Web Start.
• Create a browser plugin like Flash, but that just includes OSGI, SWT, and probably a security model.
• Create a brand new universal network client based on Eclipse RCP.

Let's look at each of these in turn.

Tom already described the weaknesses of AJAX: It's basically a hack to turn asynchronous XML requests from a browser into a rich graphical terminal. AJAX applications tend to be sluggish, as they can require round-trip network requests to anywhere in the world and rely on interpreted JavaScript operating over a DOM.

Having said this, AJAX's biggest advantage is that it is already supported everywhere the web is. AJAX is basically the least common denominator platform for rich web applications.

Flash is well-understood and fairly ubiquitous, but it is proprietary. It is not as well supported on 64 bit platforms. However, it has a better programming model for really rich graphics.

For example, there is no standard analog of an SWT Graphics Context in AJAX JavaScript, so something like Flash is required in order to implement generic graphics drawing over the web.

Java Web Start has a reputation for being roundly hated by Java programmers. I have no personal experience with it so perhaps people can elaborate in the comments.

JWS has the disadvantage that its content is not integrated into the web browsing experience. It's basically a way to bootstrap a regular Java application over the web. (Again, if I'm wrong, someone please correct me in the comments.)

This could be really cool to do. OSGI and SWT running in the browser would be very nice. With less than a 4 meg starting footprint, this could be really practical too.

The main problem here is that nobody has written it yet. Also, whoever writes it would need to have someone on staff who is really good at security, if this thing is to be deployed on the Wild, Wild Web (WWW).

At JPMorgan, we've already done this. (See also.) The Riena project at Eclipse is also working on this. This makes tons of sense within the corporate firewall because:

1. You can control deployment of a new universal network client
2. There normally is a well-defined security model already in place.

To be a general solution, however, someone would have to figure out the security implications of running arbitrary OSGI bundles over the Wild, Wild Web. And then the challenge would be to make such a universal network client truly universal on the Internet– ie: deployed to every desktop.

Looking at the above forces and solutions, it seems to me that AJAX is an obvious platform for building out a new generation of rich Internet applications. It is everywhere.

However, I agree that we we will probably run into the limitations of AJAX fairly soon and want something better.

The only two possibly-viable solutions I can see above are Flash and a custom SWT Browser Plugin. I'd vastly prefer the latter, but fear that the former will win, simply because it's there.

Is there any interest in the community writing a SWT-based web browser plugin?

Back at EclipseCon, one of the big news items had to do with the proposed Eclipse 4, or E4 feature set. But I think that the true story behind E4 isn't just about running Eclipse in a browser, but in something much more interesting than that.

E4 isn't just a very cool AJAX framework–it's the ability to write rich client applications that deploy to a desktop or a browser from the same code base.

And this is interesting.

Which is why I'm attending the upcoming E4 Summit. And why I've switched to a bliki–a cross between a blog and a Wiki–to make it easier to both blog and write about E4.

I can't make RCP4 happen by myself. IBM can't make E4 happen by itself.

Come and join us! Jump in–the coding's fun and the water's warm!

Please add comments with your ideas, thoughts, and critiques, preferably over on the RCP page.

The Visual Editor is now officially a Bliki, with no apologies to Martin Fowler who also runs a Bliki.

For those who track content in an RSS reader, the new URL is

http://www.coconut-palm-software.com/the_new_visual_editor/feed.php?ns=blog&num=10&linkto=current

11 December, 2007

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.

public class SWTTestCase extends TestCase {
    protected Display display = Display.getDefault();
    protected Shell shell = null;
 
    protected void setUp() throws Exception {
        super.setUp();
        newShell();
        methodCalls = new HashSet();
    }
 
    protected void tearDown() throws Exception {
        super.tearDown();
        display.syncExec(new Runnable() {
            public void run() {
                disposeShell();
            }
        });
    }
 
    protected void newShell() {
        disposeShell();
        shell = new Shell(display, SWT.SHELL_TRIM);
        shell.setLayout(new FillLayout());
        shell.open();
    }
 
    private void disposeShell() {
        if (shell != null) {
            shell.dispose();
            shell = null;
        }
    }
}

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.

18 May, 2007

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.

• 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.

April 17, 2007

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?