JPH07200233A - Graphic parts management device - Google Patents

Abstract

PURPOSE:To solve a problem at the time of defining the correlation of plural graphic parts by means of coding a program. CONSTITUTION:A correlation resource regulating the mutual relation of the plural graphic parts where construction processings are mutually related is registered in a resource file 40. When the execution request of the construction processing on a widget is received from an application program 11, a window manager 12 executes the construction processing of the plural widgets based on the mutual relation resource registered in the resource file 40.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a graphic component management apparatus for managing a mutual relation of a plurality of graphic components having processes associated with each other for constructing a graphical user interface.

[0002]

2. Description of the Related Art Generally, a high-performance personal computer such as a workstation employs a graphical user interface (hereinafter referred to as "GUI") as a user interface.

As a system for providing this GUI,
For example, the X window system (X window is a registered trademark) is known. This X window system is a multi-window system capable of simultaneously displaying a plurality of information by using a plurality of windows.

In this X window system,
Widgets are prepared as graphic components (buttons, dialogs, etc.) for constructing a GUI.
When an event occurs, this widget can communicate with an application program or another widget by means of a callback. Also, each widget belongs to a certain class and always has a window associated with it.

In the conventional tool kit (MOtif, etc.) provided for this X window system,
A method for defining the action of an event generated in one widget on another widget has not been sufficiently provided (see Documents 1 and 2 below).

Reference 1: XToolkit programming OSF / MOTIF version D. A. By Young Toppan Published April 15, 1991 Reference 2: OSF / Motif Programmer's Reference Release 1.1 Open Software F
published by Hitachi Ltd., Software Development Division, translated by Toppan, published November 25, 1991. In other words, in the conventional toolkit, GUI
For building (hereinafter referred to as "building process")
There is not a sufficient way to define the interrelationship of multiple widgets that are related to each other.

Therefore, conventionally, the mutual relationship between a plurality of widgets has been managed by defining the mutual relationship by coding an application program.

As the above-mentioned construction processing, for example, a display processing for displaying the widget on the screen, a deletion processing for deleting the widget from the screen, a deletion processing for deleting the widget from the screen and destroying the image data for display. There is such a process.

[0009]

As described above, conventionally, when the construction process manages the interrelationship of a plurality of mutually related widgets, this interrelationship is defined by coding the application program. Was there.

However, with such a configuration, there is a problem that the number of man-hours for developing an application program increases, and when the mutual relationship between a plurality of widgets is changed after the program is developed, the program must be rewritten. It was

Further, in such a configuration, it is difficult to clearly define the mutual relationship of a plurality of widgets, and therefore it is possible to induce a bug (for example, a bug that the input cannot be accepted) generated from the GUI specification. There was a problem that there is a property.

Further, in such a configuration, when a specific mutual relationship (for example, the priority when displaying a plurality of dialogs) is defined, the definition may be extremely difficult or may not be defined at all. There was a problem.

[0013]

In order to solve the above-mentioned problems, the present invention provides an information for defining the above-mentioned mutual relation in a device for managing the mutual relation of a plurality of graphic parts whose construction processing is related to each other. And a means for executing a construction process for a plurality of graphic parts based on the mutual relationship defining information provided by this means.

[0014]

In the above structure, the mutual relationship of the plurality of graphic parts whose construction processes are related to each other is defined as data, not as a program. Then, a construction process of a plurality of graphic components is executed based on the mutual relationship represented by this data.

[0015]

Embodiments of the present invention will be described in detail below with reference to the drawings.

FIG. 1 is a block diagram showing the configuration of the first embodiment of the present invention. In the following description, the case where the present invention is applied to the X window system will be described as a representative.

In the X window system, a server / client system is adopted as a system for realizing the function. Here, the server-client method is a method in which a target function is realized by two programs, a client and a server.

FIG. 1 conceptually shows the configuration of the first embodiment of the present invention based on the model diagram of the server-client system.

That is, in FIG. 1, 10 is a client that issues various requests to the server, and 20 is a server that manages the hardware unit 30.

The client 10 requests the server 20, for example, to open / close a window or display a widget or text on the window.

The server 20 opens / closes a window on the screen of the display 31 or displays a widget or text in the window based on a request from the client 10. Further, the server 20 reports the event to the client 10 when the event occurs.

