This content is password protected. To view it please enter your password below:

Password:

If you’re Eclipse-curious and find yourself in the Toronto area this Wednesday, be sure to come to the Toronto Eclipse DemoCamp, graciously hosted by RedHat. We’ll have a bunch of talks, followed by frosty beverages at a nearby pub; I’m taking the late bus home this time.

I’ll walk through how Eclipse 4 makes tiling editors a breeze (this code will be open-sourced shortly), and show how the new workbench model can be combined with CSS to style the active editors (vs active parts).

Hope to see you there!

Editor Tab Order

One of the great things about Eclipse 4’s CSS support is that you can use it to tweak the Eclipse UI with very little effort. I previously spent hours to navigate internals to craft little hacks to tweak the environment to my liking; now I write CSS. Add these CSS snippets using the lightweight CSS editor (some installation required).

Like many, I hate the new behaviour of our editor tabs: rather than the sensible most-recently-used order, its behaviour is actually modelled on web browser tabs, which many people seem to like. The MRU behaviour can be brought back with the following CSS:

#org-eclipse-ui-editorss { swt-mru-visible: true; }

This uses a custom SWT property.
Note: the double “s” is not a typo.

Make the Quick Access go away

I’ve actually come to like the Quick Access bar, but many don’t. CSS can make it disappear:


#SearchField { visibility: hidden; }


So how does one find these options?

Eclipse 4’s SWT-CSS supports many of the standard CSS 2.1 properties, and also includes many custom properties too.

The easiest way to discover these elements and properties is to use the CSS Spy: simply hover over the element, invoke the Spy using its hotkey, and walk up the widget hierarchy, looking at the the CSS Id column, to identify the container.

(Note: the CSS Spy is normally invoked using Shift-Alt-F4, but Windows seems to ignore the Shift and helpfully closes the current window. You can remap the Spy to a different keystroke using Preferences → General → Keys.)

What tweaks have you tried?

I was chatting with a friend a while back about table computing, and came up with an interesting idea: progressively disclosing UIs for foldable and unfoldable displays.

We’re currently witnessing a Cambrian explosion in the world of computing gadgets. Gadgets now come in all number of sizes, from wrist-watch sized IPod nanos to wall-sized displays. These different sizes demonstrate a tradeoff between size and suitability for different tasks. Although I happily use my phone/PDA to remind me of appointments and keep my grocery list, I usually surf using a tablet or my laptop — despite its amazing desktop-like web rendering, not having to squint provides a more pleasurable experience. On the flip side, I don’t take the tablet to the supermarket as its size is a hindrance.

So I now have several gadgets of different sizes, and it can be vexing. Keeping them in sync is a pain, especially when your wife wants to know why your recent music purchase hasn’t been synced to her phone to listen on her commute. Oh sure I could keep everything in The Cloud, but I pay enough to my mobile operator as it is, and repeated security breaches at best-of-breed providers are hardly reassuring. And The Cloud only pushes the syncing problem from a per-device problem to a per-application problem — waddya mean your app can’t pull down from my webdav/dropbox/flavour-of-the-moment service?

But with the advent of rollable, scrunchable, foldable display technologies perhaps we can move to a new paradigm. Rather than have multiple devices of different sizes, I propose that we instead have a single device that can adapt to different sizes. For sake of a name, let’s call this a scrunchable UI: a UI that progressively adapts to changes in the visible display area. For example:

• Fold down a table-sized display into a wallet-sized display to use as you might use a PDA.
• Unfold a PDA-sized display to a 30 cm diagonal rectangle for a nice tablet-sized display.
• Fold a display to a broadsheet size for a newspaper-like experience.
• Boarding a crowded bus? Fold your display for a more compact viewing size, and unfold it again if you get a seat.

UI design for such a world would be quite different — responsive design taken to another level. Rather than design our UIs for particular modalities (available inputs), we’d need to come up with ways to adapt to the modalities that make sense at the moment. For a sense of the problem, try interacting with a large desktop display via VNC on a tablet or PDA — while walking! Fold the display to a small size and the display could be put into a single-application screen mode and the current app would change to being in “mobile” mode with fewer but larger buttons. Unfold the display and the app should progressively show more detail. When a lappable size, perhaps the UI switches to a virtual desktop, showing multiple windows. A fully unfolded display could produce a typical PC desktop-like experience. Where these transitions should occur, and how the software should adapt is sure to provide much merriment for years.

 

