| // Copyright 2017 The Fuchsia Authors. All rights reserved. |
| // Use of this source code is governed by a BSD-style license that can be |
| // found in the LICENSE file. |
| |
| // This file contains the definition of module container layouts. |
| |
| library fuchsia.modular; |
| |
| // Specification of the layout of multiple surfaces in a module container. The |
| // surfaces are referenced by name in ContainerRelationEntry. |
| struct ContainerLayout { |
| vector<LayoutEntry> surfaces; |
| }; |
| |
| // Specification of the postion of one surface within a container layout, |
| // specified by a rectangle. |
| struct LayoutEntry { |
| // Surface name, referenced by container relation entry. |
| string node_name; |
| |
| // Layout, as rectangle in Dart conventions(left, top, width, height), as a |
| // proportion of the size of the container |
| array<float32>:4 rectangle; |
| }; |
| |
| // Specifies the surface relationship between modules started together in module |
| // container. |
| // |
| // TODO(djmurphy): this allows arbitrary graphs including cyclical ones, which |
| // makes no sense. We could consider a nested data structure that makes cycles |
| // impossible to specify. |
| struct ContainerRelationEntry { |
| // Surface name, referenced by layout. |
| string node_name; |
| |
| // Surface name of the layout parent. This could be the container itself, |
| // rather than a module in it. |
| string parent_node_name; |
| |
| // This surface relation between the surface identified by node_name and by |
| // parent_node_name. |
| // |
| // It is possible to specify a surface relationship of a module in a container |
| // to the container itself, as opposed to another module in the container. |
| // This expresses for example that a module can be dismissed individually, as |
| // opposed to dismissing the module dismisses the container as a whole. |
| // |
| // TODO(djmurphy,mesch): The case above is not really a surface relationship, |
| // because the container is not a surface as such. We could adjust the name |
| // accordingly, or use a different type here. Depends on whether all surface |
| // relationship types make sense between a module and its container or not, |
| // etc. |
| SurfaceRelation relationship; |
| }; |
| |
| // Specifies one module to start inside a container. The module is specified by |
| // a intent as usual. The node_name of the surface is referenced by container |
| // layout and by container relation entry. |
| struct ContainerNode { |
| // Name by which this module is references in layout and surface relationship |
| // specifications (cf. above). |
| string node_name; |
| |
| // The intent to resolve to a module. |
| Intent intent; |
| }; |