| home / programming / mozilla / 2 |    [previous][next] |
|
|
|
The simplest way to specify the content of a title bar is with the window.title property. Whatever it is set to will appear in the main part of the bar. Other elements of the bar are not configurable, although a window based on a <dialog> tag can remove some controls. A window can be opened with no title bar at all, using options to window.open() (see Chapter 10, Windows and Panes, for details).
The Mozilla chrome contains an XBL definition of a <titlebar> tag. It is occasionally used in other XBL definitions, but it has no real status as a XUL tag. It is no more than an <hbox> containing a <label> and an <image>. It is intended to simulate the title bar added to a window by the desktop window manager. It is a building block of the <floatingview> tag described next. Explore its use if you wish.
The <dialogheader> tag has nothing to do with title bars, it is plain content.
window.open(), <dialog>, <dialogheader>, and <page> are described in Chapter 10, Windows and Panes.
The easiest way to display extra content is to use scrollbars, but scrollbars are a simplistic fix. A better solution is to examine the design of your application window. Most windows should have a simple purpose or purposes, and users should not need to do extensive navigation. No one should ever need to scroll down an application window to reveal “extra” form elements. That may be common in Web pages, but in the end it is bad design. Forms should always fit into the initially visible window.
Some applications are desktop-like. Those applications typically have power-users who don’t want dumbed-down design. If simplifying the design fails, then XUL provides splitters and tab boxes to break up the content into bits. Both splitters and tab boxes divide the window content into sections, leaving the user responsible for navigating around those sections by hand. The benefit of such a division is a more sophisticated arrangement of content; the cost is the appearance of extra navigational controls that are peripheral to the core purpose of the application.
Some applications are not desktop-like. For repetitiously used applications, like data-entry screens, splitter and tab box divisions can get in the way of performance. Only use these techniques if you expect that the users will exercise some discretion over what they do with the window or how they arrange it. Don’t use these techniques for hardened applications or pointsolution applications. Don’t use them as a substitute for proper design. It is better to make the application support the true task rather than make a Swiss-army knife flexible enough for any need. That advice doesn’t apply to a competitive sales environment, however. In a sales environment, it’s more important to amaze the audience with nifty features than produce something that is usable and issue-free. That’s life.
If there is a risk that users will have a small screen resolution, then splitters and tab boxes may help. Such a risk should be seen as a high-level design constraint. It should not be addressed by pouring extra splitters and tab boxes into the window.
Chapter 10, Windows and Panes, contains further discussion on managing content too big for a single window. Another XUL technique for multi-panel display is the <wizard> tag, which is described in Chapter 17, Deployment.
8.2.6.1 <splitter> The <splitter> tag acts like a blend of the <button>, <resizer>, and <spacer> tags. The example shown in Figure 8.3 is a little atypical because <splitters> are usually quite narrow so that they take up minimal screen space. One XUL document can contain many <splitter> tags. Splitters are used extensively in Mozilla’s JavaScript Debugger and separate the sidebar from the Web page content in the Navigator window. The purpose of a splitter is to separate content into two panels, one on either side.<> The <splitter> tag usually contains a single <grippy> tag. As noted in Chapter 4, First Widgets and Themes, the <splitter> tag can be dragged or clicked via its <grippy> tag. The <grippy> tag provides a place to store event handlers and styles; that’s all it does. Its use is very simple:
<splitter><grippy/></splitter>
The <grippy> tag can be left out if required.
The <splitter> tag works as follows: It and its sibling tags are contained in some <vbox>, <hbox>, or boxlike tag. When users click and drag on the splitter, the splitter recalculates its position, based on each tiny drag offset. It then orders its sibling tags to squeeze up or stretch out. The splitter itself stays the same size, and in the normal case, the parent <vbox> or <hbox> stays the same size. How the siblings are stretched or squeezed depends on the attributes used for the <splitter> tag. If more than one <splitter> exists inside the parent tag, then each one acts as though the others were just simple content.
The attributes with special meaning to the <splitter> tag are
orient disabled collapse state resizebefore resizeafter fixed
The orient attribute determines if the splitter is vertical or horizontal.disabled set to true stops the splitter from responding to user input. collapse indicates which side of the splitter, before or after, should disappear if the splitter is collapsed. state may be set to open, dragging, or collapsed. open means that content on both sides of the splitter is visible. dragging means that the user is in the middle of a mouse gesture started on the splitter, and collapsed means that content on one side of the splitter is entirely hidden, giving all of the space to the splitter’s other panel.
For splitter collapse to work, the <splitter> must have one sibling tag on the side to be collapsed. The easiest way to do this is to use a <box> on that side. The collapse action occurs only when the state attribute is set, which is done using JavaScript that is part of the <grippy> implementation. Note that state="collapsed" and collapse="…" are different from the standard collapsed="true" attribute usable on all XUL tags. collapsed="true" used on the <splitter> tag will make the splitter itself disappear.
The remaining attributes set the resizing policy for sibling content. If resizebefore or resizeafter is set to farthest, then a shrinking panel will rob space from the sibling most remote from the <splitter> first. If set to closest, then a shrinking panel will rob space from the sibling closest to the <splitter> first. If the panel that is shrinking contains a single <box>, then the content of that box will shrink evenly and ignore the resizebefore or resizeafter hint. resizeafter can also be set to grow. In this last case, the content after the splitter will not shrink when the splitter is dragged toward it. Instead, it will be moved across so that it overflows and is clipped by the containing box or the window boundaries. Setting fixed to true overrides the other settings and prevents the grippy from being dragged. It may still be collapsed.
This set of arrangements means that the state and resizebefore/resizeafter attributes cannot all work at once because they require a different layout for the sibling content. Mixing resize policies with the flex attribute, and window resizing can yield a wide range of slightly different stretching effects.
<splitter> has one variant: It is also responsible for the resizing of columns in a <tree> tag. In that case, it has class="tree-splitter" and has no visible appearance. See Chapter 13, Listboxes and Trees.
| home / programming / mozilla / 2 | [previous][next] |
Legal Notices, Licensing, Reprints, Permissions, Privacy Policy.
Advertise | Newsletters | Shopping | E-mail Offers | Freelance Jobs 
Created: March 27, 2003
Revised: December 19, 2003
URL: http://webreference.com/programming/mozilla/2
