TIP 324 (font chooser dialog in tk)

[Adrian Robert-3]

Hello,

TIP 324 proposes adding a script-level API and backing implementation  
to access system-provided font dialogs on Mac and Windows, and a Tcl/
Tk-based dialog on other X-windows systems.  Both the API and  
implementation have been discussed and refined previously on this list.

Implementation is due to Keith Vetter, Pat Thoyts, and Daniel A.  
Steffen, with some very minor modifications by me, to address a bug I  
ran into in the Mac implementation as well as outstanding items listed  
by Daniel A. Steffen on 2008/08/14:

http://thread.gmane.org/gmane.comp.lang.tcl.core/8654/focus=9667

Specifically, since my last post to that thread on 2008/09/27:

http://article.gmane.org/gmane.comp.lang.tcl.core/9898

I have:

- returned the implementation to use the command name given in the  
TIP: "tk_chooseFont"

- completed the implementation on Windows to allow empty string to  
unset values for 'font' and 'command' in tk_chooseFont configure

- clarified in the TIP that if multiple interpreters are active and  
have set command callbacks, only the one in the interpreter that most  
recently set it is called

I have been using the implementation on Mac and Windows for some  
months without incident and I attach it as a patch here, as the  
tracker listing at http://sourceforge.net/tracker/index.php?func=detail&aid=1477426&group_id=12997&atid=312997 
  seems to be protected, perhaps members-only?

Unless someone thinks further work is warranted, could this be called  
for vote now?


-Adrian








-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Tcl-Core mailing list
Tcl-Core@...
https://lists.sourceforge.net/lists/listinfo/tcl-core

[Donal K. Fellows-2]

Adrian Robert wrote:
> I have been using the implementation on Mac and Windows for some months
> without incident and I attach it as a patch here, as the tracker listing
> at
> http://sourceforge.net/tracker/index.php?func=detail&aid=1477426&group_id=12997&atid=312997 seems
> to be protected, perhaps members-only?

It's not "members only", it's "maintainers and submitter only". That's
how SF works. Submit a new patch; we won't mind!

Donal.


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Tcl-Core mailing list
Tcl-Core@...
https://lists.sourceforge.net/lists/listinfo/tcl-core

[Daniel A. Steffen]

Hi Adrian,

On 24/11/2008, at 20:53, Adrian Robert wrote:

> Unless someone thinks further work is warranted, could this be  
> called for vote now?

please wait for another week to call for a vote on this, that is still  
inside the Dec 10 timeframe by a week and will give me some more time  
to work on this and edit the TIP.

Thanks

Cheers,

Daniel

--
** Daniel A. Steffen                   **
** <mailto:das@...>  **


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Tcl-Core mailing list
Tcl-Core@...
https://lists.sourceforge.net/lists/listinfo/tcl-core

[Daniel A. Steffen]

Hi Adrian,

On 24/11/2008, at 20:53, Adrian Robert wrote:

> - returned the implementation to use the command name given in the  
> TIP: "tk_chooseFont"

as explained before, the rationale for using a command name outside of  
the existing tk_* naming scheme was to make it clear to the user that  
the subcommand API is significantly different to the tk_* dialog  
commands.

this is a bikeshed of course, but I'm still partial to [tk  
fontchooser], which fits better with the widget / action pattern of  
the new API, i.e. [tk fontchooser show] rather than [tk_chooseFont  
show].

it would also have the advantage to allow future additions to [tk]  
with the same [configure/show/hide] style for the color chooser and  
file dialogs that can accommodate the modeless versions of these on  
Mac OS X (the modal versions currently used by Tk are all legacy and  
are likely to go away in the not too distant future).

Cheers,

Daniel

--
** Daniel A. Steffen                   **
** <mailto:das@...>  **


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Tcl-Core mailing list
Tcl-Core@...
https://lists.sourceforge.net/lists/listinfo/tcl-core

[Donal K. Fellows-2]

Daniel A. Steffen wrote:
> it would also have the advantage to allow future additions to [tk]  
> with the same [configure/show/hide] style for the color chooser and  
> file dialogs that can accommodate the modeless versions of these on  
> Mac OS X (the modal versions currently used by Tk are all legacy and  
> are likely to go away in the not too distant future).

You've got to continue to support the modal operation for computability
with Windows, where the dialogs are modal.