I’m presenting at tonight’s Juno DemoCamp in Toronto, where I’ll be discussing some of the impacts of Eclipse 4 for RCP and IDE developers. There are some very cool features in Eclipse 4 that all apps can benefit from, and I’ll talk about some strategies for how you can adopt Eclipse 4 in your applications/bundles.

If you’re in the Toronto area, come on by! We’ll be adjourning afterwards for some wonderful frosty beverages.

The DemoCamp being graciously hosted by RedHat; be sure to sign up so they have an indication of numbers.

June 5th 2012 6:30PM
Red Hat Toronto, 90 Eglinton Ave. East, Suite 502

I’ve posted the slides (~6MB) from my talk at EclipseCon 2012 on the CSS support found as part of the Eclipse 4 Application Platform. I’m just off to the airport for a nice vacation, but will post on some of the tips and tricks for using CSS on my return.

Find out more

One of the coolest features of the Eclipse 4 Application Platform is (IMHO) its new CSS support for styling widgets. I cannot bring myself to embed font choices, sizes, or backgrounds in code any more!

But creating CSS can be infuriating. CSS is very much like AOP, except that the selectors seem much more difficult to reason about than a pointcut. I could not see why my CSS selector either identified too many items or too few.

This was frustrating enough that I whipped up a little tool to help, called the CSS Spy, that has been contributed to the E4 Tools.

The CSS Spy window

Once installed, you can bring up the Spy on the active window with Shift-Alt-F4 (or ⇧⌥F4 on the Mac). The Spy shows the widget tree for the current window, with the initial selection is set to the control under the cursor. For each widget, the spy shows the CSS class and CSS ids for the different widgets. When a widget is selected, the Spy highlights where that widget is located on-screen with a red box, and also shows the current CSS properties for that element, the computed properties that were actually applied to the element, and other useful information for CSS use. The property table is editable, so you can also change the CSS property for an element and see the effect immediately.

Selecting a widget highlights its location on-screen

But I think the killer feature is the CSS selector search bar. You can enter any selector, and all matching widgets are highlighted. For example, you can identify the buttons with Button, or radio buttons with Button[style~='SWT.RADIO'].

CSS Spy identifying all radio buttons

E4’s model elements are partially exposed to CSS. When a model element is rendered, the containing widget (usually an SWT Composite), is annotated with the corresponding model element’s class names as a CSS class name. So you could select all MParts with .MPart.

CSS Spy identifying all E4 MPart model elements

We also expose the tag elements on a model element as a CSS class too. The E4 Workbench, which maintains binary compatibility with the Eclipse 3.x workbench APIs, adds tags to MParts to identify their type, such as Editor or View. For example, here I’m highlighting the view parts in the Eclipse IDE:

CSS Spy identifying all widgets that are a view part

I’ve only provided a taste here of what you can do with CSS. If you’d like to find out more, be sure to come to my session at EclipseCon 2012 (North American edition) where I’ll highlight how you can take advantage of the CSS support in your own Eclipse applications.

Getting & Installing the CSS Spy

To install the CSS Spy, you need to be running on the Juno stream (i.e., Eclipse Platform 4.2 M5 or later). If you’re not already, then install one of the development-stream packages. Then use Help → Install New Software and install the “E4 CSS Spy” from the update site at http://download.eclipse.org/e4/updates/0.12-I-builds.

Please report bugs to the Eclipse Bugzilla. Missing features? Fork the code and submit a patch!

[Updated 2012/06/27 as I had the wrong shortcut key combination. Sorry for the confusion!]

I’ve been trying to debug some Java code called from within a BIRT web service on MacOS X.  But the requests would hang as the BIRT report viewer would attempt to query the system’s printers with javax.print.PrintServiceLookup, which in turn loaded AWT and then hangs calling out to apple.awt.CToolkit#runningInHiDPI(), a native method on Apple’s native Toolkit implementation.

