2 - Gili Mendel and Joe Winchester of the VE Project

Riyad Kalla: Welcome to episode two of ten in the EclipseZone Callisto Podcast series. I'm your host, Riyad Kalla. In this series, we're interviewing key members from each of the Eclipse projects that will be included in the Eclipse Callisto release. Today and we'll be interviewing Gili Mendel and Joe Winchester, who are part of the VE project. Thanks for joining us guys.

Riyad Kalla: Why don't we and go ahead and start and get a summary of the VE project from Joe.

Joe Winchester: Okay, thanks Riyad. The Visual Editor project serves two goals, one of which is to fill the GUI builder slot. If you think of Eclipse out of the box, it has excellent tooling for developing Java. One of the scenarios for that is people developing Java where their destination is to run it with a Windowing Toolkit, and we wanted the Visual Editor to be able to fill that slot, but more importantly, we wanted to have something that was extremely extensible and was something that others could extend for new GUI toolkits and for new scenarios; new devices, new virtual machines and so forth. It serves two goals, one of which is to be a GUI builder and one of which is to be a framework for people who wish to produce GUI builders.

Riyad Kalla: You guys would say that the VE project started because there was an obvious lack of support for the RCP and visual development?

Joe Winchester: Not particularly, no. The Visual Editor project got started at IBM before Eclipse was even conceived as a project. IBM had a series of GUI builder tools: visual age for Smalltalk, visual age for Basic, visual age for COBOL, visual age for RPG and the last one was visual age for Java. Each time a new language was tackled, or a new GUI toolkit was tackled, there was always a huge amount of churn. We never had a code base that we were able to evolve into a new technology or a new language, yet there were just a huge amount of patterns and frameworks, and it was crying out to be rebuilt as a whole stack, from the ground up designed to be extensible.

Joe Winchester: One of the biggest problems we had with visual age for Java was -- I worked in the development team at IBM back in the late 90s -- when we had smart customers who built their own custom widgets in Java: spreadsheet widgets, spinner widgets, graphing controls and so on, they really wanted to be able to plug them into visual age for Java at that time, and to be able to extend and leverage the way that the code would be generated; the popup menu options available, the choices, how something would look in a property sheet, new layout managers was a big one for us; people would write their own layout managers.

Joe Winchester: Really, why we got started was we wanted to write something from the ground up that was able to be a visual age for Java type beast running inside Eclipse, but much more importantly was able to have a very good plug-in architecture and APIs such that they could be used and extended by IBM and by others.

Riyad Kalla: Gili, Why don't we start with you. How did you guys get involved in the VE project?

Gili Mendel: Actually, I started with the VE project in Raleigh, and Joe is actually one of the grandfathers of Visual Editor. I used to be a device driver developer, and when they asked me, "Hey, do you want to do some GUI stuff," I thought, "Hmm, the GUI guys, what do they know about programming?" But, it turned out to be that the engine underneath the Visual Editor is somewhat complicated, and as you get down to the details of it, it's also in the same type of problems.

Gili Mendel: What Joe was saying is very true: the Visual Editor is developed such that there is a central EMF model and everything goes around it. Anything that you change, you change in the model and if code is generated, it's by adapters that are actually sitting on the model, if a property sheet is changed, it's changed because of an adapter that is sitting on the model, so the extensibility and the ability to generate anything you want is very high, which causes a platform that enables us to work on different levels of Java based, device based or anything based that is very interesting.

Riyad Kalla: You brought up something interesting there. The Java EMF model that you guys have developed for the VE project is a considerable model, and it's fairly impressive. Has that been talk about pushing that down either into the EMF project or this new top-level modeling project we've been hearing about?

Gili Mendel: As a matter fact, the VE actually has a core, which is called JEMS, the Java EMF model. JEMS is actually shared by both VE and WPT tooling, so this model is being leveraged other ways.

Riyad Kalla: Great, fantastic! Joe, before we leave that question; how did you get involved?

