Recent Changes - Search:

WikiDoc

Categories

A new [dialog] command

The ancient 'dialog' command needs an overhaul. It has served us well, and, with the wonders of 'dialog::make' and 'dialog::make_paged', can be made to do amazing things. However:

  • It has no notion of a hierarchy of items, beyond those which happen to follow individual -n flags which are interpreted as being in a given page

  • You must give the command everything about the dialog up front

  • It's got dozens of flags and options which need some overhaul

  • You need to specify the width and height up front

  • Items can't resize or reveal each other (no 'reveal' triangle).

What do we want a new dialog command to do:

  • Handle nested hierarchies

  • Have some sort of callback mechanism for multiple pages/items and page contents.

  • Handle new dialog controls (tabs, listbox-controlled-pages, reveal-triangles, etc)

  • Data must be returned in a non-flat format if the dialog is dynamic (since we may never construct all items/pages in the dialog)

  • Should x,y,w,h be things that are given and fixed or not be specified at all? (we could let the geometry managers lay things out for us)

  • Should be able to provide an overall dialog result callback (and means to see if the dialog still exists) so that we can create totally non-modal (asynchronous) dialogs.

  • what else?

Let's try to be simple with this (NOTE: none of this is supposed to be any kind of final design, just some thoughts to experiment with):

dialog {item list}

is about as simple as it can get, where each item may itself be an item list. An item is presumably either a dialog-control of some kind or a group of further items. Let's say, then that each item has a type (the first element of the list), and then:

dialog {{button ...} {group {{button ..} {button ..}}} {button ..}}

would give a simple example of a dialog with one button, a group of two buttons and another button. What if the contents of a group is supposed to be dynamically generated? Then we'd use:

dialog {{button ...} {group -callback generate} {button ..}}

Where proc generate {} { return list {button ..} {button ..} } would make this code do exactly the same thing. We could then have a multi-page dialog with something like:

dialog {{type -pages {list of item lists, one for each page}} {button ..}}

Where type could be any dialog type which has multiple possible values (or, for consistency, I suppose even an item which takes one value like a label could be used if there is only one page in the dialog). So, a listbox or a tab or a popup could control the given list of pages, or a checkbox could control just two pages.

We'd presumably want the ability for the list of pages to be calculated on the fly, or to be given and fixed, and the page contents to be calculated on the fly, or given and fixed.


Category.Development

Page last modified on July 20, 2006, at 03:41 PM
Hosted on SourceForge.net Logo