diff options
| -rw-r--r-- | doc/info/mds.texinfo | 37 |
1 files changed, 37 insertions, 0 deletions
diff --git a/doc/info/mds.texinfo b/doc/info/mds.texinfo index 5c794d2..accca38 100644 --- a/doc/info/mds.texinfo +++ b/doc/info/mds.texinfo @@ -53,6 +53,7 @@ Texts. A copy of the license is included in the section entitled @menu * Overview:: Brief overview of @command{mds}. * Architecture:: Architectural overview of @command{mds}. +* Application Design:: Guildlines for your applications. * Protocol:: The @command{mds} procotol. * Utilities:: About @command{mds} utilities. * Servers:: About @command{mds} servers. @@ -295,6 +296,42 @@ and wait for a reply from all of them. +@node Application Design +@chapter Application Design + +When creating graphical @command{mds} applications, +where are some guildlines you should follow. + +@itemize @bullet +@item +@b{Do not create client side decoration}. Some +users do not want decorations or wants minimal +decorations. Windows should look similar, server +side decoration helps ensure this. Your client side +decorations may not meet the requirements the users +have. For example, your client side decoration may +only support minimise, maximise and close, whilst the +user may also want, as provided by her decoration +server, stick, shade and always on top. And it should +be sufficient to configure your decorations once +rather once for every toolkit. Additionally, because +of oversight from developers, client side decoration +tends to work poorly with tiling window managers. + +@item +@b{Do not remember size and position}. Some users +do not want their programs to remember their size +and position. There is also a risk that your +mechanism for implementing this does not account +for the possibility that outputs may have been +removed, resized or relocated. The +@command{mds-posmem} be used if the user wants +programs to start where they were closed the last +time they were closed. +@end itemize + + + @node Protocol @chapter Protocol |