Re: observations for ns*.m files (Re: Emacs.app merged)

[Dan Nicolaescu]

Adrian Robert <address@hidden> writes:

  > On Jul 27, 2008, at 4:12 PM, Dan Nicolaescu wrote:
  > 
  > OK.
  > 
  > 
  > 
  >     What is the #ifdef HAVE_NS code in frame.c:x_get_frame used for?
  >     ...
  > 
  >                                     if (!strcmp (SDATA (lower), "on")
  >     #ifdef HAVE_NS
  >                        || !strcmp(SDATA(lower), "yes")
  >     #endif
  >                        || !strcmp (SDATA (lower), "true"))
  >     ...
  >     Is "yes" and "no" something that some other program on the system can
  >     write? Or something that the user would write?  If the latter, then
  >     wouldn't it be better to just teach the users to use the values all
  >     other systems uses and avoid complications in code and docs?
  > 
  > 
  > "YES" and "NO" are the standard boolean values used in the NS defaults 
system.
  >  A property list editor or a user could write them.  
  > As far as teaching users,
  > I would hope that the purpose of application software is to adapt computers 
to
  > users rather than the other way around!  ;)

I was referring to the case where the users were taught to write
"yes"/"no" in order to use this stuff in emacs, they can be taught to
use the cross-platform standard values instead.

  >      Qfontsize = intern ("fontsize");
  >      staticpro (&Qfontsize);
  >    
  >     This seems a generic facility, should it be here?  Can't the generic
  >     way of specifying fonts work on this platform too?
  > 
  > 
  > I'm not sure if there is a generic facility.  On X, font size is part of the
  > XLFD strings.  These are not used except where absolutely necessary on NS, 
and
  > I would like to get rid of these cases.

At least talk to the Windows people because they probably have the same
problem.  This is something very basic, it would be a pity to have
different solutions for different platform.

  > 
  >      DEFVAR_LISP ("ns-icon-type-alist", &Vns_icon_type_alist,
  >                   doc: /* Alist of elements (REGEXP . IMAGE) for images of
  >     icons associated to frames.
  >     ...
  > 
  >     This looks like a generic thing, better not make it platform
  >     specific.  Is there a problem with the normal way of specifying icons?
  > 
  > 
  > What is the normal way?  I think this facility in the NS port probably dates
  > from before emacs itself had this feature, so certainly we should try to use
  > the generic code now.

You can set a icon as a frame parameter.

  >     void
  >     syms_of_nsterm ()
  >     {
  >      DEFVAR_LISP ("ns-command-modifier", &ns_command_modifier,
  >                   "This variable describes the behavior of the command 
key.\n\
  >     Set to control, meta, alt, super, or hyper means it is taken to be that
  >     key.");
  >    
  >      DEFVAR_LISP ("ns-control-modifier", &ns_control_modifier,
  >                   "This variable describes the behavior of the control 
key.\n\
  >     Set to control, meta, alt, super, or hyper means it is taken to be that
  >     key.");
  >    
  >     These 2 look identical, are they both needed?  Are they needed at all
  >     after the recent modifier changes?
  > 
  > 
  > On Mac keyboards, Command and Control are separate keys, so both are needed.

So you can change the meaning of Control?  That sounds strange.  Maybe
Meta/Alt are sometime confused, but Control should be pretty well
established.  Do users actually want this?

  >  What recent modifier changes are you referring to?

where-is-preferred-modifier

  >      DEFVAR_LISP ("ns-antialias-text", &ns_antialias_text,
  >                   "Non-nil (the default) means to render text antialiased. 
Only
  >     has an effect on OS X Panther and above.");
  >    
  >     Can the generic functionality be used instead of this?
  > 
  > 
  > Which generic functionality?

There's support for antialiasing in X, I know no details about it as I
don't use it.

One more thing:

DEFUN ("ns-set-alpha", Fns_set_alpha, Sns_set_alpha, 2, 2, 0,
       doc: /* Return a color equivalent to COLOR with alpha setting
       ALPHA.
The argument ALPHA should be a number between 0 and 1, where 0 is full
transparency and 1 is opaque.  */)

Not sure about the details, but can this functionality be replaced by
an implementation of x_set_frame_alpha?