Graphical vs textual editing

The implementation of a class may be edited. The editor provides full standard text editing capabilities and several advanced and specialised features. It may be used by students unfamiliar with editing techniques as a simple GUI editor using mainly the mouse and pull-down menus. However, it also has a powerful and configurable command set allowing more experienced users to perform more complex operations. Several Blue specific functions are supported, such as the insertion of skeletons of frequently used code structures (loops, conditionals, routines, etc.). It is, like the rest of the Blue environment, designed to be easy to use initially to support beginners, but

CHAPTER 7: THE BLUE ENVIRONMENT

to be able to be used in a more powerful way as the experience of the user grows. The aim is to support beginners, but not to keep them on a beginners level for a long time. A full editor manual is available [Kšlling 1997b].

The editor is tightly integrated with the project manager and the compiler. When a new class is created in the project window, a code skeleton is automatically created. The initial source is a valid (but empty) Blue class. This ensures that a project can immediately be compiled after classes have been added (so that the user can work on one class at a time, without having to open all classes created in a project before the first full compilation).

The automatically created skeleton together with the strict class structure of Blue make it very easy for students to recognise where different aspects of the source, such as variables and routines, have to be inserted.

The project can be edited graphically (by inserting arrows into the class structure diagram, as discussed above) or textually in the editor. Both views are kept consistent at all times. If, for example, an inheritance arrow is inserted graphically, the source of the class is automatically updated. When the class is opened, the inheritance definition is visible in textual form. (If the class was open at the time of the insertion of the arrow, the source code is immediately updated on the screen.) The reverse case also works: when a definition of a uses or inheritance relationship is added to the source of a class, the project diagram will be updated as soon as the class is saved. Closing a class view automatically saves the source, so the standard sequence of opening a class, modifying its definition and then closing it leaves a diagram that always reflects the current relationships. To achieve this effect, the editor cooperates with the compiler. After saving the classÕs source, it calls the compiler to perform a superficial parsing of the class to extract the information about its superclass and used classes. The compiler then reports the result to the project manager, which updates the graphical project representation. This analysis is, even for large classes, fast enough that it is not noticeable in normal interactive operation.

It is important to allow both graphical and textual editing. In the early stages of program design and class structure definition, we do not want students to have to descend to the lower level of source code definition to specify their applicationÕs structure. Relationships should be specified using a higher level tool (the graphical structure editor). Later, however, when the source code is under development, a user must have the opportunity to make changes without being forced to leave one tool and use another one, only because a definition was originally made using that other tool. At the same time it is, of course, essential that the information displayed in both tools is consistent.

7.4.3 Alternatives

Initially, it does not seem very sensible to implement yet another text editor. Many good editors are already available and many users have their preferred editor. In fact, discussions about the relative benefits of particular editors frequently take just as much the form of religious debates as discussions about programming languages.

CHAPTER 7: THE BLUE ENVIRONMENT

Users feel strongly about their tool of choice, and it would be a benefit to allow them this choice.

However, there are obvious problems. Much of the benefit of the system described above comes from the tight integration and specialised features of the Blue editor. We have seen examples of its close cooperation with the project manager and the compiler, and in the next sections we will discuss equally tight integration with the debugger and the library browser.

All of this could not be achieved to the same degree with a standard editor. Even if the integration could be partially achieved with a highly customisable editor, such as Emacs, this would not solve the problem. Allowing the use of standard editors only makes sense if there are several editors available to be used in conjunction with the Blue environment (otherwise we would not give the user a choice either, but still prescribe one particular editor). We cannot see how functionality even remotely resembling that provided by the present Blue system could be achieved with standard text editors such as ÒviÓ.

There are, however, some aspects which may serve to alleviate the situation. Firstly, the expected users of the environment are largely beginners, not professional software engineers. Beginners often have not yet developed such a strong preference for a particular editor. They are more willing to use a new editor, particularly since the Blue editor provides better functionality than the editors the students are most often accustomed to Ð those which are typically available on Windows systems. In an environment for software professionals the question of supporting different editors might well be decided differently.

Secondly, the editor provides user-definable key bindings. With this functionality, the key bindings can usually be defined to resemble many other editors. Thirdly, for those users who regularly use Blue and also do other editing tasks and are irritated by the use of different editors, another solution is available: the Blue editor can be used for all other editing tasks as well. A stand-alone version of the editor (named Red) has been developed as a general purpose text editor. Many students who start programming with Blue indeed use Red for all other editing tasks during first year and in later years of study.

This makes the situation slightly better than with most other environments. Almost all graphical integrated development environments supply their own text editor which cannot be replaced by another editor of choice. In comparison, the Blue editor offers better functionality then most, and the fact that it is available as a stand alone text editor can serve to avoid having to use multiple editors.

CHAPTER 7: THE BLUE ENVIRONMENT

7.5 Compiling