TIP #213: A Standard Dialog for Font Selection

TIP #213: A STANDARD DIALOG FOR FONT SELECTION
 ========================================
========
Version:      $Revision: 1.1 $
Author:       Donal K. Fellows <donal.k.fellows_at_man.ac.uk>
State:        Draft
Type:         Project
Tcl-Version:  8.5
Vote:         Pending
Created:      Saturday, 21 August 2004
URL:          http://purl.org/tcl/tip/213.html
WebEdit:      http://purl.org/tcl/tip/edit/213
Post-History:

-------------------------------------------------------------------------

ABSTRACT
==========

This TIP proposes a new command that pops up a dialog box that allows
the selection of a font. Where possible, this dialog will be
implemented using the host platform's standard dialogs.

RATIONALE
===========

A number of platforms (Windows and MacOSX) have standard dialogs for
common user-oriented tasks, and Tk provides an interface to these
dialogs through commands such as /tk_getOpenFile/ and /tk_chooseColor/.
However, another dialog that they provide and which some programs would
find useful is a font selector. This TIP proposes adding a command to
do just that; where a platform does not provide such a standard dialog,
one implemented using a Tcl script will be used instead.

PROPOSED CHANGE
=================

Tk shall have a new command, *tk_chooseFont*, with the syntax described
below (which should be recognizably similar to *tk_chooseColor*). If
the dialog is cancelled, the result of the command will be an empty
string. Otherwise, if a font is chosen the result will be a font string
suitable for use with any widget's /-font/ option.

*tk_chooseFont* ?/-option value -option value .../?

Permitted options are:

-parent: This specifies the parent window of the dialog (similarly to
the *-parent* option to other dialogs).

-title: This specifies the title of the dialog.

-initialfont:
This specifies (in any form suitable for a /-font/ option to a
widget) the font that is selected when the dialog is displayed.

-updatefont:
This specifies the name of a font created with *font create*
which will be updated to reflect the details of the users
selection; if this option is specified, it provides the result of
*tk_chooseFont* if the dialog is not cancelled. Where the dialog
implementation supports it, the font will also be updated during
the selection process. This allows the effects of changing the
font to be reflected immediately in other Tk widgets.

Whenever a platform provides a suitable font dialog in its own API, Tk
should not use a script-based alternative, even if this means missing
out on features like the title or dynamic updating of the font during
the selection process.

User code should not assume that the event loop will not be running
during the processing of the *tk_chooseFont* command.

REFERENCE IMPLEMENTATION
==========================

Not yet available.

COPYRIGHT
===========

This document has been placed in the public domain.

-------------------------------------------------------------------------

TIP AutoGenerator - written by Donal K. Fellows

