Recent Changes - Search:

WikiDoc

Categories

New dialogs

Main.NewDialogs History

Hide minor edits - Show changes to markup

January 23, 2006, at 10:42 PM by 212.180.15.164 -
Added lines 1-49:

(:title New dialogs:)

Over the last few years the 'new dialogs' code has been started (by Vince) vastly improved by Lars, and now become quite mature. Sadly it hasn't actually been used that widely in AlphaTcl, but that is now changing. All of the standard prefs dialogs (with the exception of menus/features selection at present) now use the new code. The new code basically corresponds to dialog::make]] and [[dialog::make_paged which are 100s of times better than the crufty old stuff.

Now that this new code is being heavily used, it may be time to note down any limitations which are discovered, and approaches to resolving them. Note: try to distinguish between issues which are limitations of the dialogsNew.tcl library and issues which are simply due to inadequate usage of that library (typically procs in dialogs.tcl).

We would like to keep as many special cases out of dialogsNew as possible. It's a very nice, clean library at present -- let's keep it that way!


Known issues in dialogsNew.tcl:

  • Very long text items, while they nicely wrap across multiple lines, do not wrap across multiple pages. This makes it very hard to control page heights for informational dialogs containing a large amount of static text.

Proposed solution: allow large text items to break across multiple pages -- details to be specified (Lars?)

  • Variable preferences have a very long text-edit field.

Proposed solution: Reducing the overall width of the dialogs would help. We could also define a new preference type named "var-short", which would only offer a text-edit field that is 1/3 of the normal var type. Perhaps a better solution is to define a type "numeric" (possibly with other attributes, which could even be used for validation), and have those treated differently.


Known issues in usage:

  • Standard pref dialogs are much too wide.

Proposed solution: Reduce the ambitions of dialog::setDefaultGeometry. Including 3 columns of 'flag' preferences is a noble goal, but it makes for a crowded dialog/screen. If we only tried to include 2 columns, then the default 'PrefWidth' variable could be reduced as well. Even fancier versions would make some reasonable calculation based on the global 'screenWidth' variable, setting an arbitrary maximum of 65% of the screen, or whatever is aesthetically pleasing.

Note that on Windows with Alphatk the current sizing works very well for Vince's machine with 4 or even 5 columns of flags!


Fixed issues:

  • You can't remove the 'Cancel' button.

Implemented solution: when giving -cancel {} the code should remove the button rather than display a small button with no contents.

  • It is possible for a dialog to contain a completely empty page. E.g. on Alphatk/Windows the Tcl mode preferences dialog is fine, but hit Help and you get a dialog with three pages, the third of which is totally empty.

Implemented solution: Not a bug, rather we need to fix the documentation to say that 'discretionary' items will create page breaks even if there are no items to follow, and therefore discretionary items should only be used _before_ known items, not after. Then any other bad use of discretionary needs fixing.

  • In Mac OS X 10.3.x, the width of pop-up menus is no longer automatically determined, and must be specified in advance by the dialogs code. Otherwise they always extend to the end of the dialog.

Implemented solution: pop-up menu width is explicitly calculated in dialog::makeMenuItem.

  • The discretionary items which can control switching from a single- to a multi-page dialog should also, ideally, adjust the y-position of all the first page's entries to move them down a bit and adjust for the perfect space for the popup menu at the top (currently first and subsequent pages have a different gap at the top). If this happened then we could also enhance the code so a single page dialog with empty page name didn't actually use any space for the empty page name at the top.

Implemented solution: fixed this bug by handling the single->multipage transition more intelligently.

Page last modified on January 23, 2006, at 10:42 PM
Hosted on SourceForge.net Logo