1 /* ScummVM - Graphic Adventure Engine 2 * 3 * ScummVM is the legal property of its developers, whose names 4 * are too numerous to list here. Please refer to the COPYRIGHT 5 * file distributed with this source distribution. 6 * 7 * This program is free software; you can redistribute it and/or 8 * modify it under the terms of the GNU General Public License 9 * as published by the Free Software Foundation; either version 2 10 * of the License, or (at your option) any later version. 11 * 12 * This program is distributed in the hope that it will be useful, 13 * but WITHOUT ANY WARRANTY; without even the implied warranty of 14 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the 15 * GNU General Public License for more details. 16 * 17 * You should have received a copy of the GNU General Public License 18 * along with this program; if not, write to the Free Software 19 * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. 20 * 21 */ 22 23 /* TADS OS interface file type definitions 24 * 25 * Defines certain datatypes used in the TADS operating system interface 26 */ 27 28 #ifndef GLK_TADS_OS_BANNERS 29 #define GLK_TADS_OS_BANNERS 30 31 #include "common/scummsys.h" 32 #include "glk/tads/os_glk.h" 33 34 namespace Glk { 35 namespace TADS { 36 37 /* ------------------------------------------------------------------------ */ 38 /* 39 * External Banner Interface. This interface provides the ability to 40 * divide the display window into multiple sub-windows, each with its own 41 * independent contents. 42 * 43 * To determine where a new banner is displayed, we look at the banners as 44 * a tree, rooted at the "main window," the special banner that the system 45 * automatically creates initially for the main game text. We start by 46 * allocating the entire display (or the entire application window, if 47 * we're running on a GUI system) to the main window. We then traverse 48 * the tree, starting with the root window's children. For each child 49 * window, we allocate space for the child out of the parent window's 50 * area, according to the child's alignment and size settings, and deduct 51 * this space from the parent window's size. We then lay out the children 52 * of the child. 53 * 54 * For each banner window, we take its requested space out of the parent 55 * window's area by starting at the edge of the parent window rectangle as 56 * indicated by the banner's alignment, and taking the requested `width 57 * (for a left/right banner) or height (for a top/bottom banner), limiting 58 * to the available width/height in the parent window's space. Give the 59 * banner the full extent of the parent's space in its other dimension (so 60 * a left/right banner gets the full height of the parent space, and a 61 * top/bottom banner gets the full width). 62 * 63 * Note that the layout proceeds exclusively down the tree (i.e., from the 64 * root to children to grandchildren, and so on). It *appears* that a 65 * child affects its parent, because of the deduction step: a child 66 * acquires screen space by carving out a chunk of its parent. The right 67 * way to think about this, though, is that the parent's full area is the 68 * union of the parent window and all of its children; when viewed this 69 * way, the parent's full area is fully determined the instant the parent 70 * is laid out, and never changes as its children are laid out. Note in 71 * particular that a child can never make a parent larger; the only thing 72 * a child can do to a parent is carve out a chunk of the parent for 73 * itself, which doesn't affect the boundaries of the union of the parent 74 * plus its children. 75 * 76 * Note also that if the banner has a border, and the implementation 77 * actually draws borders, the border must be drawn for the *full* area of 78 * the banner, as defined above. For example, suppose we have two 79 * borders: banner A is a child of the main window, is top-aligned, and 80 * has a border. Banner B is a child of banner A, right-aligned, with no 81 * border. Obviously, without considering banner B, banner A's space runs 82 * across the entire width of the main window, so its border (at the 83 * bottom of its area) runs across the entire width of the main window. 84 * Banner B carves out some space from A's right side for itself, so 85 * banner A's actual on-screen area runs from the left edge of the main 86 * window to banner B's left edge. However, even though banner A itself 87 * no longer runs the full width of the main window, banner A's *full* 88 * area - that is, the union of banner A's on-screen area and all of its 89 * children's full areas - does still run the entire width of the main 90 * window, hence banner A's border must still run the full width of the 91 * main window. The simple way of looking at this is that a banner's 92 * border is always to be drawn exactly the same way, regardless of 93 * whether or not the banner has children - simply draw the banner as it 94 * would be drawn if the banner had no children. 95 * 96 * Each time a banner is added or removed, we must recalculate the layout 97 * of the remaining banners and main text area. The os_banner_xxx() 98 * implementation is responsible for this layout refiguring. 99 * 100 * The entire external banner window interface is optional, although the 101 * functions must at least be defined as dummies to avoid linker errors 102 * when building. If a platform doesn't implement this feature, 103 * os_banner_create() should simply return null, and the other routines 104 * can do nothing. 105 */ 106 107 /* 108 * Create a banner window. 'info' gives the desired parameters for the new 109 * banner. 110 * 111 * Note that certain requested parameter settings might or might not be 112 * respected, depending on the capabilities of the platform and user 113 * preferences. os_banner_getinfo() can be used after creation to 114 * determine which parameter settings are actually used in the new banner. 115 * 116 * 'parent' gives the parent of this banner; this is the banner handle of 117 * another banner window, or null. If 'parent' is null, then the new 118 * banner is a child of the main window, which the system creates 119 * automatically at startup and which contains the main input/output 120 * transcript. The new banner's on-screen area is carved out of the 121 * parent's space, according to the alignment and size settings of the new 122 * window, so this determines how the window is laid out on the screen. 123 * 124 * 'where' is OS_BANNER_FIRST to make the new window the first child of its 125 * parent; OS_BANNER_LAST to make it the last child of its parent; 126 * OS_BANNER_BEFORE to insert it immediately before the existing banner 127 * identified by handle in 'other'; or OS_BANNER_AFTER to insert 128 * immediately after 'other'. When BEFORE or AFTER is used, 'other' must 129 * be another child of the same parent; if it is not, the routine should 130 * act as though 'where' were given as OS_BANNER_LAST. 131 * 132 * 'other' is a banner handle for an existing banner window. This is used 133 * to specify the relative position among children of the new banner's 134 * parent, if 'where' is either OS_BANNER_BEFORE or OS_BANNER_AFTER. If 135 * 'where' is OS_BANNER_FIRST or OS_BANNER_LAST, 'other' is ignored. 136 * 137 * 'wintype' is the type of the window. This is one of the 138 * OS_BANNER_TYPE_xxx codes indicating what kind of window is desired. 139 * 140 * 'align' is the banner's alignment, given as an OS_BANNER_ALIGN_xxx 141 * value. Top/bottom banners are horizontal: they run across the full 142 * width of the existing main text area. Left/right banners are vertical: 143 * they run down the full height of the existing main text area. 144 * 145 * 'siz' is the requested size of the new banner. The meaning of 'siz' 146 * depends on the value of 'siz_units', which can be OS_BANNER_SIZE_PCT to 147 * set the size as a percentage of the REMAINING space, or 148 * OS_BANNER_SIZE_ABS to set an absolute size in the "natural" units of the 149 * window. The natural units vary by window type: for text and text grid 150 * windows, this is in rows/columns of '0' characters in the default font 151 * for the window. Note that when OS_BANNER_SIZE_ABS is used in a text or 152 * text grid window, the OS implementation MUST add the space needed for 153 * margins and borders when determining the actual pixel size of the 154 * window; in other words, the window should be large enough that it can 155 * actually display the given number or rows or columns. 156 * 157 * The size is interpreted as a width or height according to the window's 158 * orientation. For a TOP or BOTTOM banner, the size is the height; for a 159 * LEFT or RIGHT banner, the size is the width. A banner has only one 160 * dimension's size given, since the other dimension's size is determined 161 * automatically by the layout rules. 162 * 163 * Note that the window's size can be changed later using 164 * banner_size_to_contents() or banner_set_size(). 165 * 166 * 'style' is a combination of OS_BANNER_STYLE_xxx flags - see below. The 167 * style flags give the REQUESTED style for the banner, which might or 168 * might not be respected, depending on the platform's capabilities, user 169 * preferences, and other factors. os_banner_getinfo() can be used to 170 * determine which style flags are actually used. 171 * 172 * Returns the "handle" to the new banner window, which is an opaque value 173 * that is used in subsequent os_banner_xxx calls to operate on the window. 174 * Returns null if the window cannot be created. An implementation is not 175 * required to support this functionality at all, and can subset it if it 176 * does support it (for example, an implementation could support only 177 * top/bottom-aligned banners, but not left/right-aligned), so callers must 178 * be prepared for this routine to return null. 179 */ 180 void *os_banner_create(void *parent, int where, void *other, int wintype, 181 int align, int siz, int siz_units, 182 unsigned long style); 183 184 185 /* 186 * insertion positions 187 */ 188 #define OS_BANNER_FIRST 1 189 #define OS_BANNER_LAST 2 190 #define OS_BANNER_BEFORE 3 191 #define OS_BANNER_AFTER 4 192 193 /* 194 * banner types 195 */ 196 197 /* 198 * Normal text stream window. This is a text stream that behaves 199 * essentially like the main text window: text is displayed to this 200 * through os_banner_disp(), always in a stream-like fashion by adding new 201 * text to the end of any exiting text. 202 * 203 * Systems that use proportional fonts should usually simply use the same 204 * font they use by default in the main text window. However, note that 205 * the OS_BANNER_STYLE_TAB_ALIGN style flag might imply that a fixed-pitch 206 * font should be used even when proportional fonts are available, because 207 * a fixed-pitch font will allow the calling code to rely on using spaces 208 * to align text within the window. 209 */ 210 #define OS_BANNER_TYPE_TEXT 1 211 212 /* 213 * "Text grid" window. This type of window is similar to an normal text 214 * window (OS_BANNER_TYPE_TEXT), but is guaranteed to arrange its text in 215 * a regular grid of character cells, all of the same size. This means 216 * that the output position can be moved to an arbitrary point within the 217 * window at any time, so the calling program can precisely control the 218 * layout of the text in the window. 219 * 220 * Because the output position can be moved to arbitrary positions in the 221 * window, it is possible to overwrite text previously displayed. When 222 * this happens, the old text is completely obliterated by the new text, 223 * leaving no trace of the overwritten text. 224 * 225 * In order to guarantee that character cells are all the same size, this 226 * type of window does not allow any text attributes. The implementation 227 * should simply ignore any attempts to change text attributes in this 228 * type of window. However, colors can be used to the same degree they 229 * can be used in an ordinary text window. 230 * 231 * To guarantee the regular spacing of character cells, all 232 * implementations must use fixed-pitch fonts for these windows. This 233 * applies even to platforms where proportional fonts are available. 234 */ 235 #define OS_BANNER_TYPE_TEXTGRID 2 236 237 238 /* 239 * banner alignment types 240 */ 241 #define OS_BANNER_ALIGN_TOP 0 242 #define OS_BANNER_ALIGN_BOTTOM 1 243 #define OS_BANNER_ALIGN_LEFT 2 244 #define OS_BANNER_ALIGN_RIGHT 3 245 246 /* 247 * size units 248 */ 249 #define OS_BANNER_SIZE_PCT 1 250 #define OS_BANNER_SIZE_ABS 2 251 252 253 /* 254 * banner style flags 255 */ 256 257 /* 258 * The banner has a visible border; this indicates that a line is to be 259 * drawn to separate the banner from the adjacent window or windows 260 * "inside" the banner. So, a top-aligned banner will have its border 261 * drawn along its bottom edge; a left-aligned banner will show a border 262 * along its right edge; and so forth. 263 * 264 * Note that character-mode platforms generally do NOT respect the border 265 * style, since doing so takes up too much screen space. 266 */ 267 #define OS_BANNER_STYLE_BORDER 0x00000001 268 269 /* 270 * The banner has a vertical/horizontal scrollbar. Character-mode 271 * platforms generally do not support scrollbars. 272 */ 273 #define OS_BANNER_STYLE_VSCROLL 0x00000002 274 #define OS_BANNER_STYLE_HSCROLL 0x00000004 275 276 /* 277 * Automatically scroll the banner vertically/horizontally whenever new 278 * text is displayed in the window. In other words, whenever 279 * os_banner_disp() is called, scroll the window so that the text that the 280 * new cursor position after the new text is displayed is visible in the 281 * window. 282 * 283 * Note that this style is independent of the presence of scrollbars. 284 * Even if there are no scrollbars, we can still scroll the window's 285 * contents programmatically. 286 * 287 * Implementations can, if desired, keep an internal buffer of the 288 * window's contents, so that the contents can be recalled via the 289 * scrollbars if the text displayed in the banner exceeds the space 290 * available in the banner's window on the screen. If the implementation 291 * does keep such a buffer, we recommend the following method for managing 292 * this buffer. If the AUTO_VSCROLL flag is not set, then the banner's 293 * contents should be truncated at the bottom when the contents overflow 294 * the buffer; that is, once the banner's internal buffer is full, any new 295 * text that the calling program attempts to add to the banner should 296 * simply be discarded. If the AUTO_VSCROLL flag is set, then the OLDEST 297 * text should be discarded instead, so that the most recent text is 298 * always retained. 299 */ 300 #define OS_BANNER_STYLE_AUTO_VSCROLL 0x00000008 301 #define OS_BANNER_STYLE_AUTO_HSCROLL 0x00000010 302 303 /* 304 * Tab-based alignment is required/supported. On creation, this is a hint 305 * to the implementation that is sometimes necessary to determine what 306 * kind of font to use in the new window, for non-HTML platforms. If this 307 * flag is set on creation, the caller is indicating that it wants to use 308 * <TAB> tags to align text in the window. 309 * 310 * Character-mode implementations that use a single font with fixed pitch 311 * can simply ignore this. These implementations ALWAYS have a working 312 * <TAB> capability, because the portable output formatter provides <TAB> 313 * interpretation for a fixed-pitch window. 314 * 315 * Full HTML TADS implementations can also ignore this. HTML TADS 316 * implementations always have full <TAB> support via the HTML 317 * parser/renderer. 318 * 319 * Text-only implementations on GUI platforms (i.e., implementations that 320 * are not based on the HTML parser/renderer engine in HTML TADS, but 321 * which run on GUI platforms with proportionally-spaced text) should use 322 * this flag to determine the font to display. If this flag is NOT set, 323 * then the caller doesn't care about <TAB>, and the implementation is 324 * free to use a proportionally-spaced font in the window if desired. 325 * 326 * When retrieving information on an existing banner, this flag indicates 327 * that <TAB> alignment is actually supported on the window. 328 */ 329 #define OS_BANNER_STYLE_TAB_ALIGN 0x00000020 330 331 /* 332 * Use "MORE" mode in this window. By default, a banner window should 333 * happily allow text to overflow the vertical limits of the window; the 334 * only special thing that should happen on overflow is that the window 335 * should be srolled down to show the latest text, if the auto-vscroll 336 * style is set. With this flag, though, a banner window acts just like 337 * the main text window: when the window fills up vertically, we show a 338 * MORE prompt (using appropriate system conventions), and wait for the 339 * user to indicate that they're ready to see more text. On most systems, 340 * the user acknowledges a MORE prompt by pressing a key or scrolling with 341 * the mouse, but it's up to the system implementor to decide what's 342 * appropriate for the system. 343 * 344 * Note that MORE mode in ANY banner window should generally override all 345 * other user input focus. In other words, if the game in the main window 346 * would like to read a keystroke from the user, but one of the banner 347 * windows is pausing with a MORE prompt, any keyboard input should be 348 * directed to the banner paused at the MORE prompt, not to the main 349 * window; the main window should not receive any key events until the MORE 350 * prompt has been removed. 351 * 352 * This style requires the auto-vscroll style. Implementations should 353 * assume auto-vscroll when this style is set. This style can be ignored 354 * with text grid windows. 355 */ 356 #define OS_BANNER_STYLE_MOREMODE 0x00000040 357 358 /* 359 * This banner is a horizontal/vertical "strut" for sizing purposes. This 360 * means that the banner's content size is taken into account when figuring 361 * the content size of its *parent* banner. If the banner has the same 362 * orientation as the parent, its content size is added to its parent's 363 * internal content size to determine the parent's overall content size. 364 * If the banner's orientation is orthogonal to the parent's, then the 365 * parent's overall content size is the larger of the parent's internal 366 * content size and this banner's content size. 367 */ 368 #define OS_BANNER_STYLE_HSTRUT 0x00000080 369 #define OS_BANNER_STYLE_VSTRUT 0x00000100 370 371 372 /* 373 * Delete a banner. This removes the banner from the display, which 374 * requires recalculating the entire screen's layout to reallocate this 375 * banner's space to other windows. When this routine returns, the banner 376 * handle is invalid and can no longer be used in any os_banner_xxx 377 * function calls. 378 * 379 * If the banner has children, the children will no longer be displayed, 380 * but will remain valid in memory until deleted. A child window's 381 * display area always comes out of its parent's space, so once the parent 382 * is gone, a child has no way to acquire any display space; resizing the 383 * child won't help, since it simply has no way to obtain any screen space 384 * once its parent has been deleted. Even though the window's children 385 * will become invisible, their banner handles will remain valid; the 386 * caller is responsible for explicitly deleting the children even after 387 * deleting their parent. 388 */ 389 void os_banner_delete(void *banner_handle); 390 391 /* 392 * "Orphan" a banner. This tells the osifc implementation that the caller 393 * wishes to sever all of its ties with the banner (as part of program 394 * termination, for example), but that the calling program does not 395 * actually require that the banner's on-screen display be immediately 396 * removed. 397 * 398 * The osifc implementation can do one of two things: 399 * 400 * 1. Simply call os_banner_delete(). If the osifc implementation 401 * doesn't want to do anything extra with the banner, it can simply delete 402 * the banner, since the caller has no more use for it. 403 * 404 * 2. Take ownership of the banner. If the osifc implementation wishes 405 * to continue displaying the final screen configuration after a program 406 * has terminated, it can simply take over the banner and leave it on the 407 * screen. The osifc subsystem must eventually delete the banner itself 408 * if it takes this routine; for example, if the osifc subsystem allows 409 * another client program to be loaded into the same window after a 410 * previous program has terminated, it would want to delete any orphaned 411 * banners from the previous program when loading a new program. 412 */ 413 void os_banner_orphan(void *banner_handle); 414 415 /* 416 * Banner information structure. This is filled in by the system-specific 417 * implementation in os_banner_getinfo(). 418 */ 419 struct os_banner_info_t 420 { 421 /* alignment */ 422 int align; 423 424 /* style flags - these indicate the style flags actually in use */ 425 unsigned long style; 426 427 /* 428 * Actual on-screen size of the banner, in rows and columns. If the 429 * banner is displayed in a proportional font or can display multiple 430 * fonts of different sizes, this is approximated by the number of "0" 431 * characters in the window's default font that will fit in the 432 * window's display area. 433 */ 434 int rows; 435 int columns; 436 437 /* 438 * Actual on-screen size of the banner in pixels. This is meaningful 439 * only for full HTML interpreter; for text-only interpreters, these 440 * are always set to zero. 441 * 442 * Note that even if we're running on a GUI operating system, these 443 * aren't meaningful unless this is a full HTML interpreter. Text-only 444 * interpreters should always set these to zero, even on GUI OS's. 445 */ 446 int pix_width; 447 int pix_height; 448 449 /* 450 * OS line wrapping flag. If this is set, the window uses OS-level 451 * line wrapping because the window uses a proportional font, so the 452 * caller does not need to (and should not) perform line breaking in 453 * text displayed in the window. 454 * 455 * Note that OS line wrapping is a PERMANENT feature of the window. 456 * Callers can note this information once and expect it to remain 457 * fixed through the window's lifetime. 458 */ 459 int os_line_wrap; 460 }; 461 typedef struct os_banner_info_t os_banner_info_t; 462 463 /* 464 * Get information on the banner - fills in the information structure with 465 * the banner's current settings. Note that this should indicate the 466 * ACTUAL properties of the banner, not the requested properties; this 467 * allows callers to determine how the banner is actually displayed, which 468 * depends upon the platform's capabilities and user preferences. 469 * 470 * Returns true if the information was successfully obtained, false if 471 * not. This can return false if the underlying OS window has already 472 * been closed by a user action, for example. 473 */ 474 int os_banner_getinfo(void *banner_handle, os_banner_info_t *info); 475 476 /* 477 * Get the character width/height of the banner, for layout purposes. This 478 * gives the size of the banner in character cells. 479 * 480 * These are not meaningful when the underlying window uses a proportional 481 * font or varying fonts of different sizes. When the size of text varies 482 * in the window, the OS layer is responsible for word-wrapping and other 483 * layout, in which case these simply return zero. 484 * 485 * Note that these routines might appear to be redundant with the 'rows' 486 * and 'columns' information returned from os_banner_getinfo(), but these 487 * have two important distinctions. First, these routines return only the 488 * width and height information, so they can be implemented with less 489 * overhead than os_banner_getinfo(); this is important because formatters 490 * might need to call these routines frequently while formatting text. 491 * Second, these routines are not required to return an approximation for 492 * windows using proportional fonts, as os_banner_getinfo() does; these can 493 * simply return zero when a proportional font is in use. 494 */ 495 int os_banner_get_charwidth(void *banner_handle); 496 int os_banner_get_charheight(void *banner_handle); 497 498 /* clear the contents of a banner */ 499 void os_banner_clear(void *banner_handle); 500 501 /* 502 * Display output on a banner. Writes the output to the window on the 503 * display at the current output position. 504 * 505 * The following special characters should be recognized and handled: 506 * 507 * '\n' - newline; move output position to the start of the next line. 508 * 509 * '\r' - move output position to start of current line; subsequent text 510 * overwrites any text previously displayed on the current line. It is 511 * permissible to delete the old text immediately on seeing the '\r', 512 * rather than waiting for additional text to actually overwrite it. 513 * 514 * All other characters should simply be displayed as ordinary printing 515 * text characters. Note that tab characters should not be passed to this 516 * routine, but if they are, they can simply be treated as ordinary spaces 517 * if desired. Other control characters (backspace, escape, etc) should 518 * never be passed to this routine; the implementation is free to ignore 519 * any control characters not listed above. 520 * 521 * If any text displayed here overflows the current boundaries of the 522 * window on the screen, the text MUST be "clipped" to the current window 523 * boundaries; in other words, anything this routine tries to display 524 * outside of the window's on-screen rectangle must not actually be shown 525 * on the screen. 526 * 527 * Text overflowing the display boundaries MUST also be retained in an 528 * internal buffer. This internal buffer can be limited to the actual 529 * maximum display size of the terminal screen or application window, if 530 * desired. It is necessary to retain clipped text, because this allows a 531 * window to be expanded to the size of its contents AFTER the contents 532 * have already been displayed. 533 * 534 * If the banner does its own line wrapping, it must indicate this via the 535 * os_line_wrap flag in the os_banner_getinfo() return data. If the 536 * banner doesn't indicate this flag, then it must not do any line 537 * wrapping at all, even if the caller attempts to write text beyond the 538 * right edge of the window - any text overflowing the width of the window 539 * must simply be clipped. 540 * 541 * Text grid banners must ALWAYS clip - these banners should never perform 542 * any line wrapping. 543 */ 544 void os_banner_disp(void *banner_handle, const char *txt, size_t len); 545 546 /* 547 * Set the text attributes in a banner, for subsequent text displays. 548 * 'attr' is a (bitwise-OR'd) combination of OS_ATTR_xxx values. 549 */ 550 void os_banner_set_attr(void *banner_handle, int attr); 551 552 /* 553 * Set the text color in a banner, for subsequent text displays. The 'fg' 554 * and 'bg' colors are given as RGB or parameterized colors; see the 555 * definition of os_color_t for details. 556 * 557 * If the underlying renderer is HTML-enabled, then this should not be 558 * used; the appropriate HTML code should simply be displayed to the 559 * banner instead. 560 */ 561 void os_banner_set_color(void *banner_handle, os_color_t fg, os_color_t bg); 562 563 /* 564 * Set the screen color in the banner - this is analogous to the screen 565 * color in the main text area. 566 * 567 * If the underlying renderer is HTML-enabled, then this should not be 568 * used; the HTML <BODY> tag should be used instead. 569 */ 570 void os_banner_set_screen_color(void *banner_handle, os_color_t color); 571 572 /* flush output on a banner */ 573 void os_banner_flush(void *banner_handle); 574 575 /* 576 * Set the banner's size. The size has the same meaning as in 577 * os_banner_create(). 578 * 579 * 'is_advisory' indicates whether the sizing is required or advisory only. 580 * If this flag is false, then the size should be set as requested. If 581 * this flag is true, it means that the caller intends to call 582 * os_banner_size_to_contents() at some point, and that the size being set 583 * now is for advisory purposes only. Platforms that support 584 * size-to-contents may simply ignore advisory sizing requests, although 585 * they might want to ensure that they have sufficient off-screen buffer 586 * space to keep track of the requested size of display, so that the 587 * information the caller displays in preparation for calling 588 * size-to-contents will be retained. Platforms that do not support 589 * size-to-contents should set the requested size even when 'is_advisory' 590 * is true. 591 */ 592 void os_banner_set_size(void *banner_handle, int siz, int siz_units, 593 int is_advisory); 594 595 /* 596 * Set the banner to the size of its current contents. This can be used 597 * to set the banner's size after some text (or other material) has been 598 * displayed to the banner, so that the size can be set according to the 599 * banner's actual space requirements. 600 * 601 * This changes the banner's "requested size" to match the current size. 602 * Subsequent calls to os_banner_getinfo() will thus indicate a requested 603 * size according to the size set here. 604 */ 605 void os_banner_size_to_contents(void *banner_handle); 606 607 /* 608 * Turn HTML mode on/off in the banner window. If the underlying renderer 609 * doesn't support HTML, these have no effect. 610 */ 611 void os_banner_start_html(void *banner_handle); 612 void os_banner_end_html(void *banner_handle); 613 614 /* 615 * Set the output coordinates in a text grid window. The grid window is 616 * arranged into character cells numbered from row zero, column zero for 617 * the upper left cell. This function can only be used if the window was 618 * created with type OS_BANNER_TYPE_TEXTGRID; the request should simply be 619 * ignored by other window types. 620 * 621 * Moving the output position has no immediate effect on the display, and 622 * does not itself affect the "content size" for the purposes of 623 * os_banner_size_to_contents(). This simply sets the coordinates where 624 * any subsequent text is displayed. 625 */ 626 void os_banner_goto(void *banner_handle, int row, int col); 627 628 } // End of namespace TADS 629 } // End of namespace Glk 630 631 #endif 632