diff options
| -rw-r--r-- | doc/README.md | 28 |
1 files changed, 14 insertions, 14 deletions
diff --git a/doc/README.md b/doc/README.md index 090b1ae..e2b8fa4 100644 --- a/doc/README.md +++ b/doc/README.md @@ -74,8 +74,8 @@ further customize layer and orientation of surfaces. These have **no** particular meaning, except that it hints the compositor where they should be stacked or where to position them. The background one occupies -the most lower layer, the desktop ones on top and the panel surfaces the upper -most layer. +the lowest layer, with the desktop role ones on top of it, and the panel role +surfaces on the uppermost layer. Additional roles have been added, in a different extension, to add further functionality with the control/security functions being transferred over to a @@ -86,8 +86,8 @@ further details. Clients can make use of this protocol to define different kind of roles for different kind of surfaces. This defines panels and a background surface. It -includes to ability to activate other applications, assuming that those are -already running. Activation happens by using using the app_id, respectively +includes the ability to activate other applications, assuming that those are +already running. Activation happens by using the app_id, respectively using set_app_id request as defined by the XDG shell protocol. Established client-side implementation of the XDG shell protocol will have a function used to set it up, or it should provide or expose an API to do so. @@ -99,7 +99,7 @@ for the client shell to activate them. This extension is targeted at keeping some of the functionally already established in AGL a) to allow applications display/activate other -surfaces/application window, and b) to set further roles, specially dialog +surfaces/application window, and b) to set further roles, such as dialog pop-ups and split-type of surfaces. Clients can make use of this protocol to set further roles, like independently @@ -117,7 +117,7 @@ roles, and with this extension we add some further roles. These are: split these are encoded with different values such that there's a translation needed, between the protocol values and the internal values. -Besides the roles, additional data can to be passed, but only relevant +Besides the roles, additional data can be passed, but only relevant depending on the role. #### Receiving application state events from (other) applications @@ -132,13 +132,13 @@ needed. Both agl-shell and agl-shell-desktop have requests to activate other application based on their XDG shell app_id. In case the application is -present/running it it will attempt to make the surface backing that application -the current activate one, with each output having independently active +present/running, it will attempt to make the surface backing that application +the current active one, with each output having independent active surfaces. ### Explicit output -The activation and setting surface roles requires passing an output +Activation and setting of surface roles requires passing an output (wl_output). The output is the wayland interface representation of an output and is **mandatory**. Clients can retrieve it (the output) if they wish to place the surface on other outputs by using the toolkits exposing wayland @@ -152,7 +152,7 @@ Both protocols assume immediate, synchronous behaviour and to some extent lack some error handling functionality. Role assignment to surfaces could probably be improved with an additional -interface with can add further data, if that roles assumes that to be true. +interface that could add further data, if a role requires it. There seems to be some overlapping functionality with respect to activating applications, so a potential improvement would be that the agl-shell protocol @@ -174,12 +174,12 @@ issue: $ meson -Dprefix=/path/to/where/to/install/compositor -Dpolicy-default=deny-all build_directory -Users wanting to create their own policy engine should create a specialized +Users wanting to create their own policy engine should create a specialized version and use `struct ivi_policy_api` where they can install their own callbacks. The default policy found in src/policy-default.c should more than sufficient to -get started. Users can either re-puporse the default policy or create a new one +get started. Users can either re-purpose the default policy or create a new one entirely different, based on their needs. ### Hooks @@ -209,8 +209,8 @@ or hiding the application specified in the policy rule. #### Default events and states -By default the when creating the policy framework it will add the 'show', and -'hide' events and the 'start', 'stop' and 'reverse' states. An special type, +By default, when creating the policy framework it will add the 'show', and +'hide' events and the 'start', 'stop' and 'reverse' states. A special type, assigned by default is 'invalid'. #### State changes |