Joe Winchester: With the Visual Editor project, I think that I was one of the two or three people that started it really, with colleagues of mine, Rich Kulp and Peter Walker, who still are comitters on the project, like myself. I was hired by IBM as an experienced hire because I had used a lot of IBM's tools at the time. I used visual age for Smalltalk, and I would constantly beat up any IBMer I ever saw at a conference or who visited at the company I was consulting for about all the list of improvements I wanted. In the end, for personal reasons, I wanted to give up consultancy and I ended up joining IBM and working on the visual age Smalltalk team, which became visual age for Java, which then became what's now the Visual Editor.

Riyad Kalla: That list of improvements you kept hounding those people with became your to-do list after you got hired?

Joe Winchester: Right, poacher turned gamekeeper!

Riyad Kalla: Right, exactly! As you hinted at, the visual development of the Visual Editor is not just for Swing and SWT, as a lot of people think. You guys are trying to create an entire platform for visual development in general. Has there been interest from other projects? I know the GMF project is really focusing on a lot of visual developers; for example, they're working with the UML2 team. Is there a lot of interest from other projects to either collaborate with VE or have VE and GMF collaborate? It seems like there's a lot of visual development going on under the Eclipse umbrella.

Gili Mendel: Right. When you say visual, visually is a large term. You could actually look at them and VE differently. We are actually focusing more on the visual GUI building, and that means things like the eSWT project -- actually, some of them have produced some plug-ins extending us -- and any other type of GUI builders. There are some companies out there that extended the Visual Editor to sell real products, actually building components to eSWT.

Riyad Kalla: Oh, interesting.

Joe Winchester: That's a really good point. GUI is a graphical user interface on an end running program, and a good example is GEF, a graphical editing framework. GEF, in fact, was one of the things that was spawned out of the fact that in the IBM visual age line there was no light weight drawing framework that allowed you to adapt an object model to a set of light weight figures. That's really where GEF started, and in fact, the two developers that kicked GEF off were people that had worked on the visual age tools line.

Joe Winchester: We're always given invitations to participate in things like GMF because there is some synergy, but we have to draw the line somewhere. The majority our users put pressure on us, and give us requirements where they want us to, first of all, enhance the straight out of the box GUI building experience for the widget toolkits and support, enhance the code generation patterns and so on, support enhanced ways of doing copy and paste, more lap manager stuff -- straight requirements list, most of them, we can consume. The second one of which is people who are trying to extend us, so we just have to draw the line somewhere. Apart from JEM, which is a powerful toolkit that is used elsewhere, we tend to try to limit our involvement with those simply because we like to be driven by user requirements rather than technology ones.

Riyad Kalla: How much collaboration is there going on between -- I know you guys have EMF and GEF as dependencies in the VE project -- are there a lot of requirements you guys are kicking back to those teams, saying, "Hey, in order for us to get this, this and this done, we need you guys to change this, this and this," or have they provided you with frameworks and APIs that you can just build on, and you haven't needed to kick anything back their way?

Joe Winchester: There's a huge amount. With EMF, one of our comitters, Rich Kulp, is a very heavy user of EMF and he participates in all the conference calls. We used EMF in a slightly different way. EMF tends to be used as a static code generation model. People have a static model, then they generate EMF that gets them XML persistence and all the benefits of the model behind it, first class relationships and so forth. We have a dynamic model, where we discover the shape of JavaBeans, or in the case of SWT, it's not quite JavaBeans; we discover the shape of the class that somebody is about to drop into the palette or somebody has used in their code that we now have to discover. We discover that dynamically, and we create the EMF objects dynamically, so we use dynamic EMF. We push back a lot on requirements for them. We push back code, and the same is true with GEF; we'll push back code and we'll push back requirements on GEF.

Gili Mendel: This is true. As matter fact, the Visual Editor started a little bit after GEF -- well actually, before GEF, but a little bit after EMF, but the matter of the fact is that it was one of the first clients of both of those guys. During the iterative development cycle of those projects, Visual Editor was one of the key pushers for those projects.

