|--< intro >--< api >--< overview >--< sourcetool >--| 
 
 
     At this time this package is considered beta yet will be considerably improved to provide developers with the features that they are interested in. With any luck, the FrameManager source tools and examples will be at the upcoming developer conference.
 
 
    The FrameManager package has been designed in the interest of increasing productivity for the BeOS developer. Its primary purpose is to provide an efficient way to implement resizing and positioning behaviors for BView objects. Its resizing code far exceeds Be's current positioning system and allows for complex dynamic positioning for components such as tab views and splitters for view resizement. This lightweight set of classes do not require the use of inheritance and may be incorporated easily into existing projects. 

    In addition to providing a simple set of powerful classes for implementing interfaces, a visual tool for building and testing resizing behaviours is also included. This source tool allows the developer to minimize the amount of time necessary to code the desired dynamic behaviour and to write the configuration to a resource. 

 
 

 
The Classes
 
    The obvious intent for a package such as this is to provide the developer with the most simple solution to the problem. As such you will find that only the use of two primary classes is required:
 

    Some additional classes have been included to either help you get started coding on the BeOS or as examples of more flexible uses of the FrameManager package:
   
What is a Frame?
 
    A frame describes the behaviour of each edge of a rectangular region on the screen. If an edge is supposed to move or stay stationary, it's described by the frame. In general an edge manager uses a frame to move around a view or set of views. Why make this intermediate object? Reusability. If you have a set of hidden views which may occupy a similar space they all can be associated to a single frame. This is the behaviour commonly seen in tab views.
 
How do I make a Frame?
 
    Since every rectangular area has four edges, you can make an instance of a WFrame object and call Set() for each edge. Of course in most cases this results in four function calls for every view so a nicer solution is to use the source tool.
 
    The visual source tool included with this package will allow you to draw the regions on the screen and then define the behaviour by clicking on the edges. Once you have arranged your interface you can test the resizing behaviour to see if it behaves as you predicted. To extend the separation of data and code, the visual tool will write the description to the resource of your application.
 
    Hopefully this will save a lot of developers the trouble of recompiling constantly for simpe UI changes.
 
Isn't this like a layout manager?
 
    If you spend an evening or two jotting down examples of layout and resizing behaviors you'll soon realize that there is no "silver bullet" layout manager. In fact even this package cannot position views in every way conceivable. Remeber that layout managers usually don't attempt to solve all positioning problems, dy definition they have their own style of arrangement.

    The FrameManager package is different. It attempts to solve a much broader solution to the layout problem. In essence it is a superset of most layout managers. One of the goals of  the FrameManager package is to solve problems which developers spend time rewriting from scratch. There's very little reason why anyone should have to rewrite the code which asks one view to be a percentage size of another view, especially if it's publically available.
 
So do layout managers relate at all?
 
    There are many packages to auto arrange your views, but most are just a subset of the FrameManager package. In fact implementing a layout manager on top of this package is very viable and appealing. Layout managers implemented with these classes need only to describe a region's behavior once during an initialization peroid and from that point on their code is out of the way.

    Enevitably a collection of proxy classes which will automate the interface to the WEdgeManager object will be available. These may simulate the same functionality found in the Java AWT or perhaps the packing mechanism found in TCL/TK. Whatever layout manager is desired should be available, written from a common code base and hopefully will come from the development community.
 
How flexible is the layout routine?
 
    Presently there are three major alignment modes each with several positioning arrangements. Many of the features of the package rely directly on use of literal (absolute), percentage and relational positioning. The categories of behavior are defined below:
 
 

 
Alignment
 
 
Positioning
 
 
Description
 
None
None  
The manager makes no attempt to adjust this edge. Adjustments made by the app_server are valid and won't conflict with the manager. 
 
 
Self
Delta Offset
 
  The edge will consistantly remain a fixed distance away from its opposite edge. This behavior is commonly seen in menubars. 
 
 
Parent Container Literal Position  
  The manager will enforce that this edge remain at the literal position specified within the container. 
 
 
 Parent Container
Percentage Position
 
  The manager will compute the percentage location of the edge with regards to the corresponding width or height of the container. 
 
 
 
Sibling View
Adjacent Edge
 
  The edge will remain flush but not overlap with the closest edge of a sibling view. The closest edge for the left side would be the right edge of the given view, the top edge would be closest to the bottom edge of the given view, and so on. 
 
 
 
 Sibling View
Adjacent Edge with Delta
 
  The edge's position will begin flush to the closest edge of the sibling view and then recede a given delta pixels away. useful for maintaining a buffer between two views. (All deltas may be positive or negative.) 
 
 
 Sibling View
Opposite Edge
 
  The edge will be positioned one pixel before the location of the far edge of the given sibling view. 
 
 
 Sibling View
Opposite Edge with Delta
  The edge will be positioned one pixel before the liocation of the far edge and then recede a given delta pixels away. 
 
 
 Sibling View
Percentage Position
 
  The manager will compute a percentage offset into a given sibling view to align the edge at that point. This will permit edges to overlap and occupy the same x or y location for exact alignment.