Tk Toolkit

The scripted font dialog does close when the parent is destroyed on linux.
The other issues can be raised as bugs at some point if they annoy people.
Its just hidden in here.

Dropping prio; not a release-blocker now

leaving open as a reminder to fix a number of small issues with the
pure-tcl implementation:
- [tk choosefont configure] option changes ineffective once dialog has been
shown (except for -font)
- [tk choosefont configure] option querying fails with 'value for "-xxx"
missing'
- font dialog does not close when parent window is destroyed

committed attached updated patch to HEAD

adds docs & demos and other minor changes (file renaming for consistency,
deal with parent window destruction in macosx code) and removes [tk]
conversion to ensemble (committed separately)
c.f. github for details
http://github.com/das/tcltk/commits/fontchooser
File Added: tip324-081210.diff

TIP now updated to match this implementation

updated patch with minor changes attached, c.f. github for details
http://github.com/das/tcltk/commits/fontchooser

File Added: tip324-081201.diff

updated to apply cleanly to HEAD
File Added: tip324-081129.diff

ack, obviously meant to say:
'that I have _not_ been able to test'

note that the tip324-081128 patch makes minor changes to the windows code
that I have been able to test, so somebody needs to verify that the patch
still builds & works correctly on windows.

attached updated patch that:
- integrates Adrian Robert's changes posted to tcl-core recently (with a
rewrite of the TkMacOSXProcessFontEvent() changes that has some additional
fixes)
- adds a virtual event sent when the chosen font changes (i.e. when the
-cmd callback is called),
- turns [tk] into an ensemble
- renames [tk::choosefont] to [tk fontchooser] (and similarly for all
related symbols)

for full history, see http://github.com/das/tcltk/commits/fontchooser
note that patch needs to be applied with -p1

TIP update to match this patch will follow shortly


File Added: tip324-081128.diff

You access the pure Tcl version using [tk_chooseFont] (or whatever the TIP
says) on the correct platform. The manner in which the dialog is
implemented (C code, Tcl script, whatever) is not defined in the spec: RTFS
if you want to know. :-p

I tested the OS X version with DAS's patch against the documentation
outlined at http://www.tcl.tk/cgi-bin/tct/tip/324:

tk::choosefont configure -parent: returns "."--not sure this is relevant on
the Mac because it's a native system dialog.
tk::choosefont configure -title: Title is hard-coded in dialog.
tk::choosefont configure -font: Running this command in the console changed
the selected font in the system dialog to the font specified by
"configure", but the console display did not reflect the new font until I
clicked on the font dialog. Not sure if this is a problem or not, but I
wanted to document the behavior.
tk::choosefont configure -visible: works as expected.
tk::choosefont hide and tk::choosefont show: works as expected.

tk::choosefont configure -command: This is unclear to me: do individual
developers need to worry about this or is it handled by the dialog? I'm
wondering because this seems to be where a developer would add an
additional command binding, i.e. writing the chosen font to a preferences
file, etc. Further explanation of this would be helpful.

Also, how does one access the pure-Tcl/script version of this dialog?
That's not clear from the documentation.

updated patch attached with aqua implementation added.
File Added: tk_tip213-080619.diff

Updated the patch once more. This now implements introspection of the
configuration options and adds a read-only -visible option which is needed
for platforms using a non-modal dialog. I have also added a virtual
<<TkChoosefontVisibility>> event that is sent to the parent window when the
visibility of the dialog changes.
Implementations in pure-tcl and native for Windows.
File Added: tk_chooseFont-20080516.patch

New patch that implements both the script and Win32 versions as a
tk::choosefont ensemble with configure, show and hide sub-commands. This
has an example Font menu on the console which works fine in windows and
should work as expected on MacOSX too (where Cmd-T should toggle the
visibility of the dialog).
The API changes are in response to tcl-core input from the MacOSX people.
File Added: tk_chooseFont-20080511.patch

Another patch update. This has more tests and now uses Keith Vetter's
script implementation with suitable updates for scripting and key
navigation.
File Added: tk_chooseFont-20080418.patch

Updated the TIP and the sample implementation to permit MacOSX style usage.
The script implementation is my ttk version of dkf's dialog but Keith
Vetter has provided another that closely follows the Windows font chooser
that possibly the unix people may prefer.
File Added: tk_chooseFont-20080415.patch

I've added a patch against 8.6 that merges the tkchat choosefont code for
windows into a tk_chooseFont command. For platforms that don't implement a
C tk_chooseFont tk.tcl will call to tk::choosefont::choosefont which is a
rewrite of dkf's fontSel dialog code but using ttk widgets. This is in
library/fontdlg.tcl

The interface to tk_chooseFont is close to that in the tip except for using
-apply instead of -updatefont as all the currently extant implementations
that I know of are using -apply.
A Mac implementation is welcome but I'll not be doing it.
File Added: tk_chooseFont.patch

I think that how mac users expect to see this work is pretty much
irrelevant. At the moment they don't get anything and neither do windows
and X users. We can arrange to have something done correctly for win32 and
something nice for X users and leave the Mac people with something that at
least lets them choose a font using a dialog. Once some enterprising mac
person sorts out how to do it for that platform then great.
In the meantime I have a couple of critcl units that provide a Win32 and a
Gtk standard font dialog and the package degrades to use DKFs tcl font
dialog. Currently this stuff is in the tkchat application.

Logged In: YES
user_id=79902

The key problem with doing this sort of thing is that Win
users expect font dialogs to behave one way (modal, with OK
button, etc.) and Mac users expect font dialogs to behave
another (non-modal, with main menu item to show/hide the
dialog).

Resolving these differences is tricky. :-(

(TIP#213 http://tip.tcl.tk/213 is related, so classifying as
a TIP impl...)