Riyad Kalla: Oh, I see.

Joe Winchester: And the JDT as well. We use the Java development tooling because we have to parse and code generate Java source, so we push back on Java development on the JDT a fair bit. We'll open enhancements, and again, some SWT as well. When we have to tool up for SWT, we would get involved with them. But, you want to limit -- it's like you've only got five or ten trump cards you can play your hand, you want to save those up for the things when you really can't find an alternate solution, because again, those teams are up against the wall with more requirements then they can handle, so you don't want to swamp them with requirements.

Riyad Kalla: How helpful has the community involvement in VE been, both from the users -- the mailing list people using it to build Swing and SWT GUIs, as well as the companies extending it? Has there been a lot of patches and collaboration coming back from the community in general or has it just been requests and waiting to see what you guys do?

Gili Mendel: There were both. We had people, like Red Hat had extended it and needed some stuff for the Visual Editor in order to package it within some packages in Red Hat. There were other users that provided patches, but mostly it's the comments from the newsgroups and the mailing list that influences us in what needs to be done or what needs to be done first.

Riyad Kalla: I see. Joe, anything?

Joe Winchester: No, that's a fair thing. We will always want more involvement from other users, and that's what we're really trying to do. I think open source really flourishes in that environment. I can give you an example: support for the Visual Editor on the Macintosh was something that wasn't a core -- Gili can give you a little more about the history, but it certainly wasn't a core line item that we were committed for a release, but then the support for that just came. That came from people in newsgroups that decided they wanted it and they got together.

Gili Mendel: The bottom line was we didn't have a Macintosh to work on, so we were really counting on people outside to actually figure out the code, get the patches tested and make sure everything works and we integrated it in.

Joe Winchester: So, all the Mac support came, as Gili said. There's a company called Canoo, out of Switzerland, and they have a very successful product called UltraLightClient, which is kind of a Swing for J2 VE, that's the best way I can describe it. You code up a servlet and you import Swing packages and code as though you had a GUI on your server, which is sort of impossible because the user can't see it, but at run time, there's mechanics that makes sure that the user that's attached to that servlet can see that GUI. They are very heavy user of ours.

Joe Winchester: Recently, for example, was saw a huge increase in newsgroup traffic. There's an individual right now who is adding support for XWC form layout; it's something we support, but not really first class. We support grid layout very, very well; it's the one that most people use. We never really got form layout working. But, just by simply looking at our APIs and doing a little bit of digging around with a debugger, he came up with support for form layout, and there are other things as well. For example, we haven't done any work on Mustang. Mustang is the Java 6.0 release that Sun is producing right now. Someone on the Java.net forums has a plug-in that extends the Visual Editor to support all of the Swing laps: JX, DesktopPane and various new widgets that are in Mustang.

Joe Winchester: Again, we've really not been involved with that. We might answer a couple of newsgroup questions or publish some API tutorials on EclipseCon, and that's the beauty of open source. Sometimes you just light a number of fires and some go out and some just take off and keep burning on their own.

Riyad Kalla: Exactly. You touched on the community involvement and feedback. I know that a big thing that stirred the Visual Editor pot, just visual designers in the general case, was when NetBeans released the Matisse designer. At that time, I remember a lot of activity popping up on the VE newsgroup and mailing list. It seemed to me like it was mostly that the snap to design, removing the need for people to be concerned with UI guidelines and things along those lines -- what did that do to VE's roadmap? Where there features that all of a sudden got requested so much that you guys had to mix things up or was everything steady after that, and it didn't affect it much?

Joe Winchester: It's a good question. I think in truth, Matisse didn't really affect it. There's a very good software book written by somebody called Joel Spolsky that I've just finished reading, and various other things that say, "Don't listen to your competitors, listen to your customers," and again, at IBM that's constantly drilled into people, and we're both IBMers. Yes, there was a lot of flack from it, and we got pressure from the most senior people in the Eclipse management team. They gave us lots of pressure to support group layout, for example, one of the things that was very good in Matisse. We turned around and we then critiqued NetBeans.

