Friday, December 13, 2013

Split Editors: Anatomy of a new Feature

Finally, we're able to start moving the Eclipse IDE beyond what 3.x could do, showing some real pay-off for all the pain (for you and us). First up is the infamous Bug 8009, 11 years old and highly desired but never able to be implemented in the 3.x code base.

Lars has (again) beat me to the punch as far as the announcement goes so I'll take a different track; how did we go from the idea to the finished feature ?

Step 1: Design and Mockups

We started by making a variety of informal stabs at hacking the functionality, arriving in the end at the conclusion that in order to proceed we needed to allow a mechanism for an MPart to contain a sub-structure (sashes and other parts...). This part is all about testing the scope of the feature and learning what we really need.

This eventually lead to the extension of the model with a new element MCompositePart, giving us a formal definition of a part that can contain other parts.

Step 2: Functional Prototype

Once the MCompositePart made it into the model it was time to hack up a prototype of the feature, making sure that it performs all the operations necessary to expose the new functionality. My favorite technique for this type of work (especially when it's eventually aimed at the IDE rather than pure e4) is to just make a new project based off the 'Hello World, Command' template. Then I work on the command's handler code until I have a 'command' that can do what I want. In this case I ended up with the following (Kodos to the Orion team; my code snippets use an Embedded Orion Editor):

This gives me a command that will act as a toggle and change orientation each time you split (to ensure that we can do both) and accomplishes two objectives:

Allows me to fully implement the desired functionality, creating methods to be used in the implementation of the handler.

Test / refine the rendering capabilities to allow for the new requirements. In this case very few were needed as you can see by looking at the commits on Bug 378298. A lot of this code is only necessary because we have to support the new MCompositePart itself and it not directly related to the split editor feature.

BTW, not to worry about the implementations of the 'split'
and 'unsplit' methods used in the code above; we'll be getting back to
that code later :-).

Now we have a working implementation of the feature but it's not correctly packaged since all the code is in the handler class (and that handler uses the IDE's mechanisms but we will want this functionality in e4 as well)...what to do ? what to do ?

Step 3: Packaging the code for re-use

OK, the first thing to consider is what this feature would look like in pure e4. The pattern used by the MinMaxAddon is also applicable to this scenario so let's go with it:

Define a new SplitPartAddon that reacts to two new IPresentationEngine constants "SPLIT_HORIZONTAL" and "SPLIT_VERTICAL".

Move the methods required to do this out of the original handler into the new addon, calling them appropriately based on the new tags being added / removed from an existing MPart.

Here's SplitterAddon (note that the complete functional implementation is only 150 lines of code):

Now we can take our original IDE command handler and replace the code that used to call the methods directly with code that adds or removes the appropriate tags on the MPart for the active editor. Here's the final code for the IDE handler:

We also add a couple of key bindings for easy access...in this case Ctrl + '_' gives a horizontal split (one above the other) and Ctrl + '{' gives a side-by-side split.

Step 4: Release and Polish

Finally, we blog about it so that folks will know that it's available...;-).

Then we take the feedback and polish the feature (adding CSS to define the splitter's color...). The earlier we can release a new feature the more time we'll have to get the feedback and act on it before the actual release. If there's one thing as certain as death and taxes is that you won't get it right the first time. I've learned that it's more productive to 'get it working, get it out', then polish it rather than putting a ton of work into the polish up front just to trash it later based on feedback.

P.S. While the current implementation is specific to the Eclipse IDE and editors in particular we do expect to extend this feature to allow the proper splitting of any MPart. This will, however, require some more design work on allowing the MCompositePart to somehow 'host' the Toolbar and Menus from the currently active 'child' MPart so they appear in the stack and work correctly.

Alrighty then, on to the next one...different presentations based on how many monitors you have.

Followers

Blog Archive

About Me

I'm a tech fogie, having been around the industry since 1980, almost exclusively writing GUI code.
I'm currently an IBM employee and a committer on both the eclipse Platform and E4 projects, I'm currently the Eclipse 4 SDK development lead.
I've been a strong proponent of Model Driven UI's for a looong time.
I'm also glad to see that I'm not yet obsolete, what with new interface options coming on line (multi-touch, gesture, usable voice input...) there's still a lot to be done!! Sure, some of the simple boring UI's can be generated now but the really cool stuff is still crafted by hand (or mind).