The event occurs when the user clicks the button of the mouse 32 or presses the key of the keyboard 33. This event also occurs when the window state changes.

The client 10 includes an application program, a window manager, a utility and the like. In FIG. 1, the application program 1
1 and the window manager 12.

The application program 11 requests the window manager 12 to open / close windows and generate widgets, for example. When the application program 11 receives an event from the server 20, the application program 11 decrypts the event and requests the window manager 12 to perform widget construction processing based on the decryption result.

Here, the widget construction processing means the processing of displaying, deleting, deleting, etc. of the widget as described above. In addition, the generation of the widget means generation of image data for displaying the symbol of the widget.

The window manager 12 requests the server 20 to open and close windows requested by the application program 11, manages the display positions of windows and widgets, and creates widgets. Also, this window manager 12
Relays the event reported from the server 20 to the application program 11.

The above is the general configuration of the client / server system. Next, a configuration for managing the mutual relationship between the widgets, which is a feature of the present invention, will be described.

Widgets have program parameters that define the form (size, color, shape, etc.) and behavior.
This parameter is called a resource. When the window manager 12 receives a widget generation request from the application program 11, the window manager 12 generates a widget based on this resource (particularly, a resource regarding the form).

With such a configuration, the form of the widget can be easily and freely changed by changing the content of the resource.

This embodiment pays attention to this point, and in addition to the resource (hereinafter, referred to as "morphological resource") that defines the form and operation of each widget, a plurality of widgets whose construction processes are mutually related A resource (hereinafter, referred to as "mutual relation resource") that defines a relation is prepared, and a construction process of a plurality of widgets is executed based on the mutual relation resource.

This execution is performed by the window manager 12. Therefore, the window manager 12 of this embodiment is provided with a function of executing a construction process of a plurality of widgets that are related to each other, in addition to the window opening / closing function described above.

The resource file 40 is used to provide the interrelated resources to the window manager 12. Therefore, the window manager 12 of this embodiment is provided with the function of reading the interrelated resources from the resource file 40.

FIG. 2 is a diagram showing an example of mutual relation resources. In addition, in FIG. 2, in order to make the contents of each interrelationship resource easy to understand, their names are expressed in Japanese rather than in the actual naming system.

Among these plural inter-related resources, for example, "overlap priority" is a resource indicating the display priority of a certain widget when a plurality of widgets overlap each other. When using this interrelationship resource to represent that the priority of widget 1 is 1, for example,
It is expressed as "Widget 1. Overlapping priority: 1".

"Delete on display" is a resource indicating a list of widgets to be deleted when a certain widget is displayed. When using this interrelationship resource to represent the relationship of “delete widget 2 when displaying widget 1,” for example,
It is displayed as "Widget 1. Deleted when displayed: Widget 2."

Although detailed description is omitted, the other inter-relationship resources shown in FIG. 2 can be considered in the same manner as the above-mentioned inter-relational resource “delete when displayed”.

FIG. 3 is a diagram showing an example of the configuration of the resource file 40. The illustrated resource file 40 is used for both registration of mutual relation resources and registration of form resources. In this case, the resource file 40
Has two areas and holds the correlation resource and the morphology resource separately.

The above is the conceptual configuration of this embodiment.
Next, the hardware configuration of this embodiment will be described with reference to FIG.

FIG. 4 is a block diagram showing an example of the hardware configuration of this embodiment. As shown in the figure, the hardware configuration of this embodiment is almost the same as the hardware configuration of a normal computer.

That is, in FIG. 4, 34 is an application program 11 and a window manager 1.
2, a central processing unit (hereinafter referred to as "CPU") for executing various programs such as the X server 20. Therefore, the processing characteristic of this embodiment is executed by the CPU 34.

Reference numeral 35 is a memory used for storing programs executed by the CPU 34 and various data. Therefore, the program defining the processing that characterizes this embodiment is stored in this memory 35.

Reference numeral 36 is a disk in which the above-mentioned resource file 40 and the like are set. Therefore, the inter-relational resource that characterizes this embodiment is registered in this disk 36.

In the above configuration, the operation of executing the construction process of a plurality of widgets based on the interrelated resources will be described.

FIG. 5 is a flowchart showing the processing of the application program 11 in this case. In addition,
In FIG. 5, for simplification of explanation, only the processing of the part related to the widget is briefly shown. Further, in FIG. 5, when an event occurs, an execution request for the construction process is always given to the window manager 12.