Joe Winchester: NetBeans is a top down only GUI builder; I'll very quickly describe the difference between that and what we do. In NetBeans you open, you say I want to visually design a class and you design it, you drag and drop your widgets. It's very good; it's as good as any other. When you hit save, or when you switch to the source tab, it generates your code. Your code is now not available for you to modify. You can augment the code by saying, "When this button is clicked, do something here," but if, for example, there was something there you did not quite like about a label or you wanted to change the exact syntax as to how color had been provided and so on and so forth, you cannot do that. It's one way; it's from GUI to source only. What they persist is that they don't only persist the dot Java file, but they persist this metadata that represents the source. Now, we used to do that for visual age for Java and we haven't done that for the last seven or eight years or something. We pass the source when it is opened, we recognize the code, we provide flexible coding patterns and we make it so that you can modify the source and get to the code and back.

Joe Winchester: Another thing that we do as well, within Eclipse, within the Java project, is the entries on the vas classpath of the Java or Java/C compiler is completely fluid. You can just add new jars and projects and pre-reqs and add new JRE levels and so forth and create a whole new stack of things. Now, the JDT recognizes that -- compiles against that, code assists against that, so does the Visual Editor. If you add in a new JRE that we don't support yet or you've added in a new jar with some new JavaBeans, or some new XMC custom widgets, we just light up and we just will work with that and support that. We have an architecture that supports that. NetBeans fails on both of those accounts. They are top down only on the GUI buildup and the JRE that they run that preview widgets is the same JRE that the IDE has been launched upon.

Joe Winchester: We think in the long run, once everything has settled down, just extensibility and a good open source community will always win out. Gili might have a different answer, but my answer is no. NetBeans -- we pretty much just said no, we are going to hold on to the tiller, we'll hold to course. We know what's right and we think we'll win.

Gili Mendel: Joe is absolutely right. If you look at what's the mission that we set forth for the Visual Editor, it's to be a platform. As a platform, we have reference implementation for SWT and Swing, but it doesn't mean that we produce any run time. What it means is that the Matisse, the goodness of Matisse -- the bottom line is, there is no doubt in anybody's mind that Matisse got some good things done. The way they got it done is by developing both run time and UI layout manager that works with the tooling, and the tooling to run the content manager because at the end of the day, the engine is really, really rough to deal with, as much of a veneer you are going to put on top of it, you are still going to have some of the bumps reflecting outside of the veneer.

Gili Mendel: What we are saying is something very simple. We cannot provide and we don't intend to provide layout managers to introduce to SWT, that's part of the run time to do, but what we would do is provide the extension points for people to do whatever they want. Adding a layout manager -- if you want to use a particular layout manager and you want to extend the Visual Editor to have the tooling exactly the way Matisse does it in Visual Editor, it's not a big deal. If somebody wants to contribute, it will take it. As a matter of fact, we are thinking about doing it ourselves. It may be happening sometime in the future, but the bottom line is, we are in the process of making APIs and extension points to the platform versus focusing on the tooling itself.

Riyad Kalla: I see. Is there any hope of having the Instantiations team kick back their new additions?

Gili Mendel: You are welcome to come and help us!

Riyad Kalla: Another interesting thing that people in UI development that is becoming a big ordeal, it's probably been a big deal for about the last year or so, is data binding. We have seen that the JFace data binding recently went into the experimental status for Eclipse 3.2. Have there been a lot of requests for support for that? Are you working for support for the data binding? What would that look like?

Gili Mendel: You see, data binding, and that's my personal view, for me when you say, "I drop in some buttons and doing the Matisse cool stuff in the line in," this is cool stuff, but this is kind of 101 of GUI building. The next thing after you drop those components, you want to populate them with data. Everybody builds models or connect to web services or connect to what not. I think that's the next level where people need some proficiencies and tooling to make them more productive. That's something that would be great to extend the Visual Editor on for binding into many other domains, if it's domain models or server models, or what not.

