eople communicate with computers on two different levels. On the upper level you see a very flexible system of windows: you can move them, resize, overlap, or put side by side. However, starting an application immediately removes all the flexibility, leaving you to work only inside the scenario developed by the designer of the program. Typically, you cannot move graphics or controls nor resize them. I have designed an extremely powerful mechanism that makes graphical objects moveable and resizable. My technique not only significantly improves existing applications, but it takes them to another level. This article explains in detail the construction and use of moveable and resizable graphical objects.
When you switch on your PC, you usually sink into the world of rectangular windows. You can easily move these windows, resize them, overlap them, or put them side by side. At any moment you can reorganize the whole screen view to whatever you really need. It wasn't this way at the beginning of the computer era; it became the law only after Windows conquered the world. Consider this axiom 1
in modern day programming design:
On the upper level, all objects are moveable and resizable.
To make these features obvious and easy to use, windows have title bars on which users can click to move them, and borders that allow users to resize windows. Being moveable and resizable are standard features of essentially all windows; developers eliminate those features only for special purposes.
Usually, the goal of switching on the computer is not to move some rectangular windows around the screen; you want to do a bit more. You start an application, step into the inner level, and then everything changes. It's here, inside the applications, where you do the real work you are interested in—and at the same time you are stripped of all the flexibility of the upper level; you can do only what the program designer allows you to do. The design can be excellent or horrible; it can influence the effectiveness of your work in different ways, but still it unnecessarily deprives users of any control of the situation. Have you ever questioned the cause of this abrupt change? If you have, then you belong to the tiny percentage of those who did. And I would guess that the answer was: "Just because. These are the rules."
Unfortunately, these are the rules, but rules are always based on something. The huge difference between levels is that on the upper level you have only one type of object, windows, and on the inner level there are two different types: controls, inheriting from windows, and graphical objects that have no inheritance from windows and are absolutely different. The addition of these graphical objects changes the whole inner world.
Controls and Graphical Objects
The inheritance of controls from windows is not always obvious, as controls often do not look like windows. Controls have no title bars, so there is no indication that they can be moved. Usually there are no borders that indicate the possibility of resizing. But programmers can easily use these features for all controls, and from time to time, they do use them, for example, via anchoring and docking. The most important thing is not how you can move or resize controls, but that you can organize moving and resizing without problems.
Graphical objects have a different origin than controls and, by default, are neither moveable nor resizable. There are ways to make things look different than they are in reality (programmers are even paid for their knowledge of such tricks). One technique that programmers use is to paint on top of a control: any panel is a control, so it is resizable by default. With the help of anchoring/docking features, a programmer can make it look as though a graphic is resizable as users resize a form (dialog). Simply paint on top of a panel and make the panel the subject of anchoring/docking. By default, panels have no visible borders, and if the background color of the panel is the same as its parent form, then there is no way to distinguish between painting directly on the form or on the panel. Certainly, such "resizing" of graphics is very limited, but sometimes sufficient; it all depends on the purpose of the application.
Another solution for resizing rectangular graphical objects is to use bitmap operations, but in most cases quality problems, especially when enlarging images, precludes using this solution. Both of these (painting on a panel or using bitmap operations) are tricky solutions and have one common defect—you can use them only with rectangular objects.
When a limited area is populated with two different types of tenants (controls and graphical objects) that abide by different rules, the only way to organize peaceful co-residence and avoid problems is to force them to live under one set of rules. Because graphics are neither moveable nor resizable, the easiest solution is to ignore these controls' features, as if they didn't exist. That is why so few applications allow users to move around any inner parts. Thus you have axiom 2:
On the inner level, objects are usually neither moveable nor resizable.
Interestingly, these two axioms create this absolutely paradoxical situation:
- On the less important upper level, users have absolute control of all the components, and can make changes easily.
- On the more important inner level, users have nearly no control at all. When they are given some control, it is usually limited and always organized indirectly through some additional windows or features.
No one has actually declared these axioms as axioms in a strict mathematical way; at the same time I've never seen, read, or heard about even a single attempt to look at this awkward situation in any other way than as an axiom, or to design any kind of application on a different foundation. Programmers received these undeclared axioms from Microsoft and have worked under these rules for years without questioning them. If you project these same rules on your everyday life, it would work like this: you are free to move around the city or country, but somebody will tell you where to put each piece of furniture inside of your house. Would you question such a situation?
Certainly, anyone reading this article can easily think of an example of resizing a graphical object. For example, in Paint you've seen a dotted line moving with your mouse cursor. You can do this trick fairly easily using an XOR operation—but it has nothing to do with real moving or resizing of objects. This type of "moving or resizing" is only an imitation, but in some situations it works.
Making moveable/resizable graphics is not a theoretical idea of the "nice to have" type. For many years I worked to develop very complicated programs for engineering and scientific tasks in totally different areas. Though the aims of these programs had nothing in common, all of them required, to a high extent, the use of different forms of plotting. The quality of users' analysis of the most difficult problems in both engineering and scientific tasks (and in many other disciplines) depends heavily on the quality of the graphical presentation of data and results. Because every user has his personal view about how a system must look to be the best instrument for their own work, the development of such systems happens in parallel with never-ending discussions (and even quarrels) between designers and users. I suspect anyone who designs this type of application is familiar with this situation, and is used to working under the pressure of multiple simultaneous requests, which are often in opposition to each other.
Giving users full control to move graphics in such complicated systems would help to reduce the endless discussions about which graphical layout offers the best view. Full control would significantly increase the effectiveness of engineers' work with such applications, which is the main goal. I saw again and again that the inflexibility of the graphics, designed and fixed by the programmer of the application, became not only the main problem in further improvement of engineering and scientific software, but became the real barrier in exploration and solving of the most interesting problems.
Big engineering and scientific programs are brilliantly designed, but development of big applications takes time, so every user is restricted to whatever vision of the situation the designer had one, two, or three years ago. These are the consequences of having non-moveable graphics—everyone must work with designer-driven applications.
In The Universe in a Nutshell (Bantam Books, 2001), Steven Hawking writes, "In science, finding the right formulation of a problem is often the key to solving it
." When I started to work on the problem of making graphics moveable and resizable, I began with the analysis of the features that I would like to implement. My goal was not to make some kind of moveable graphical object (for individual objects of a particular type anything can be done), but to find a general solution. Initially I looked at scientific and engineering plotting, which usually has a rectangular shape—but that was only one kind of experimental model. I looked for the general solution and I found it. Before describing the whole algorithm I want to emphasize that:
- You can use my algorithm in absolutely different areas and with arbitrary forms of objects.
- You can and must look on the design of moveable/resizable graphics separately from the consequences of using such graphics. Classes and algorithms used for the design may differ, but including any form of moveable and resizable graphics serves to move the application into an absolutely new paradigm—user-driven applications.
- It is theoretically a "nice to have" type of idea. At www.SourceForge.net in the MoveableGraphics project you'll find a whole package of applications and documents that help to explain moveable/resizable graphics.
|Editor's Note: This article was first published in the March/April 2008 issue of CoDe Magazine, and is reprinted here by permission.|