In the process of the application program 11, first, a process of requesting the window manager 12 to generate a widget is performed (step S11). This allows the window manager 1
In 2, the requested widget is generated as described later. That is, the image data for displaying the requested widget is generated.

Thereafter, a process for determining whether or not an event has occurred is performed (step S12). This is done by determining whether or not a report that an event has occurred is received from the server 20 via the window manager 12.

If no event has occurred, the process of monitoring the occurrence of the event is continued. In contrast,
When an event occurs, a process of decoding the content of the occurred event is performed (step S13). This decoding determines the widget construction processing (display, deletion, deletion) that should be requested to the window manager 12.

When this decoding is completed, a process of requesting the window manager 12 for the construction process determined thereby is performed (step S14). As a result, the window manager 12, based on the interrelationship resource related to the requested construction process, will be described later.
The process of building multiple widgets is executed.

When this process ends, the process returns to step S12. As a result, the processing described above is performed again when an event occurs. Similarly, the processing described above is repeated every time an event occurs.

FIG. 6 is a flowchart showing the processing of the window manager 12. In FIG. 6 as well, for simplification of the explanation, only the processing part relating to the widget is briefly shown. Further, when an event occurs, the execution request for the construction process is always received from the application program 11.

In the process of the window manager 12, first, a process of generating the widget requested by the application program 11 is performed (step S21). This generation is performed based on the form resource registered in the resource file 40. The generated widget, that is, the image data for displaying the widget symbol is stored in, for example, the memory 35 until a deletion request is received.

When this process ends, a process for determining whether an event has occurred is performed (step S2).
2). This determination is made by determining whether or not a report that an event has occurred is received from the server 20.

When an event occurs, a process of reporting the event to the application program 11 is performed (step S23). Then, the process of step S24 is performed. On the other hand, if the event does not occur,
The process of step S24 is performed as it is.

In step S24, it is determined whether or not a request for executing the widget construction process has been received from the application program 11. When this request is received, the process of step S25 is performed. On the other hand, if the request is not received, the process returns to step S22, and steps S22 and S are performed until the request is received.
The processing of 24 is repeated.

In step S25, a process for reading the interrelated resource from the resource file 40 is performed. In this case, only the resources related to the construction process requested by the application program 11 are read out as the interrelated resources.

For example, when the requested construction process is the deletion of the widget 1, only the resource related to the deletion of the widget 1 is read. This is to shorten the resource read time.

That is, when reading the interrelated resource from the resource file 40, it is not the resource related to the requested construction process (in the above example, deletion of the widget 1), but the widget for which this construction process is requested ( In the above example, it is conceivable to read out the resource associated with widget 1).

However, when the resource related to the widget is read out, the resource read time is often long because the resource is generally larger than the resource related to the construction process.

Therefore, in this embodiment, the read time is shortened by reading only the resources related to the construction process. Note that this will be described in detail later using a specific example.

When the reading of the interrelated resources is completed,
A process of selecting a resource related to the current display state of the screen from the read mutual relation resources is performed (step S26).

For example, when a resource "widget 1. Deleted when displayed: widget 2" is read from the resource file 40, this resource is selected only when the widget 2 is displayed on the screen. Note that this will also be described later in detail using a specific example.

When the selection of the interrelationship resource is completed, a process for executing a process for constructing a plurality of widgets is performed based on the selected interrelationship resource (step S).
27). For example, when the resource “widget 1. Deleted when displayed: Widget 2” is read as the inter-related resource, the widget 1 is displayed and the widget 2 is deleted.

When this process ends, the process returns to step S22. As a result, when the event occurs,
The processing described above is executed. Hereinafter, similarly, each time an event occurs, the above processing is repeated.

The display position of the widget is determined based on a predetermined rule. Further, the widget construction process is actually executed by the server 20 based on the request from the window manager 12 as described above.

Here, the processing of steps S25 and S26 in FIG. 6 will be described using a concrete example with reference to FIGS.

In the following description, the case where the widget is a dialog will be described as a representative example. Here, the dialog can be simply considered as a rectangular graphic component forming the body of the window.

FIG. 7 is a diagram showing an example of the resources registered in the resource file 40 and related to the management of the mutual relation of a plurality of dialogs.

