Apress Pro PHP-GTK phần 7 docx

218 CHAPTER 9 ■ WORKING WITH TREES AND LISTS

// Get the singleton product summary.

require_once 'Crisscott/Tools/ProductSummary.php';

$productSummary = Crisscott_Tools_ProductSummary::singleton();

$productSummary->displaySummary($product);

}

public static function singleton()

{

if (!isset(self::$instance)) {

$class = __CLASS__;

self::$instance = new $class;

}

return self::$instance;

}

}

?>

Summary

Trees and lists by themselves are relatively simple objects for modeling, rather than complex

data structures. A tree or list can take a collection of data and make it easy to navigate and

access individual elements. The organized nature of these models allows them to be used in

a myriad of ways when combined with GtkTreeView and its associated objects. The specializa￾tion and abstraction of responsibility of these classes make for a very powerful tool set that

can provide almost endless flexibility when it comes to how a model should be displayed and

accessed.

Now that you have seen how to work with large collections of data, you’ll want to know

how to display all of that data in a small space. Chapter 10 discusses how to make a section of

an application scroll so that the user can access data that cannot fit in the space given for a tool.

No longer will the sections of the application be restricted by the size of a container or the user’s

screen. An endless amount of space will be made available for any piece of the application that

needs it by providing scrollbars for both the horizontal and vertical axes.

6137ch09.qxd 3/14/06 2:14 PM Page 218

219

CHAPTER 10

■ ■ ■

Scrolling

At this point, the Crisscott PIMS application has several tools that may contain large amounts

of data. Unfortunately, none of them currently provides a graceful way to handle this data when

it exceeds the boundaries of the tool. For instance, if the data contained within the product tree

exceeds the space provided by the tree, rows and characters just get pushed out of the visible

area. Other tools may stretch to accommodate the oversized data. While this approach doesn’t

hide data from the user, it can interfere with the layout of the rest of the application, which may

be more damaging than hiding values. A better solution enables a tool to extend its data beyond

its visible borders, but remain accessible to the users. This is the role of scrolling widgets.

GtkScrolledWindow and GtkViewPort are widgets specifically designed to make data accessi￾ble even though it has outgrown its available space within the application. These two widgets

provide a means to access data in another widget that is not currently within the widget’s visi￾ble area. Additionally, you can customize scrolling for a particular widget.

Throughout this chapter, we will examine ways to use scrolling to make better use of the

space available in the PIMS application.

Scrolled Windows

Some widgets have been designed with scrolling in mind. These widgets, including GtkTreeView

and GtkTextView, will likely display large amounts of data. For example, a tree or list could show

many rows from a database. A GtkTextView widget may display a lengthy press release or report.

In order to make either of those documents fit on one screen, the font would have to be very

small, likely rendering the document unreadable. Instead of asking developers to squeeze data

into a restricted space, the designers of these widgets have given them native scrolling support.

Native scrolling support means that the widgets can accept scrollbars and will allow the

scrollbars to control which part of the widget is shown in the visible area. GtkScrolledWindow

provides the scrollbars that these widgets need.

GtkScrolledWindow is a bin container, a descendant of GtkBin. The scrollbars that it provides

make it easier for users to access different parts of the child widget.

For instance, consider Figure 10-1, which depicts the product tree without scrollbars. It is

impossible to see all the rows of the tree at once, and there is nothing to indicate to the user

that the contents of the view are scrollable.

6137ch10.qxd 3/14/06 2:16 PM Page 219

220 CHAPTER 10 ■ SCROLLING

Figure 10-1. A GtkTreeView without scrollbars

Figure 10-2. A GtkTreeView with scrollbars

On the other hand, Figure 10-2 displays the product tree after it has been added to

a GtkScrolledWindow. While this doesn’t make it possible to see all the rows at once (actually,

the scrollbars take up space, making even less information visible), it does make it clear that

the contents of the window can be scrolled.

Adding scrollbars to those widgets that have native scrollbar support is relatively easy.

Listing 10-1 presents an excerpt from an updated version of the Crisscott_MainWindow class.

In previous iterations of this class, the Crisscott_Tools_ProductTree instance was attached

directly to the table. In this example, the instance is added to a GtkScrolledWindow, which is

then attached to the table.

Listing 10-1. Adding Scrollbars to a GtkTreeView

<?php

// ...

// Get a singleton instance of the product tree.

require_once 'Crisscott/Tools/ProductTree.php';

$productTree = Crisscott_Tools_ProductTree::singleton();

6137ch10.qxd 3/14/06 2:16 PM Page 220

CHAPTER 10 ■ SCROLLING 221

// Create a scrolled window for the product tree.

$scrolledWindow = new GtkScrolledWindow();

// Set the size of the scrolled window.

$scrolledWindow->set_size_request(150, 150);

// Set the scrollbar policy.

$scrolledWindow->set_policy(Gtk::POLICY_NEVER, Gtk::POLICY_AUTOMATIC);

// Add the product tree to the scrolled window.

$scrolledWindow->add($productTree);

// Attach the scrolled window to the tree.

$table->attach($scrolledWindow, 0, 1, 2, 3, 0, $expandFill, 0, 0);

// ...

?>

Notice that the scrolled window, rather than the product tree instance, is sized. This is

because the scrollbars are added to the outside of the scrolled window’s child widget. If the

product tree were sized to 150 pixels wide and then added to the scrolled window, the layout

of the application would be distorted.

In the simplest scrolling use case, adding the child is all that needs to be done. But, as you

can see in Listing 10-1, some customizations may be made.

Setting the Scrollbar Policy

One of the most common customizations for a GtkScrolledWindow is setting the scrollbar policy.

The scrollbar policy determines when scrollbars will appear in the scrolled window. The default

is to always show both the horizontal and vertical scrollbars, but this can be changed.

Three policy rules can be applied to horizontal and vertical scrollbars individually:

• Gtk::POLICY_ALWAYS: The scrollbar should be shown, regardless of whether or not there

is enough information to scroll in the given direction.

• Gtk::POLICY_AUTOMATIC: The scrolled window shows the scrollbar only when it is needed.

• Gtk::POLICY_NEVER: The scrollbar will never be shown.

You can set the policies for a scrolled window with set_policy. The first argument that

set_policy expects is the policy for the horizontal scrollbar, and the second argument is for

the vertical scrollbar. The code in Listing 10-1 sets the policy for the horizontal scrollbar to

Gtk::POLICY_NEVER, while the vertical scrollbar is set to Gtk::POLICY_AUTOMATIC. The horizontal

scrollbar is not needed because the cell renderer for the tree is told to ellipsize the cell text.

Even if the policy were set to automatic, the scrollbar would never be shown because the child

widget will not expand horizontally.

Not only is it possible to set whether the scrollbars appear in a GtkScrolledWindow, but

you can also control where they appear in relation to the child widget.

6137ch10.qxd 3/14/06 2:16 PM Page 221