Donal.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Tcl-Core mailing list
Tcl-Core@...
https://lists.sourceforge.net/lists/listinfo/tcl-core

[Donal K. Fellows-2]

Donal K. Fellows wrote:
> You've got to continue to support the modal operation for computability
> with Windows, where the dialogs are modal.

Aargh! I meant "compatibility". Damn you spellchecker!

Donl.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Tcl-Core mailing list
Tcl-Core@...
https://lists.sourceforge.net/lists/listinfo/tcl-core

[Daniel A. Steffen]

Hi Donal,

On 25/11/2008, at 10:18, Donal K. Fellows wrote:

> Daniel A. Steffen wrote:
>> it would also have the advantage to allow future additions to [tk]  
>> with the same [configure/show/hide] style for the color chooser  
>> and  file dialogs that can accommodate the modeless versions of  
>> these on  Mac OS X (the modal versions currently used by Tk are all  
>> legacy and  are likely to go away in the not too distant future).
>
> You've got to continue to support the modal operation for  
> computability
> with Windows, where the dialogs are modal.

oh definitely, but the [configure/show/hide] model can do that as  
shown by the TIP 324 implementation (where the dialog is modal on  
Windows and modeless on Mac OS X).
There is no way that the existing dialog commands like  
[tk_chooseColor] can support a modeless dialog API however, so these  
commands will become inoperative in a future version of Mac OS X Tk  
and we will need an alternative that can support both modal and modeless

Cheers,

Daniel

--
** Daniel A. Steffen                   **
** <mailto:das@...>  **


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Tcl-Core mailing list
Tcl-Core@...
https://lists.sourceforge.net/lists/listinfo/tcl-core

[Daniel A. Steffen]

On 25/11/2008, at 10:28, Daniel A. Steffen wrote:

> so these commands will become inoperative in a future version of Mac  
> OS X Tk

or better fallback to the pure-tcl implementation for back-compat...

Cheers,

Daniel

--
** Daniel A. Steffen                   **
** <mailto:das@...> **


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Tcl-Core mailing list
Tcl-Core@...
https://lists.sourceforge.net/lists/listinfo/tcl-core

[Adrian Robert-3]

On Nov 25, 2008, at 3:26 AM, Daniel A. Steffen wrote:

> Hi Adrian,
>
> On 24/11/2008, at 20:53, Adrian Robert wrote:
>
>> - returned the implementation to use the command name given in the  
>> TIP: "tk_chooseFont"
>
> as explained before, the rationale for using a command name outside  
> of the existing tk_* naming scheme was to make it clear to the user  
> that the subcommand API is significantly different to the tk_*  
> dialog commands.