In the figure, six resources except
,,,, are interrelationship resources that define the interrelationships of multiple dialogs. On the other hand, is
It is a resource for registering post-processing function as a callback. This resource is already available from the above-mentioned Mot.
It is provided by tool kits such as if.

Here, the callback is a function that is called when an event occurs in the widget. This callback is used by the window manager 1 when the widget is created (when the symbol image data is created).
2 is registered in the resource file 40.

By registering such resources in the resource file 40, post-processing is automatically performed. This makes it possible to separate and consider the interrelationships of multiple dialogs and the post processing that accompanies them.
The load when creating the window manager 12 can be reduced.

Each resource will be briefly described.
Is a resource indicating the overlapping priority of the dialogs 1, 2, and 3. Is a resource indicating a list of dialogs deleted by displaying the dialog 1. Is
It is a resource showing a list of dialogs displayed by deleting dialog 1. Is a resource indicating a list of dialogs that are deleted by displaying the dialog 6. Is a resource indicating a post-processing function when the dialog 1 is deleted.

FIG. 8 is a diagram for explaining a process (first specific example) based on resources ,.

Now, assume that only the dialogs 2 and 3 are displayed on the screen of the display 31, as shown in FIG. In this case, since the dialog 2 has a higher priority than the dialog 3, the dialog 2 is displayed over the dialog 3.

In this state, when a request for displaying the dialog 1 is sent from the application program 11, the resource is read from the resource file 40.

That is, the dialog 1 requested to be displayed
Resources related to are: ,,,.
However, of these four resources,
Resources related to the dialog 1 display request are:
There are two. Therefore, in this case, only these two resources are read.

The resource read out is appropriately selected according to the current display status of the screen. In the present example, the dialogs 2 and 3 are currently displayed on the screen, and the dialog 4 is not currently displayed. Therefore, in this case, the resource is selected and the resource is not selected. As a result, the dialog 1 is displayed over the dialog 2 as shown in FIG.

FIG. 9 is a diagram for explaining the resource-based processing (second specific example).

Now, as shown in FIG. 9A, it is assumed that a request for displaying the dialog 1 is sent from the application program 11 while the dialog 4 is being displayed. In this case, the resource is read from the resource file 40 as described above.

However, at present, only the dialog 4 is displayed on the screen. Therefore, in this case, of the two read resources, only the resource is selected and the resource is not selected. As a result,
As shown in (b), the dialog 1 is displayed and the dialog 4 is deleted.

FIG. 10 shows resource-based processing (third part).
FIG. 6 is a diagram for explaining a specific example of FIG.

Now, as shown in FIG. 10A, it is assumed that a request for deleting the dialog 1 has been sent while the dialog 1 is being displayed. In this case, the only resource associated with this request is
Only this resource is read. As a result, FIG.
As shown in (b), the dialog 1 is deleted and the dialog 5 is displayed.

FIG. 11 is a diagram for explaining the processing based on the resource (fourth specific example).

Now, as shown in FIG. 11A, it is assumed that the display request for the dialog 6 is sent while the dialog 1 is being displayed. In this case, this resource is read because the resource associated with this request is.

This resource is a resource for instructing deletion of the dialog 1 when the dialog 6 is displayed. Resources are provided in the resource file 40 as resources related to the deletion of the dialog 1.
Therefore, in this case, in addition to the resource, the resource is also read.

As a result, as shown in FIG. 11B, the dialog 6 is displayed and the dialog 1 is deleted based on the resources. At this time, post-processing for deleting the dialog 1 is automatically performed based on the resource.

(1) According to this embodiment described in detail above,
Since the resource that defines the mutual relation of multiple widgets related to each other by the construction process is prepared and the construction process of multiple widgets is executed based on this mutual relation resource, the following effects can be obtained. To be

Since it is not necessary to define the interrelationship of a plurality of widgets by coding the application program, it is possible to reduce the man-hours required for developing the GUI at the time of developing the application program, and to cope with GUI specification changes and bugs. The number of steps required can be shortened.

Since it is easier to understand the mutual relationship between a plurality of widgets as compared with the related art, it is possible to prevent a bug on the GUI (such as a deadlock on the screen) from occurring.

By changing the mutual relation resource, the mutual relation of a plurality of widgets can be changed, so that a complicated mutual relation can be defined easily and freely.

