• Home
• Features
• Forums
• Announcements
• Newsletter
• Podcasts
• About
• Write for us

Eclipse Project Series: The Visual Editor Project - August 2005

The Eclipse Project Series takes a look "under the hood" at leading edge Eclipse projects through technical interviews with the developers that created them.

The Visual Editor Project is a generalized GUI builder that can be used for Swing and SWT out of the box, but can also be used for creating GUI builders for other languages like C/C# or alternate widget sets. In this article, EclipseZone interviews two of the developers of the Visual Editor: David Orme and Dr. Gili Mendel.

[EclipseZone] How did you get started with programming?

[Dave] The first computer I ever played with was a minicomputer at AT&T Bell Labs while I was in grade school in the 1970s. My Dad was a computer programmer for them and he occasionally brought home a 300 baud thermal paper terminal so he could work at home. We played text adventures (such as there were in the 1970s) on that computer when my Dad wasn't programming.

So when my junior high school got an Apple ][ plus computer with a whopping 16 kilobytes of RAM, I was very interested in learning to use it, which back in those days meant learning to program, since the first thing you saw after booting one was a BASIC command prompt. So starting in junior high school, I mostly taught myself Applesoft BASIC. In high school, I added 6502 assembler, Pascal, C, and a little bit of Unix.

[Gili] My first computer was a 2 (256K) floppy, 256K memory 8088 machine. I had one master floppy with the OS, Turbo Pascal, and all of my goodies; life was good. I could go to any computer and keep on hacking ..... Today, I have one master 60G iPod to carry all my junk with me - but, to keep on hacking, I still have to carry my laptop with me anyway.

Is working on the VE project your full time job? If not, what else do you work on?

[Dave] VE is not my full-time job. Full-time, I am an independent consultant, currently working for:

1. db4objects, the simplest way to store and retrieve native Java objects I've ever seen. It is a real database, which means that it has full transactionality and real object querying. It's small (400kb JAR, 1 meg RAM), fast, and can run either in an embedded mode or in a true client-server mode. I wrote and maintain their Object Manager GUI, which is a standalone SWT/JFace application for maintaining databases.
2. Sarvega, a manufacturer of application-specific co-processing appliances for large enterprise or Internet applications. I'm responsible for creating a graphical editor for their RCP-based IDE.

[Gili] I work on the Visual Editor Eclipse project part time. My other responsibilities are to develop Eclipse extensions for the Visual Editor for IBM's Rational Application Developer product.

What are some of the strengths of the Visual Editor that might not be immediately apparent to the user?

[Dave] When people think about GUI builders, they think about the GUI builders from the 90s that really were focused around helping people lay out canned controls in an X/Y grid. VE is fundamentally different. We go to great lengths to let you write code graphically the way you would write it by hand, only faster and with more precision because you get instant feedback about if what you wrote does what you think it will do. There are three features in VE that really enable this kind of coding:

1. VE lets you create your own custom controls, then immediately use them without having to first install them on the palette. This is huge! It means that (unlike recent commentary in HackNot), you can easily create custom controls for things that you know will repeat in your GUI (like a name and address block, to use the example from HackNot), and then drop it as many times as you like, wherever you want.
2. VE actually compiles your code on the fly, then runs your code in a background virtual machine. This is how VE can display your live custom control immediately in another form. If you find a bug in your custom control, no problem. Just switch back to its source code, fix the bug, then go back to the VE form designer and try it again. You don't have to go through an explicit run cycle because VE does that for you, automatically, in the background as you code.
3. Our new GridLayout tooling (see figure 1) lets you design your layouts visually. It feels like designing in X/Y layout mode. But you get the full benefits of having a real GridLayout layout manager behind you. I experienced a great productivity boost when I started using this new feature. Watch Gili's great screencast for details.

Figure 1. VE1.1 provides thicker support for GridLayout.

[Gili] The Visual editor uses a target VM that runs on the project's .classpath. This enables VE to work with different levels of JREs, RCP/SWT independent to the level of the IDE. VE is not dependant on, nor does it generate any meta information. It reverse parses Java source code.

VE is extensible. It's override-able on many levels which gives one the flexibility to further extend/modify the editor's behavior (see the Eclipse Corner article on this). VE is not hard coded to work with specific Components or Widgets. It uses introspection, reflection, Screen Scraping, and uses an Object's hierarchy (with conjunction of core VE extensions) to determine an object handling.

What's your plan for future versions?

[Dave] Improved RCP support, better GridLayout support and FormLayout support. We think that we can make this work nearly exactly the way Matisse works, but without having to resort to a proprietary layout manager.

Currently, VE is not very widely used, even within the Eclipse community. Why do you think that is, and do you expect that to change?

[Dave] VE is the 4th most popular download at Eclipse.org, so I think that this is already changing. But you're right that in the past we weren't used that much. I think that it's mainly a maturity thing. VE has really grown up in the performance department with the 1.1 release, and it's a lot more stable. VE 1.0 basically wasn't usable on Linux. Now I use it nearly every day on Linux/GTK and it's fast enough for me.

[Gili] GUI builders typically rely on clean code generation patterns and do not deal, in many cases, with code that was created by hand (which may use a mix of simple and templates based functions/logic). Hence, GUI builders are widely used by novice users (top down) that rely on the editor to set and layout visual components. GUI builders lack wide adoption by expert users that typically already have an existing code base that is not readable by the Builder. Some of these users do not see a reason to spend time and refractor the code so that they can take advantage of a GUI builder.

As GUI builders get better at parsing hand coded patterns, and as builders become simpler, intuitive, and less intrusive, advanced user will opt to use them more often simply because it saves time to do so. After all, even an expert "hand coder" spends significant amount of time dealing with the details various layouts, constraints, and settings. It takes countless amount of time for a "hand coder" to change/run/test/debug cycles, when constructing a GUI. This is something that is alleviated by having a good WYSIWYG GUI builder.

Every time I try to use a GUI design program I spend a lot of time fighting with the editor, making things go where I want, getting the nesting the way I want, making resize work, that sort of thing. Is using a GUI designer really worth it?

[Dave] I think that we can do a better job of communicating the best practices for using VE. For example, it's much better to develop lots of simple custom controls and assemble them than to try to do everything in one layout. Like I said before, we support this mode of operation very well. But I don't think we have communicated this as well as we could.

[Gili] ... this implies that the tool needs to get thicker in these areas.

What do you mean by thicker?

[Gili] Using a given layout manager is something that takes some time to get used to. Most tools help you use layout managers by providing helper dialogs and visual queues reflecting the manager's properties setting requirements (see figure 2). The thing that dazed me with the Mattise and Foam tools, is that the "laying out" use case is simple and intuitive. You don't really need to know much about the particulars of the underlining layout manager. The use case focuses on what needs to be done, vs. how to do it with LayoutFooBar. Tools can do a lot to relieve the user from the details of a given layout manager. Think about configuring an IP address twenty years ago; it was not simple: setting NIC resources, IP address, Subnet address, TCP settings etc. One really had to know a lot about the plumbing. It is not the case today. TCP/IP settings needs have not changed much, but the software around TCP/IP became thicker, removing the need to set multiple of little knobs and using a few simple ones instead.

Figure 2. VE uses a customize layout dialog for fine tuning but the designers hope to do away with this someday.

Most IDEs have the GUI editor built into them, while yours is a separate download (actually 3 separate downloads if you count all the prerequisites). What are the advantages and disadvantages of such an approach? Do you think this will change in the future?

[Dave] There has been talk within Eclipse.org about coordinating the launches of all the main projects and subprojects to a specific date or short range of days. If this happens, I wouldn't be suprised if you also might see a drop that includes VE. But at the least, if this happens, you'll be able to get VE immediately via Update Manager, which will automatically grab the prerequisites for you.

[Gili] With update manager, it is a bit simpler to install (GA levels of) VE and its dependant projects. There is a work effort under way to make the update manager site more extensible so that various projects can have more control over the content of the update site.

One of the Eclipse member companies, Instantiations, sells a GUI editor not built on top of VE, but here is the Eclipse Foundation itself giving one away for free. How'd that happen? Does this cause any problems?

[Dave] At the time that the Visual Editor Project was initially being discussed there were actually three commercial GUI builder initiatives. But it was clear that Eclipse itself needed a GUI builder in order to be taken seriously. ASC, the company I represented at the time that was funding one of the GUI builder efforts, had a backup plan in case Eclipse.org wanted to get into the GUI builder business. So I volunteered to lead the effort to create the project. The question then became whose code base to use. ASC was willing to donate its code base and IBM was willing to donate theirs. Instantiations wanted to be involved but they didn't want their code base to be the basis for VE. So since IBM's code base was already crafted in such a way that it could support multiple widget sets and languages (ASC's code base was SWT only), theirs was the logical choice. IBM then immediately proved that they could at least support multiple widget sets by adding SWT support to VE, so in retrospect I'm confident that we made the right choice.

As to if this causes problems, we have had many conversations at the Eclipse board level about how operating in an open-source environment affects our business stratgies. Of course open-sourcing some technology creates change and change means pain, and this is not easy. But I think if we look around us we are seeing that there are companies that have successfully adapted and are surviving or thriving in an environment where open-source plays a large role. I think Instantiations is one example here of a company that has done this well.

Do you have any thoughts on the economics of Open Source and about the commoditization of what were formerly expensive programs such as IDEs and GUI editors? For example, how can people still make a living when an OS alternative moves into their space?

[Dave] There are many options, including:

1. Hardware built using open-source software. Sarvega's appliances, for example.
2. Using the GPL to up-sell a commercial version of a product. ie: MySQL, db4objects.
3. Selling a product with premium capabilities above and beyond what the open-source world offers. Instantiations, for example.
4. Services.
5. Application Service Providers like Amazon and Orbitz who build using open-source infrastructure.
6. Value-added reseller. Which winds up often being a combination of #1 and #4 but can also mean packaging a distribution into a tested, pre-validated configuration, for example.

Do you have anything you want to say on the merits of Swing and SWT, and what you see for the future of application user interfaces?

[Dave] I think that developers should pick Swing or SWT based on their requirements. Swing is better if your application must run identically across all platforms. SWT is better if your application should be different across platforms in the areas where the platforms themselves are different--so that customers can't tell that the application was written in Java.

Swing's API is harder to use right to get good results. If you know how to use it right, you can make it fast and you can make it pretty. But it isn't that easy to do this. On the other hand, SWT's API is easier, but it requires more cross-platform knowledge so you don't code something that can't possibly work right across all platforms. This doesn't happen often, but I've been bitten once or twice when I tried to do some really adavnced stuff with the SWT table control and it didn't work right across platforms.

In both cases, you've just got to be experienced with the API or with the cross-platform behaviors respectively in order to use either Swing or SWT to best benefit. So it's not that suprising that people who only really know one of them tend to hate the other. At the end of the day, we think that Swing and SWT are complimentary more than competitive; that they're both good for what they do best. Which is why we support them both.

Bios

David Orme is a consultant specializing in Eclipse-based solutions. He has recently created and deployed Object Manager, a cross-platform standalone SWT / JFace graphical database browser for the embeddable db4objects database (http://www.db4o.com). He is currently working on rich graphical editing tools in an Eclipse RCP environment for Sarvega, the application-specific XML appliance company. Previous projects included a GUI builder that included features that are now in VE and a wide variety of other consulting engagements. In addition to consulting, Dave has served as a representative to the Eclipse.org Legal Committee on the Eclipse board. Dave can be reached at "djo at coconut-palm-software.com".

Dr. Gili Mendel is an IBM senior software engineer and is the technical lead for IBM's Visual Editor for Java project that is part of IBM's Rational Application Developer suite. Gili is located in Raleigh, NC. In his 11 tenure with IBM Gili was involved in various Systems, and Application software development projects. The last 3 years he focused on true "rich client" tooling technologies.

For more information

For more information on the Visual Editor, including download links and tutorials, see the Visual Editor Project page at eclipse.org .