[[Send Tcl/Tk announcements to tcl-announce@mitchell.org
Announcements archived at http://groups.yahoo.com/group/tcl_announce/
Send administrivia to tcl-announce-request@mitchell.org
Tcl/Tk at http://tcl.tk/ ]]

Donal K. Fellows wrote:

>  TIP #213: A STANDARD DIALOG FOR FONT SELECTION
>  ========================================
========
> ...
>  Permitted options are:
>

I would like to suggest additional options:

-sample string

Sets the sample text to the supplied string.

-fixed bool

If bool evaluates to true, only show fixed-width fonts and/or initially
sets the "show only fonts of type X" option in the dialog. That is, if
the dialog has a dropdown menu with choices like "fixed", "variable" or
"both", -fixed 1 would automatically select the "fixed" option.

-applylabel string

Use string for the label of the Apply button

-oklabel string

Use string for the label of the Ok button

-cancellabel string

Use string for the label of the Cancel button

If there were an easy way to set the button labels via X resources
and/or message catalogs we wouldn't necessarily need the last three options.

I would hope that the dialog somehow gracefully handles bitmapped fonts.
I still have users that insist on using fonts like "6x13" :-|

Donal K. Fellows wrote:
>  TIP #213: A STANDARD DIALOG FOR FONT SELECTION
>  ========================================
========

>
>  Tk shall have a new command, *tk_chooseFont*, with the syntax described
>  below (which should be recognizably similar to *tk_chooseColor*). If
>  the dialog is cancelled, the result of the command will be an empty
>  string. Otherwise, if a font is chosen the result will be a font string
>  suitable for use with any widget's /-font/ option.
>
what about named fonts? font create doesn't take the same string
do I always have to create a named font first & then use the dialog
with -updatefont ?

>        *tk_chooseFont* ?/-option value -option value .../?
>
>  Permitted options are:
>
>  -parent: This specifies the parent window of the dialog (similarly to
>        the *-parent* option to other dialogs).
>
>  -title: This specifies the title of the dialog.
>
>  -initialfont:
>        This specifies (in any form suitable for a /-font/ option to a
>        widget) the font that is selected when the dialog is displayed.
>
>  -updatefont:
>        This specifies the name of a font created with *font create*
>        which will be updated to reflect the details of the users
>        selection; if this option is specified, it provides the result of
>        *tk_chooseFont* if the dialog is not cancelled. Where the dialog
>        implementation supports it, the font will also be updated during
>        the selection process. This allows the effects of changing the
>        font to be reflected immediately in other Tk widgets.
>

if this updates the font on the fly, does it reset it on a cancel?
if so it should probably state that explicitly, if not I think it
is a very bad idea to have a dialog have lasting effects on a cancel.

in general I think the diablog could have a text area with sample text
(perhaps having an option for caller to specify what the tesxt is)
and that text is changed dynamically, but the font name given is
only updated if user clicks OK - I think this is more consistent
with the behavior of most apps.

other than these questions I think this is a good idea (and even if the
answers/decision are contrary to what I think, I still like it)

bruce

Some great ideas guys for platforms that don't have a font chooser but the
OS-provided font selector will be used if there is one available (Windows,
OS X) so unfortunately any options above/beyond those provided by the OS
ones wouldn't be cross-platform.  At least that's the way I understand it,
correct me if I'm wrong.  That's why Donal kept it simple and
straightforward.

From the TIP --
"Whenever a platform provides a suitable font dialog in its own API, Tk
should not use a script-based alternative, even if this means missing out on
features like the title or dynamic updating of the font during the selection
process."

Bruce Hartweg wrote:
> what about named fonts? font create doesn't take the same string
> do I always have to create a named font first & then use the dialog
> with -updatefont ?

Yes.  I was rather annoyed that I couldn't use the same values for
both (or at least not easily) so I chose to make the value directly
usable for display.

> if this updates the font on the fly, does it reset it on a cancel?
> if so it should probably state that explicitly, if not I think it
> is a very bad idea to have a dialog have lasting effects on a cancel.

Yes, but you're right that I ought to specify this a bit more
strongly.  Thanks for picking up on this.

> in general I think the diablog could have a text area with sample text
> (perhaps having an option for caller to specify what the tesxt is)
> and that text is changed dynamically, but the font name given is
> only updated if user clicks OK - I think this is more consistent
> with the behavior of most apps.

Sample text is , but I'm not sure it can be done in a
cross-platform manner.  (I'm sure that the version for Unix will allow
the user to change it though, since I'll write that myself. Well,
actually I'll use some code that I've already got written. ;^)

Donal.

Bryan Oakley wrote:
> I would like to suggest additional options:
>   -sample string
>   -fixed bool
>   -applylabel string
>   -oklabel string
>   -cancellabel string

I don't know that these can be done portably, or at least I am nowhere
near a good enough Win hacker to be able to say whether it is
possible.  :^)  (The key problem is turning out to be OSX, where the
system model for font selection is wildly different.)

> If there were an easy way to set the button labels via X resources
> and/or message catalogs we wouldn't necessarily need the last three options.[/colo
r]

Good point.

> I would hope that the dialog somehow gracefully handles bitmapped fonts.
> I still have users that insist on using fonts like "6x13" :-|

I was planning to use (on Unix) a dialog very much like that provided
in TkChat (which is actually code I wrote a few years ago), though
that ends up concealing system font aliases like 6x13.

Donal.

Bryan Oakley wrote:
> If there were an easy way to set the button labels via X resources
> and/or message catalogs we wouldn't necessarily need the last three
> options.

'OK' and 'Cancel' are already localised resources in Tk's message
catalogs; only 'Apply' would need to be added.  These are really
needed only on Un*x, since on Windows, the common dialogs are
already ostensibly localised.  I'm against exposing the button
labels in any way other than Tk's message catalogs.

(It's *possible* to reconfigure the labels under Windows, but
it's really, really, ugly - MS is obviously sending the message,
"Don't Do That.")

--
73 de ke9tv/2, Kevin

[A complimentary Cc of this posting was sent to
Donal K. Fellows
<donal.k.fellows@man.ac.uk>], who wrote in article <pgpmoose.200408250854.26091@despot.non.
net>:
>  Whenever a platform provides a suitable font dialog in its own API, Tk
>  should not use a script-based alternative, even if this means missing
>  out on features like the title or dynamic updating of the font during
>  the selection process.

.. unless the option `-native 0' is specified.  In the latter case
a fully-functional version (via TCL script, if needed) is used.

Hope this helps,
Ilya