Thus, for example, when a plurality of dialogs are divided into groups and a deletion request for any one of the plurality of dialogs belonging to a certain group is received,
Easily define relationships such as deleting all dialogs belonging to that group, and setting dialogs that are displayed on the screen or hidden dialogs only while a specific dialog is displayed. be able to.

(2) Further, according to this embodiment, since the mutual relation resource is provided to the window manager 12 by using the resource file 40 similarly to the form resource, the providing means is newly constructed. It is possible to provide using the form resource providing means without doing so.

(3) Further, according to this embodiment, when the interrelated resource is read from the resource file 40,
Since not all the resources related to the widget for which the construction process execution request has been made, but only the resources related to the construction process that has been requested are read, the resource read time can be shortened.

(4) Furthermore, according to this embodiment,
In the resource file 40, not only the mutual relation resource but also the resource for registering the post-processing function as a callback is registered, so that the mutual relation of the widget and the post-processing associated therewith can be considered separately. As a result, the burden of creating the window manager 12 can be reduced.

FIG. 12 is a block diagram showing the configuration of the second embodiment of the present invention.

In the above embodiment, the window manager 1
Resource file 40 whose stored content is read by 2
A window manager for interrelated resources using
The case where it is provided to 2 was explained.

On the other hand, in this embodiment, the application program supplies the interrelation resource to the window manager by using the message for transmitting the construction process execution request to the window manager. is there.

FIG. 12 is a block diagram showing a conceptual configuration in this case. 12, the same parts as those in FIG. 1 are designated by the same reference numerals, and detailed description thereof will be omitted.

In FIG. 12, 16 is an application program of this embodiment, and 17 is also a window manager.

The application program 16 of this embodiment is the application program 11 of the previous embodiment.
Unlike the above, it has a function of providing the window manager 17 with the interrelated resource using the request message. For this reason, the window management 17 of this embodiment is not provided with the function of reading the interrelated resources from the resource file 40.

FIG. 13 shows the application program 1
It is a flowchart which shows the process of 6. In FIG. 13, the same parts as those in FIG. 5 are designated by the same reference numerals, and detailed description thereof will be omitted.

In FIG. 13, the point different from FIG. 4 is that, after the event decoding processing step S13, the step S16 of reading the interrelated resource from the resource file 40.
Is provided.

Also, in step S17, the window manager 12 is requested to execute widget construction processing.
In FIG. 14, as shown in FIG. 14, a mutual relation resource is inserted in the parameter part of the request message.

Also in this embodiment, the reading of the interrelationship resource is performed only for the resource related to the construction processing determined by decoding the event. The resources to be inserted in the message also include the resources for registering the post-processing function as described above.

FIG. 15 is a flow chart showing the processing of the window manager 17. In FIG. 15, the same parts as those in FIG. 6 are designated by the same reference numerals, and detailed description thereof will be omitted.

The difference between FIG. 15 and FIG. 6 is that
Step S25 of reading out the interrelated resource in FIG.
Is omitted. This is, in this example,
This is because the interrelationship resource is given from the application program 16 as described above.

In the above configuration, when the application program 16 issues a request to execute the widget construction process, first, a process is performed to read out the interrelated resource related to the construction process from the resource file 40 (step S16). After that, a process of supplying a request message including the read mutual relation resource to the window manager 17 is performed (step S17).

As a result, the window manager 17 performs a process of selecting a resource related to the current display state of the screen from the sent interrelated resources (step S26). After that, based on this selected resource, a process of constructing a plurality of widgets is executed.

In this embodiment described in detail above, the same effects as those of the previous embodiment can be obtained, and further, the following effects can be obtained.

That is, in this embodiment, since the interrelationship resource is provided by using the request message, the window manager 17 should immediately start the execution of the construction process upon receiving the construction process execution request. You can

Although two embodiments of the present invention have been described above, the present invention is not limited to the above-mentioned embodiments.

(1) For example, in the above-mentioned second embodiment, the case where the mutual relation resource is read from the resource file 40 has been described. However, in this embodiment, this resource may be set as data on the application program.

Even with such a configuration, when the mutual relationship is changed, only the data written in the program need be changed, so that the change is easier than the case where the coding of the program is changed.