Riyad Kalla: Okay. Joe?

Joe Winchester: We were very heavily involved in JFace data binding project and both Gili and myself are comitters on that project, although most of the work is done by Boris Bokowski of IBM Ottawa and Dave Orme. I think the thing to do with that is to wait and see. We've talked about how we would like to tool for that and having done visual objects and lines between them, and all sorts of stuff that's very easy to whiteboard. Again, the thing that we'll do with that is we'll sit back and wait and see what our users request of that framework. It may be that framework is so easy to use without tooling that it almost does not need it. So, we'll just wait and see. We don't have any concrete plans for 3.2.

Riyad Kalla: To change gears a little bit here, you're talking about VE as a platform for visual designers and so forth, and you mentioned something about Red Hat working on a designer. Is there an intention for VE to support different visual designers, and as an example that someone mentioned, was WX widgets on Ruby, and also what comes to mind, after you mentioned Red Hat, was even GTK because they seem to have adopted Eclipse as their premier IDE.

Joe Winchester: There are two questions here. The first one is Ruby -- at the moment at the heart of the Visual Editor is JEM model and that is a Java EMF model and that's very based around Java at its core. We have people who have non-Java models, they use the benefits of VE and they kind of fake out to be Java. We don't yet have anybody that's used really first class use in a different language. There is talk of it, there is certainly talk of it being done for C, but somebody would have to really start from the ground up and model Ruby within EMF, for example. That's not something that's on our radar. The second part of the question -- I've forgotten for a moment.

Riyad Kalla: Was it about the Red Hat and GTK designer?

Joe Winchester: Yes, tell me a little bit more about that because out of the box, we support Swing and SWT.

Riyad Kalla: I was just curious about how much work it would take -- but I think you answered it -- to develop, for example, a GTK designer on top of VE that can be used within Eclipse with, let's say, the CDT project. I think you touched on it that it would require ground up work to model the C libraries and things like that.

Joe Winchester: There are people looking at that and unfortunately, because there is a commercial company looking at that, I can't tell you who that is. But, there are people looking at that who are involved with Eclipse community and their intention, I believe is to see if they can bake a cake around the Visual Editor with a C EMF model.

Riyad Kalla: Gili, anything to add?

Gili Mendel: That's pretty much right.

Riyad Kalla: Now guys, what is your favorite new feature in VE 1.2?

Joe Winchester: I think our favorite feature is we support the Eclipse. Eclipse for SWT has the SWT Windowing Toolkit, where basically every SWT thing maps on to a native pretty much; at least on Windows it does, anyway. But, it also has another toolkit called Eclipse forms toolkit, org.eclipse.ui.forms is the plug-in name, and that's the one, for example, used by the plug-in editor. It's almost a web look and feel; it's a white background and flat buttons and some little twisties to expand things. We put support in for that and we support the expandable composites and sections and hyperlinks and all the good and wonderful stuff. The nicest thing for me about that was how quickly we did it; we did it in a fairly short space of time and also the fact that we didn't actually have to touch a single line of core Visual Editor code, to the best of my knowledge. We just took the API that by now we have already proven -- road tested it for AWT, for swing, for SWT and then we just put in Eclipse form with it and it just worked, and that was nice for me. It served both a good end user function point and also another very good proof of the extensibility.

Riyad Kalla: Right.

Gili Mendel: From my point of view I think one thing we started to work on is the JFace support. The nice thing about JFace is that JFace itself is not a widget component like SWT is, it's just a wrapper. People usually, if you look at GUI builders in the past, they just look at as just one more widget type, but the way Visual Editor says, when you draw up a table, at the beginning users, especially users that are novices about SWT specifics, do not understand the difference between an SWT table and a JFace table -- a table viewer. In essence you really draw up a table and you could convert between the JFace viewer back and forth just by right clicking it and having a designation to annotate and says this a JFace table, but it is a table. In essence you really try to leverage the fact that Visual Editor could work with widgets and widget wrappers within the framework itself.

