|--< intro >--< api >--< overview >--< sourcetool >--| ![]() |
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 |
What is a Frame? |
How do I make a Frame? |
Isn't this like a layout manager? |
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? |
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? |
|
|
|
|
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. ![]() |
|
|
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. ![]() |
|
|
The manager will compute the percentage location of the edge with regards to the corresponding width or height of the container. ![]() |
|
|
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. ![]() |
|
|
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.) ![]() |
|
|
The edge will be positioned one pixel before the location of the far edge of the given sibling view. ![]() |
|
|
The edge will be positioned one pixel before
the liocation of the far edge and then recede a given delta pixels away.
![]() |
|
|
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. ![]() |