Design and Use of Moveable and Resizable Graphics, Part 1

People 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 and you can work only inside the scenario developed by the designer of the program; 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 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 which users can click on to move a window, and borders that allow users to resize a window. Being moveable and resizable are standard features of all the windows and you eliminate these 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. Here, inside the applications, you are doing 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 only do what the designer of the program 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 is awkward that users are absolutely deprived 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 a lot from windows, and graphical objects that have no inheritance from them and that 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 are of an absolutely different origin than controls and, by default, they are neither moveable nor resizable. There are ways to make things look different than what 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 if a graphic is resizable as one resizes 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 in the form or on the panel, which resides on it. Certainly, such “resizing” of graphics is very limited, but in some cases it is just enough; all depends on the purpose of the application. Another solution for resizing of rectangular graphical objects is the use of bitmap operations, but in most cases you can’t use this solution because of quality problems, especially for enlarging the images. Both of these tricky solutions (painting on a panel or using bitmap operations) have one common defect-you can only use them with rectangular objects.

If any limited area is populated with two different types of tenants (in our case-controls and graphical objects), which prefer to live under different rules, then the only way to organize their peaceful residence and avoid any mess is to force them to live under ONE law. Because graphics are neither moveable nor resizable, the easiest solution is to ignore these controls’ features, as if they don’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 upper level, which is not so important for real work, any user has an absolute control of all the components and any changes are done easily.
• On the inner level, which is much more important for any user because the real tasks are solved here, users have nearly no control at all. If they do have some control, then it is very limited and is 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 and 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 could fairly easily do this trick with the help of an XOR operation and it has nothing to do with the real moving or resizing of the 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 absolutely 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) highly depends 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 goes in parallel with never-ending discussions (and even quarrels) between designers and users. I think that anyone who designs this type of application is familiar with this situation and has to work under the same pressure of multiple requests, which often can demand opposite things. Giving users full control to move graphics in such complicated systems will reduce the endless discussions about which graphical layout offers the best view; full control will 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 science, finding the right formulation of a problem is often the key to solving it…” [Hawking, S. The Universe in a Nutshell. Bantam Books, 2001]. 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 graphical objects moveable (for individual objects of a particular type anything can be done), but to find the general solution. Though initially I looked for the solution for scientific and engineering plotting, which usually has a rectangular shape, 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 be different, but if there is any form of moveable and resizable graphics, then it is the base for an absolutely new paradigm-user-driven applications.
• It is a theoretical idea of a “nice to have” type. 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.

By: Sergey Andreyev

For many years Sergey Andreyev worked in the Computer Center of the Russian Academy of Sciences. First, on the systems for applied optimization, and then he found that he was fascinated by sonogram images. He received a PhD for “Design of new algorithms and programming systems for speech analysis”.

He likes to implement new ideas in new areas and he has designed complicated systems for telecommunications, thermodynamics, and analysis of big electricity networks. He has also worked on applications for foreign language studies and for organizing photo archives. Photography is one of his hobbies.

Sergey prefers to work with people who are more talented than he is and surrounded by the thousands of volumes that concentrate the wisdom of the past. Throughout the years he found places to work on his ideas in the USA, Finland, and New Zealand.

He likes to travel where the only sign of human existence on Earth is the rare movement of tiny lights across the dark sky.

andreyev_sergey@yahoo.com