Unfortunately specifying the property java.awt.headless=true wasn’t quite sufficient: this setting still results in Apple’s CToolkit being loaded (in java.awt.Toolkit#getDefaultToolkit()), but it would then be wrapped in a HeadlessToolkit. So my process would still hang.

After poking around a bit further, I discovered that the JRE includes a different headless toolkit implementation called sun.awt.HToolkit. This headless toolkit can be configured using the awt.toolkit property as follows:

-Djava.awt.headless=true
-Dawt.toolkit=sun.awt.HToolkit

With these settings, my debugging is now hang free. I’m not sure why this toolkit implementation is not used on java.awt.headless=true.

I was recently in a situation where I had a client experiencing a problem in a Java app that I couldn’t recreate on my machine. The only solution was to do some remote debugging. Unfortunately both he and I were behind NAT firewalls, circumstances that neither one of us could change.

Fortunately SSH provides a solution through port forwarding, providing you have some publicly accessible host to serve as an intermediate. The process is made a bit more complicated as my intermediate host only allows incoming connections on particular ports. So I needed to set up a two sets of port-forwarding. As I always end up confusing myself with the meanings of SSH’s “-L” and “-R”, I thought I’d write up the recipe (mostly for my own benefit).

In the following I’ll use “C” to refer to the client’s remote machine, “L” to refer to my own machine, and “I” for the publicly-accessible host. Basically I needed to forward a port (C) from the remote machine to the intermediate (I_p), and then a port from the intermediate (I_p) to my local machine (L_p). The client’s app was configured to connect to C_p, and my debugger configured to wait for an incoming connection on port L_p. In my case I used L_p = C_p = 8000 and I_p = 6789 to avoid as much confusion as possible!

1. On L (my dev machine): start a debugging session listening on port C_p (8000). In Eclipse, this means setting the Connection Type to “Standard (Socket Listen)”.
2. On C (client’s machine): cause connections to the port C_p (8000) on the client’s machine to be forwarded to I_pon the intermediate:

   $ ssh -L 8000:localhost:6789 account@intermediate sleep 3000

3. On L (my dev machine): cause connections to port I_p (6789) on the intermediate to be forwarded to L_p(8000) on my local dev machine:

   $ ssh -R 6789:localhost:8000 account@intermediate sleep 3000

4. On C (client’s machine): start the app; if you want it to suspend immediately on start, change the “suspend=n” to “suspend=y”:

   $ java -Xdebug -Xnoagent \
     -Xrunjdwp:transport=dt_socket,address=8000,server=n,suspend=n \
     …appargs…

   or for Eclipse deployed apps:

   $ rcplauncher …appargs… \
     -vmargs -Xdebug -Xnoagent \
       -Xrunjdwp:transport=dt_socket,address=8000,server=n,suspend=n

Plink from the PuTTY distribution is a great SSH implementation for Windows machines.

Debugging Problems in JavaScript Code

I’ve recently been doing some client work with BIRT reports. Although BIRT is a surprisingly powerful reporting framework with support for embedding JavaScript, debugging a failing report is a bear. Unfortunately I have yet to find a nice compendium of debugging advice.

So without further ado, here are some tips and tricks I’ve stumbled across. I’ll amend this post with updates. Feel free to contribute your own in the comments!

[Updated 2011/07/21: add note about EngineException]

BIRT uses the Mozilla Rhino execution engine to process its JavaScript. To trap various JavaScript errors, place breakpoints on the following exceptions:

• org.mozilla.javascript.RhinoError
• org.mozilla.javascript.EcmaError: thrown on missing methods
• org.mozilla.javascript.EvaluatorException
• org.mozilla.javascript.JavaScriptException
• org.mozilla.javascript.RhinoException

I’ve found that it’s also useful to put a breakpoint on org.eclipse.birt.report.engine.api.EngineException as this seems to be thrown when there is a calculation error of some kind within the report. If you’re getting an error displayed like:

Errors occurred when generating the report document for the report element with 2906

then you’re likely encountering an NPE or division-by-zero error in your JavaScript code.

org.eclipse.birt.report.engine.api.ViewerException is thrown when there’s some deeper issue affecting report generation.

ViewerException: The viewing session is not available or has expired

The system that I’m developing uses a web interface to view BIRT reports. I found that during development that the report generation would fail, complaining that “The viewing session is not available or has expired”. It turns out that although I was accessing the web interface through “localhost”, internally the system would redirect to the machine’s alternative name “dev.mt.ca”. As my browser was configured to ignore cookies from other domains, the BIRT session cookies were tossed.

All was well when I accessed the web interface using the alternative machine name.

EngineException: Can not load the report query

I’ve usually seen this exception in a few circumstances:

• When binding a table to a dataset and specifying a column that no longer exists. “Refreshing” a table’s bindings only adds missing columns; there’s no warnings of bad references. (I wonder if there’s a way to trap references to non-existant columns?)
• Having changed a table grouping’s name, but forgetting to update any aggregations defined by that grouping name.