Progress Meter in use under Solaris/CDE
A progress meter based on a
scale widget. It is amazing what you can do with
the standard widgets and commands, that the original authors didn't
think of.
Makes a progress meter
out of a collection of frame and label
widgets, together with the judicious use of the place
geometry manager. Requires Tk 8.0 or later. Sorry, but I've not
made this into a true megawidget. 'Tis sloth on my part, I
admit...
Progress Meter in use
under Solaris/CDE
There are two relevant commands introduced in the global namespace:
Creates a new widget with path name pathName and makes it into a progress bar. The additional arguments are passed directly to the underlying frame, though the class of the frame is pre-set to Progress. The progress bar is initialised to 0%. Returns the name of the widget created.
Sets the progress displayed by the progress bar called pathName to be value out of range. The range defaults to 100, making the value be directly what the value displayed on the meter is.
The script includes some test code at the end which you will need to strip off before using the progress meter in your own code. Things to notice include the resize behaviour of the bar and the way the numbers in the center change colour to maintain contrast as the count goes past 50%.
How to make a scrolled
window. This code uses the grid geometry manager
extensively, so Tk4.1* is needed.
This script implements a notebook container megawidget similar to the type beloved by Microsoft in their properties dialogs.
(Suitable for Tk 8.0 and later only.)
Notebook (with embedded
canvas) in use under Solaris/CDE
There are three relevant commands:
This command creates a new notebook widget called pathName with the tabs whose names are the tabString arguments. Note that my tabs are never wrapped onto multiple lines, so if you define a lot of them your widget could get rather wide. If you find yourself doing that, get a better interface idiom! Multi-row tabs are extremely lame and hard to use...
If pathName refers to a notebook that has already been defined, then this command returns the name of the subframe connected to the tab with name tabString. There is no other mechanism for getting a name component for referring to the contents; you must use this if you wish to put any widgets inside the notebook.
If pathName refers to a notebook that has already been defined, then this command makes the tab with the name tabString into the current tab.
Thanks to Lindsay Marshall for this addition. It was a function I had never needed in my own code, and so I'd never added it...
Please note that the focus is not handled quite as well as I might wish. In particular, tab-traversal can have unexpected effects, and there is no way to change tabs using the keyboard. Also, it only really looks at its best if your default application borderWidth is 1.
There is some demo code attached to the end of the script. You'll need to remove it to use the script in a library.
This Tcl script provides a ComboBox much as in the style of M$Windows. Derived from a news posting by Jeffrey Hobbs.
This Tcl script provides a labelled FrameBox much as in the style of M$Windows. The only real problem with it is the fact that you cannot really have the contents as being packed (or placed for that matter) in the window whose name is an argument to the procedure. However, this seems to be unavoidable without masses of work...
This Tcl script provides a quick demonstration of how to link listboxes so they track each other. It also shows how to go about setting up a sensible gridded geometry for a window.
For Tk 8.0 and later, I supply a font selection dialog box for those
times when you want to pop up a dialog to select a font, just as you
can do for a colour with tk_chooseColor. I also supply
an advanced version that includes
documentation, etc.
New! Users of Tk 8.4 and later should use this version instead, especially as it includes support for the Tile theming engine as well.
|
Font selection dialog.
A rather nice font selection dialog that can handle virtually anything thrown at it except multibyte fonts (which I don't understand anyway.) And there the main problem (in Tk8.1) is that the sample text is not font-dependant but rather optimised for ASCII... If the Cancel button is pressed or the font selector is deleted in an untimely fashion, then an empty string is returned. If the OK button is pressed, then the name of the selected font is returned. |
Font Dialog in
use under Solaris/CDE without an Apply button
Note that I suspect that some of the colours have been messed up in the above picture due to Motif/CDE's mangling of resources. One of these days I will get around to figuring out how to introduce better resources handling. The last time I felt that energetic, I was scared off by the code though, so don't hold out any high hopes for now...
Font
Dialog in use under Windows with an Apply button
Font Dialog
(for Tk 8.4) in use under Windows XP with the Tile package also loaded.
This command takes four option-arguments:
Adds an apply button to the dialog. When that button is pressed, the given script will be executed with the given name of the font appended as a single argument (i.e. all whitespace and other significant metacharacters will be quoted.)
What font style should be used to initialise the font selector. Has a fairly reasonable default...
What window is the logical parent of the font selector.
A title for the font window (might not be displayed with some window managers).
The dialog should be relatively easy to customise for non-English locales provided the fonts in use have 256-character encodings. I might work on getting multibyte encodings working as well some time, but I don't know enough about the issues involved at the moment.
The sample text is actually in an entry widget so that users can change it to include any characters interesting to them. You cannot navigate to this window using the keyboard. This feature is not intended to be visible at the moment - please let me know if this is not the case on some platform!
The version in the zip archive is more completely documented with the resource files split off from the main body of the code. These resource files are also now documented.
Both versions of the code include heavy use of
keyboard binding and accelerators - the dialog can be manipulated
virtually entirely through the keyboard. Note that I don't normally
put that much effort in - I actually care about this code! 
Both versions of the code should work acceptably under both Unix/X and Windows. I have no access to other platforms so I can't perform the platform-localisation there...
A drop-in replacement for the error dialog and error script in the standard Tk 8.0 (and later) distribution. Features added are:
Concealment of the trace until a button is pressed. This makes the occurrence of this dialog somewhat more acceptable in an application that is exposed to users.
A Save To Log capability, which makes writing the error trace out to a file (for printing, emailing or posting to USENET) much easier.
There is no mail this error message to the developer feature, as this is much more difficult to make platform-indepenent. (It is easy enough on Unix-based systems, but Windows doesn't do things that way, and who knows with the Mac?)