Subject: bug#1804: 23.0.60; (with-ns) application preferences should be global

From: David Reitter <[email-masked]>
Date: Mon, 4 May 2009 12:20:12 -0400

When did you last pull?

The font panel isn't shown from Preferences for me.  Prefs should show  
the same as M-x customize RET.
(The prefs panel that we used to have is gone.)
Can you confirm so we can close this?

If it was there and showed the font panel, then I would absolutely  
agree with you...

Btw, even if it is shown (using M-x ns-popup-font-panel, which I  
blieve is the only way to bring it up now), it does not clearly show  
its association with a window.  This, however, is a Cocoa problem with  
the design of the panel.

- David

On May 4, 2009, at 12:11 PM, B Smith-Mannschott wrote:

> On Tue, Apr 28, 2009 at 15:25, David Reitter  
> <[email-masked]> wrote:
>> Ben,
>>>
>>> 7. Select a font 8. (nothing happens) 9. Click on a currently open  
>>> emacs
>>> frame (not the Preferences window). 10. (the Preferences window  
>>> loses
>>> keyboard focus) 11. Select a font (from the font panel) 12. (The  
>>> font of the
>>> currently focused frame will change.) 13. (The font of the second  
>>> frame will
>>> not change.)
>>
>> I don't think that the font panel should apply globally
>
> It should be clear form the context that produces it, what the font
> panel will affect. As it stands, it's displayed by Preferences in the
> *Application* menu. This makes it global, by implication. If font
> control isn't intended to be global, then it simply shouldn't be made
> available through the application-wide Preferences window.
>
>> (at least not in GNU
>> Emacs); also because it gives the user less control.
>
> This line of argument *can* be used to paper over all manner of
> usability sins, but in the case of Emacs it's correct. It is in Emacs'
> nature to be all dials, toggles and blinkenlights.
>
>> However, it should set the font for future frames, because there is  
>> no other
>> way to set that through the GUI (w/o customization buffer).   
>> Perhaps that
>> would serve as a working compromise.  For that, try the code below.
>
> I'll give the code a spin the next time I'm on my mac. I still
> thinking removing this option from the application-wide preferences
> window is the simplest way not to violate the user's expectations.
> (Naturally, the functionality still needs to be accessible and
> discoverable thorough other means.)
>
>> (defun ns-respond-to-change-font ()
>>  "Respond to changeFont: event, expecting ns-input-font and\n\
>> ns-input-fontsize of new font."
>>  (interactive)
>>  (let ((face 'default))
>>    (set-face-attribute face t
>>                        :family ns-input-font
>>                        :height (* 10 ns-input-fontsize))
>>    (set-face-attribute face (selected-frame)
>>                        :family ns-input-font
>>                        :height (* 10 ns-input-fontsize))
>>    (let ((spec
>>           (list (list t (face-attr-construct 'default)))))
>>      (put face 'customized-face spec)
>>      (custom-push-theme 'theme-face face 'user 'set spec)
>>      (put face 'face-modified nil))))