Le kit d'interface

La plupart des applications ont une interface graphique interactive. Quand une application demarre, elle affiche des fenetres dans lesquels l'utilisateur peut cliquer et entrer des elements au clavier. L'application reponds au actions de l'utilisateur et mets a jour ses fenetres.

Pour avoir ce genre d'interface, une application doit:

• Gerer des fenetres

• Dessiner dans les fenetres

• Repondre au actions de l'utilisateur (cf imessages d'interface)

Le kit definit un groupe de classe en C++, fournissant une structure pour ces operations. Ce premier chapitre presente la structure conceptuelle associee a l'interface utilisateur, puis decrit toutes les classes, fonctions, types et constantes du kit.

Stucture d'une Interface Utilisateur

Une interface graphique s'organise autours de fentres. Dans un environnement multi-tache, un grand nombre d'applications peut tourner en meme temps, chacune avec ses propres fenetres a l'ecran. Toutes les fentres doivent pouvoir cooperer dans une interface commune. Le serveur d'application gere tout cela:

• Il surveille le clavier et la souris, et envoie les messages correspondants a l'application (touche pressee, deplacement de la souris... ).

• Il recoit les intructions de dessins provenants de l'application et les interprete pour dessiner a l'interieur des fenetres

Les objets BWindow

Chaque fenetre est represente dans une application par un objet BWindow. La construction d'une BWindow etablit une connection au serveur d'application. Lorsque vous appelez une fonction de manipulation de fenetre (tels que Show(), MoveTo(), SetTitle()...), l'objet envoie un message au serveur qui accomplit la manipulation.

La classe BWindow herite de BLooper. Chaque objet BWindowest associe a un thread qui recoit et reponds a des messages provenants du serveur.

Tous les autres objets du kit d'interface dependent d'une BWindow. Ils dessinent dans une fenetre, repondent aux messages recus par une fenetre, contribuent aux dessins et aux reponses aux messages.

Les objets BView

Une fenetre est divisee en zones rectangulaires plus petites appelee vues (views). Chaque vue correspond a une partie de l'affichage de la fenetre (barre de defilement, liste ...).

Une application mets en place une vue en construisant un objet BView et en l'associant a une BWindow particuliere. L'objet BView est responsable du dessin dans le rectangle definissant la vue et de la gestion des messages d'interface a l'interieur de celle ci.

Dessiner dans une vue

A window can retain and display rendered images, but it can't draw them; for that it needs a set of BViews. A BView is an agent for drawing, but it can't render the images it creates; for that it needs a BWindow. The two objects work hand in hand.

Each BView object is an autonomous graphics environment for drawing: It has its own coordinate system, current colors, drawing mode, clipping region, font, pen position, and so on. The BView class also defines functions that represent elemental drawing operations such as line stroking, character drawing, and image blitting.

Handling Messages in a View

When the user acts, system messages that report the resulting events are sent to the BWindow object, which determines which BView elicited the user action and should respond to it. For example, a BView that draws typed text can expect to respond to messages reporting the user's keystrokes. A BView that draws a button gets to handle the messages that are generated when the button is clicked. The BView class derives from BHandler, so BView objects are eligible to handle messages dispatched by the BWindow.

The View Hierarchy

A window typically contains a number of different views—all arranged in a hierarchy beneath the top view, a view that's exactly the same size as the content area of the window. The top view is a companion of the window; it's created by the BWindow object when the BWindow is constructed. When the window is resized, the top view is resized to match. Unlike other views, the top view doesn't draw or respond to messages; it serves merely to connect the window to the views that the application creates and places in the hierarchy.

The view hierarchy can be represented as a branching tree structure with the top view at its root. All views in the hierarchy (except the top view) have one, and only one, parent view. Each view (including the top view) can have any number of child views.

When a new BView object is created, it isn't attached to a window and it has no parent. It's added to a window by making it a child of a view already in the view hierarchy. This is done with the AddChild() function. A view can be made a child of the window's top view by calling BWindow's version of AddChild().

Until it's assigned to a window, a BView can't draw and won't receive reports of events. BViews know how to produce images, but it takes a window to display and retain the images they create.

Drawing and Message Handling in the View Hierarchy

The view hierarchy determines what's displayed where on-screen, and also how user actions are associated with the responsible BView object:

• When the views in a window are called on to draw, parents draw before their children; children draw in front of their ancestors.

• Mouse events are associated with the view where the cursor is located.

Overlapping Siblings

Siblings don't draw in a predefined order. If they overlap, it's indeterminate which view will draw last—that is, which one will draw in front of the others. Similarly, it's indeterminate which view will receive the mouse events that occur in the area the siblings share.

Therefore, it's strongly recommended that you arrange your sibling views so they don't overlap.