I don't feel strongly and will go along with whatever, but IMHO the  
API difference does not outweigh the overall similarity to these other  
tk_ commands, which all deal with short-term, special purpose  
dialogs.  If the decision is to distinguish it though, I'd rather not  
do something as drastically new and different as to put it in a  
different namespace.  (The "tk_" prefix for the other commands is  
already strange enough and I wish it didn't exist.)

BTW, re: modeless dialogs, as far as I'm aware file open/save are  
generally modal on OS X.  Is this not true?


-Adrian


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Tcl-Core mailing list
Tcl-Core@...
https://lists.sourceforge.net/lists/listinfo/tcl-core

[Daniel A. Steffen]

On 25/11/2008, at 9:12, Adrian Robert wrote:

> IMHO the API difference does not outweigh the overall similarity to  
> these other
> tk_ commands, which all deal with short-term, special purpose
> dialogs.  If the decision is to distinguish it though, I'd rather not
> do something as drastically new and different as to put it in a
> different namespace.

exporting [fontchooser] from tk:: will actually help with that of  
course, as you can then just [namespace import] it.

we're bikeshedding between a '_' and a ' ' in the syntax at this point  
though...

>  (The "tk_" prefix for the other commands is already strange enough  
> and I wish it didn't exist.)

surely inroduced out of a desire to avoid collisions with user  
commands from a pre-namespace era...
in general, I think Tk should strive to behave more like a standard  
tcl package and (with new commands) not pollute the global namespace  
unnecessarily, esp with the advent of ensembles.

> BTW, re: modeless dialogs, as far as I'm aware file open/save are  
> generally modal on OS X.  Is this not true?


no, only the legacy OS9-back-compatible file dialogs are all modal,  
the modern save dialogs are sheets (i.e. modeless or more specifically  
document-modal).

similarly with the color picker, the modern variant is modeless,  
exactly like the font panel.

Cheers,

Daniel

--
** Daniel A. Steffen                   **
** <mailto:das@...>  **


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Tcl-Core mailing list
Tcl-Core@...
https://lists.sourceforge.net/lists/listinfo/tcl-core

[Daniel A. Steffen]

On Tue, Nov 25, 2008 at 09:06, Daniel A. Steffen <das@...> wrote:

On 24/11/2008, at 20:53, Adrian Robert wrote:

Unless someone thinks further work is warranted, could this be called for vote now?

please wait for another week to call for a vote on this, that is still inside the Dec 10 timeframe by a week and will give me some more time to work on this and edit the TIP.

I have now updated the TIP and the implementation, and it is now ready to be CFV as far as I am concerned. Pat has also indicated that his is happy with the proposed specification.

http://tip.tcl.tk/324

http://sourceforge.net/support/tracker.php?aid=1477426

http://github.com/das/tcltk/commits/fontchooser

Cheers,

Daniel

-- 
** Daniel A. Steffen                   **
** <mailto:das@...> **

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Tcl-Core mailing list
Tcl-Core@...
https://lists.sourceforge.net/lists/listinfo/tcl-core

[Adrian Robert-3]

On Dec 1, 2008, at 2:10 PM, Daniel A. Steffen wrote:

> On Tue, Nov 25, 2008 at 09:06, Daniel A. Steffen <das@...
> > wrote:
> On 24/11/2008, at 20:53, Adrian Robert wrote:
> Unless someone thinks further work is warranted, could this be  
> called for vote now?
>
> please wait for another week to call for a vote on this, that is  
> still inside the Dec 10 timeframe by a week and will give me some  
> more time to work on this and edit the TIP.
>
> I have now updated the TIP and the implementation, and it is now  
> ready to be CFV as far as I am concerned. Pat has also indicated  
> that his is happy with the proposed specification.
>
> http://tip.tcl.tk/324

I'm still uneasy about the prefixing for the command, though I hope  
this can be decided independently of the voting on the TIP.  The main  
proposals have been:

(1) tk_chooseFont [original]
(2) ::tk::chooseFont [June-November]
(3) tk chooseFont [current]

(1) is consistent with other temporary dialogs (tk_getOpenFile,  
tk_messageBox, tk_chooseColor, etc.) in its naming style, however the  
font chooser dialog operates differently in that it may be non-modal  
on Mac OS X and perhaps other platforms.

Therefore (2) was proposed, however it would introduce a practice of  
dividing the tk core cross-platform commands into multiple  
namespaces.  This seems too drastic a move to deal with the  
inconsistency in (1).

Perhaps partly in reaction to this, (3) was brought into the most  
recent version of the TIP.  However the 'tk' command is described in  
its man page as "Manipulate Tk internal state". The other subcommands  
under it include "appname", "scaling", and "useinputmethods".  Putting  
up a dialog to choose a font would be an odd man out here.

(1) is the best choice.  Not just for the shortcomings of (2) and (3),  
but also because the diversity of commands under the tk_ prefix is in  
fact already greater than what would be added by bringing in  
chooseFont.  There are tk_focusNext, tk_setPalette, tk_textPaste, even  
tk_bisque.  Moreover, the most similar dialog Tk currently supports is  
tk_chooseColor.  The font chooser is non-modal on Mac OS X, however to  
be equally platform compliant tk_chooseColor should be this way as  
well, and may eventually be changed to such.  Regardless, prefixing/
naming these commands differently will adversely affect the clarity of  
the tk core command set.


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Tcl-Core mailing list
Tcl-Core@...
https://lists.sourceforge.net/lists/listinfo/tcl-core

[Donal K. Fellows-2]

Adrian Robert wrote:
> I'm still uneasy about the prefixing for the command, though I hope  
> this can be decided independently of the voting on the TIP.  The main  
> proposals have been:
>
> (1) tk_chooseFont [original]
> (2) ::tk::chooseFont [June-November]
> (3) tk chooseFont [current]

My advice? Stop vacillating. Go with the current proposal. Not because
it is inherently vastly superior, but because *nothing* is vastly
superior here and the current proposal is, well, current. :-)

Donal.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Tcl-Core mailing list
Tcl-Core@...
https://lists.sourceforge.net/lists/listinfo/tcl-core