Riyad Kalla: Interesting. As you've gotten 1.2 out the door and Callisto has been taken care of, are there any big changes coming down the pipeline for VE 2, or whatever the next big release of VE is, that have made it to, maybe they've only been talked about or maybe they needed to be sidelined in order to get VE 1.2 to the point where it was ready for Callisto? What are the next big features we can expect that you guys are excited about?

Gili Mendel: I am not sure that we have any specific features that we are saying, "this is the target goal to be running off," as a matter of fact we are looking at the community itself to actually help us and direct us and push us to the right place to go.

Riyad Kalla: Okay. Joe?

Joe Winchester: Yes, pretty much. We've got two masters who we serve, one of which is the community. We definitely want to get more of our APIs out there understood and get more tutorials published; I think we possibly haven't done a good enough job with that. Sometimes it's an exercise left to the intelligent user. Everybody goes behind scenes and they see these internal files that we have in packages, and after a while they get the hang of what's going on and put some break points. We want to make that an easier experience for people to digest. Hopefully we can turn some of our more experienced people on newsgroups and things, who have gotten to be a little bit bolder, and help them to become comitters and gain the benefit of their expertise.

Joe Winchester: From the point of view of just straightforward line items, I suppose coming back to the original architecture, one of the reasons that the Visual Editor is extensible because every time you start it up and you open a class, it has to create the widgets, and it does it in a virtual machine. That virtual machine is not the same virtual machine that you're running at the moment in Eclipse. That's a strength and a weakness. It's a strength because it's very extensible for people who are running at different JRE levels, but for people who aren't, for people who just start Eclipse and just want a very simple out the box GUI building experience, and they're running the same levels of Swing or SWT that Eclipse has got, one of the things we've always toyed about was the fact that we would actually run with the same set of widgets that are inside the IDE. For example, you talked about Instantiations, that's one of the things that Instantiation's GUI builder does and so does NetBean's, and it definitely is faster for performance because it is less engineering. We've done lots of performance optimizations with our target VM architecture, but we've probably slightly run out of runway. For me, the next big feature would be to just get it so that performance delta was unnoticeable for people who weren't really trying to leverage the fact that classpath was different, and then for the people that were, the Visual Editor would detect that and you would just take the second or so delay that that adds on top, just so that people's out of the box experience of the end user tool was a much snappier one. That would be the big thing, and we've always sidelined that, and for me that would be the big thing for us to work on.

Riyad Kalla: Well guys, we're getting close to the end of the podcast, is there anything you wanted to add before we wrapped up?

Joe Winchester: I suppose the only thing I want to add is that we just want to encourage as many people as we can to just use it and give constructive feedback, check out our newsgroup and get involved. It's a fantastic route to help us to do some documentation, help us to submit some patches, we're just been hugely welcoming. If we get good e-mails, good stuff from the newsgroup, we'll always break stride from what we're doing in our day-jobs at that particular point in time, and try and deal with that problem. We're just trying to encourage as many people as we can to just get involved and hopefully become maybe even a comitter if that's their goal. We'll just always welcome that and help people to become part of the VE community, that's all.

Gili Mendel: I totally agree, I think that the Matisse example is a great area where someone could actually contribute without devoting much time and effort to the Visual Editor. Anybody could go ahead and implement some plug-in outside or inside and say, "Oh, here's an extension for the lap manager, and we have supporting this and that." Without doubt, I'm sure people would like to do that; it's a great challenge to us all.

Riyad Kalla: Absolutely. Well guys, Gili Mendel and Joe Winchester from the VE project I wanted to thank both of you for taking the time to sit down with us.

Gili Mendel: No problem.

Riyad Kalla: I want to thank everyone for tuning in and I hope you enjoyed yourselves. This concludes episode two of ten in the EclipseZone Callisto Podcast series.

Transcription by CastingWords