(2) Further, in the first and second embodiments described above,
The case where the present invention is applied to the X window system has been described. However, the present invention can be applied to systems other than the X window system as long as the system has a GUI.

That is, if the system has a GUI, a window system other than the multi-window system such as the X window system,
It can be applied to systems other than the window system.

(3) In addition to the above, the present invention can of course be variously modified without departing from the scope of the invention.

[0116]

As described above in detail, according to the present invention,
A resource that defines the mutual relationship between a plurality of graphic components related to each other by the construction process is prepared, and the construction process of the plurality of graphic components is executed based on this mutual relation resource. It is possible to provide a graphic component management device capable of solving a problem when defining a mutual relationship.

[Brief description of drawings]

FIG. 1 is a block diagram showing a conceptual configuration of a first embodiment of the present invention.

FIG. 2 is a diagram showing an example of a mutual relation resource according to the first embodiment.

FIG. 3 is a diagram showing an example of a configuration of a resource file according to the first embodiment.

FIG. 4 is a diagram showing a hardware configuration of a first embodiment.

FIG. 5 is a flowchart showing processing of an application program of the first embodiment.

FIG. 6 is a flowchart showing a process of a window manager according to the first embodiment.

FIG. 7 is a diagram showing a specific example of a mutual relation resource according to the first embodiment.

FIG. 8 is a diagram for explaining a first specific example of the process of the first embodiment.

FIG. 9 is a diagram for explaining a second specific example of the processing of the first embodiment.

FIG. 10 is a diagram for explaining a third specific example of the processing according to the first embodiment.

FIG. 11 is a diagram for explaining a fourth specific example of the processing according to the first embodiment.

FIG. 12 is a block diagram showing a conceptual configuration of a second embodiment of the present invention.

FIG. 13 is a flowchart showing the processing of an application program of the second embodiment.

FIG. 14 is a diagram showing a structure of a request message according to a second embodiment.

FIG. 15 is a flowchart showing the processing of the window manager of the second embodiment.

[Explanation of symbols]

 10 ... Client 20 ... Server 30 ... Hardware section 40 ... Resource file 11, 16 ... Application program 12, 17 ... Window manager 31 ... Display 32 ... Mouse 33 ... Keyboard 34 ... CPU 35 ... Memory 36 ... Disk

Claims (7)

[Claims] 1. A graphic component management apparatus for managing a mutual relation of a plurality of graphic components related to each other by a process for constructing a graphical user interface, the mutual relation defining the mutual relation of the plurality of graphic components. Mutual relationship regulation information providing means for providing regulation information, and, upon receiving the execution request of the processing, executes processing of the plurality of graphic parts based on the mutual relationship regulation information provided by the mutual relationship regulation information providing means. And a processing execution means for performing the processing. 2. The graphic component management apparatus according to claim 1, wherein the mutual relation defining information providing unit is an information storing unit whose storage content is read by the process executing unit. 3. The processing execution means reads information from the information storage means only mutual relationship defining information related to the processing requested by the execution request, and the mutual relationship read by the information reading means. Information selecting means for selecting only mutual relationship defining information related to the current screen display state from the defining information, and the plurality of graphic parts based on the mutual relationship defining information selected by the information selecting means. 3. The graphic component management device according to claim 2, further comprising an execution unit that executes a process. 4. When the execution request for the processing is generated, the mutual relationship defining information providing means uses the message for transmitting the request to the processing executing means, and sends the mutual relationship defining information to the processing executing means. The graphic component management device according to claim 1, wherein the graphic component management device is configured to supply the graphic component. 5. The mutual relationship defining information providing means, an information storing means for storing the mutual relationship defining information, and an information reading operation for reading the mutual relationship defining information from the information storing means when an execution request for the process is issued. 5. A means and an information supplying means for supplying the mutual relation defining information read by the information reading means to the processing executing means by using the message.
Graphic component management device described. 6. The information providing unit is configured to supply only the interrelationship defining information related to the process requested by the execution request to the process executing unit. Graphic component management device. 7. The information selecting means, wherein the processing executing means selects only the mutual relationship defining information related to the current display state of the screen from the mutual relationship defining information supplied by the mutual relationship defining information providing means. 7. The graphic component management apparatus according to claim 6, further comprising: an execution unit that executes processing of the plurality of graphic components based on the mutual relationship defining information selected by the information selection unit.