NeXTStep port preferences

NeXTStep port preferences

[David Reitter]

[-- Attachment #1.1: Type: text/plain, Size: 435 bytes --]

The new NeXTStep / Cocoa port contains a "Preferences" dialog.

Is this wanted, or just a mistake when merging?  It is inconsistent  
with all the other customizations, at least in terms of UI.  Where are  
these preferences stored?

A better preferences system would be much welcomed, but it should be  
compatible with existing customizations.  The selection of preferences  
seems arbitrary; why the cursor type, or line spacing?



[-- Attachment #1.2: pastedGraphic.png --]
[-- Type: image/png, Size: 130079 bytes --]

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

Re: NeXTStep port preferences

[Adrian Robert]

David Reitter <david.reitter <at> gmail.com> writes:

> The new NeXTStep / Cocoa port contains a "Preferences" dialog.
> 
> Is this wanted, or just a mistake when merging?  It is inconsistent  
> with all the other customizations, at least in terms of UI.

The logic is similar to the "Options" menu, which itself
is "inconsistent with all other customizations": put a few of the
most frequently desired quick changes in a convenient place.


>  Where are these preferences stored?

They are stored using the NS equivalent to X resources, as has
been discussed previously on this list and various OS X emacs
lists.


 
> A better preferences system would be much welcomed, but it should be  
> compatible with existing customizations.  The selection of preferences  
> seems arbitrary; why the cursor type, or line spacing?

The preferences window controls surface aspects of the GUI that
were not already controlled by other GUI methods.  Font, color,
frame dimensions, and toolbar presence are handled by mouse
actions or popup windows (at least, until the font and color
panels will be removed from Emacs.app).  The modifier key
mappings were also added because they are a notorious point of
varying preferences among OS X users.

Anyway, the functioning of this facility is already broken by
recent checkins which override the system highlight color and
antialiasing selections.  I suspect it will quickly be removed.
Unfortunately users will never be consulted.  It is also not
something easy to maintain outside of GNU Emacs itself (e.g. in a
distribution like Aquamacs) because it involves integrated
Objective C code and additional files going into the bundle.

The desire to keep all GUI interfaces to Emacs similar to one
another is a reasonable one.  However, some concessions to
platform convention and user convenience ought to be tolerated on
a case-by- case basis depending on the user-benefit to
obtrusiveness ratio.  Otherwise, at least in this case, there's
no real reason not to just use the X11 version on OS X (and
GNUstep platforms).  Apple has not said they will stop supporting X.

Re: NeXTStep port preferences

[Benjamin Riefenstahl]

Hi David, Adrian,


I have been trying to work with that dialog some and have been mostly
frustrated.   Some thoughts:

- Quick access to the options for default font and modifier keys are
  usefull for first installation and probably for newbies.

- The options to change the cursor are probably not important enough
  to have here.  [If I understand this right, there are new NextStep
  specific cursor drawing routines in the port.  This is not good, I
  think.  If the portable cursor routines are deficient they should be
  updated for all platforms.  I may be missing something here.]

- That the dialog stores its stuff in the defaults database is a good
  feature, because defaults are read before ".emacs" and so this is a
  good place for the font setting.

- I am missing the "Emacs.geometry" option in the defaults database.
  For me "Emacs.font" and "Emacs.geometry" are the two options that I
  need in the defaults database, everything else is better in
  ".emacs".

- The font setting mechanism doesn't work unless an Emacs frame is
  selected.  This used to be documented in the readme, but it is still
  a bug.

- The callbacks that the Cocoa dialogs call are not protected in a
  catch block.  If they run into an error, Emacs aborts without a
  visible error message.

I think that the "Preferences..." menu should start a customization
buffer, like it does in the Carbon port.  This can start with the root
of the customize hierarchy or it can be a "New Installation" group
with the most important options, if somebody wants to create such a
group.  If customize does not support having buttons to show the font
and color dialogs, that can be added to customize.


Adrian Robert writes:
> It is also not something easy to maintain outside of GNU Emacs
> itself (e.g. in a distribution like Aquamacs)

It is not easy to be maintained anywhere.  As you notice, it is broken
even now, and only part of that is bit-rot.

> However, some concessions to platform convention and user
> convenience ought to be tolerated on a case-bycase basis depending
> on the user-benefit to obtrusiveness ratio.

I don't think that a buggy and old-fashioned looking dialog (IMO) is
really an asset for anybody, certainly not Mac users.

> Otherwise, at least in this case, there's no real reason not to just
> use the X11 version on OS X

The inconvenience of having to start X11 to edit files or to read mail
and probably missing features (e.g. does DnD work from Finder to
Emacs?).


benny

Re: NeXTStep port preferences

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 3212 bytes --]

Adrian,

On 17 Jul 2008, at 13:32, Adrian Robert wrote:
>
> The logic is similar to the "Options" menu, which itself
> is "inconsistent with all other customizations": put a few of the
> most frequently desired quick changes in a convenient place.

How did you evaluate or estimate what customizations are frequent?
For instance, how frequently would people want to use a highlight  
color in Emacs that is different from the rest of the system?  Or use  
ugly, non-antialiased fonts and even choose special (deprecated)  
"quickdraw" rendering?
How come the cursor blink rate is considered a frequently used setting?

>>
>> Where are these preferences stored?
>
> They are stored using the NS equivalent to X resources, as has
> been discussed previously on this list and various OS X emacs
> lists.

Why are those settings stored in org.gnu.Emacs.plist, while others  
(from the Options menu) are stored in the custom-file?
This makes it harder for people to troubleshoot their settings.

I for instance have trouble with the antialiasing (can't turn it on in  
the current build). There's now an extra file location to know and to  
check for possible adverse settings.


>
> The preferences window controls surface aspects of the GUI that
> were not already controlled by other GUI methods.

Yes, but customization buffers control GUI aspects, too.  (Besides,  
your statement is inconsistent with the paragraph I quoted first,  
above.)

I am under the impression that this special dialog contains settings  
that are specific to the Cocoa port.  I believe that the technical  
layer or revision at which a setting was introduced should not  
influence the UI.

> The modifier key
> mappings were also added because they are a notorious point of
> varying preferences among OS X users.

I'll buy that for the Meta/Option/Command key assignment.  This could  
be handled via the Options menu.

> Anyway, the functioning of this facility is already broken by
> recent checkins which override the system highlight color and
> antialiasing selections.

Antialiasing doesn't work any longer for me, the fonts look horrible.
How does one turn it back on?
How do I find out the system's highlight color via Lisp?


>  something easy to maintain outside of GNU Emacs itself (e.g. in a
> distribution like Aquamacs) because it involves integrated
> Objective C code and additional files going into the bundle.

I'm happy to write ObjC code - happier actually than writing Carbon  
code in C--.

One thing I am annoyed with is that the Apple Events map has gone -  
this was an elegant way to integrate events with the standard Emacs  
event map system.
This was important for the Preferences / About Emacs menu items, but  
also for external interfaces (ODOC events, e.g.)

> The desire to keep all GUI interfaces to Emacs similar to one
> another is a reasonable one.  However, some concessions to
> platform convention and user convenience ought to be tolerated on
> a case-by- case basis depending on the user-benefit to
> obtrusiveness ratio.

I was arguing for that 3 or 4 years ago, but the events since have  
convinced me that we need to cater to two distinct user groups, with  
two different packages.

- D

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

Re: NeXTStep port preferences

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 468 bytes --]

On 19 Jul 2008, at 11:59, David Reitter wrote:
>>
>> Anyway, the functioning of this facility is already broken by
>> recent checkins which override the system highlight color and
>> antialiasing selections.

Looked into this some more.
The settings in Preferences don't stick.
I suggest you take out the QD smoothing setting or at least unify it  
in one single popup menu.
ns-use-qd-smoothing should default to nil in my view.  That's default  
on that platform.
- D

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

Re: NeXTStep port preferences

[Adrian Robert]

On Jul 19, 2008, at 12:01 PM, David Reitter wrote:

> On 19 Jul 2008, at 11:59, David Reitter wrote:
>>>
>>> Anyway, the functioning of this facility is already broken by
>>> recent checkins which override the system highlight color and
>>> antialiasing selections.
>
> Looked into this some more.
> The settings in Preferences don't stick.
> I suggest you take out the QD smoothing setting or at least unify it  
> in one single popup menu.
> ns-use-qd-smoothing should default to nil in my view.  That's  
> default on that platform.

That was the case.  Something happened, I don't know if due to the  
cleanup checkins or otherwise.  Saving Preferences now causes crashes  
for many people, though apparently not including you.  Somehow  
Quickdraw smoothing always gets enabled.

Re: NeXTStep port preferences

[Adrian Robert]

Benjamin Riefenstahl <b.riefenstahl <at> turtle-trading.net> writes:

> I have been trying to work with that dialog some and have been mostly
> frustrated.   Some thoughts:
> 
> - Quick access to the options for default font and modifier keys are
>   usefull for first installation and probably for newbies.

Some users differ.  There are many use cases calling for frequent
font and/or modifier key changes.  We'd need a poll to get better
data.


> - The options to change the cursor are probably not important enough
>   to have here.

Again, see above.  I use different types of cursors for editing
different files (coding, text, etc.), and it's nice to switch
quickly.


>  [If I understand this right, there are new NextStep
>   specific cursor drawing routines in the port.  This is not good, I
>   think.  If the portable cursor routines are deficient they should be
>   updated for all platforms.  I may be missing something here.]

This has been in the TODO list for some years, but because it has
been working well enough and there have been higher-priority
issues (e.g., bugs) it has not gotten done.  It would be great if
someone could work on this.



> - I am missing the "Emacs.geometry" option in the defaults database.
>   For me "Emacs.font" and "Emacs.geometry" are the two options that I
>   need in the defaults database, everything else is better in
>   ".emacs".

'geometry' is split into Width, Height, Top, Left entries.  If
changing this to geometry and possibly using an X11-compatible
string would be better, a patch is welcome.


 
> - The font setting mechanism doesn't work unless an Emacs frame is
>   selected.  This used to be documented in the readme, but it is still
>   a bug.

Another long-standing TODO fallen victim to more urgent tasks.
Help is welcome.


 
> - The callbacks that the Cocoa dialogs call are not protected in a
>   catch block.  If they run into an error, Emacs aborts without a
>   visible error message.

I've never had a bug report on this, but if it's an easy fix we
should do it.


> > It is also not something easy to maintain outside of GNU Emacs
> > itself (e.g. in a distribution like Aquamacs)
> 
> It is not easy to be maintained anywhere.  As you notice, it is broken
> even now, and only part of that is bit-rot.

This is a bit harsh.  It has been part of Emacs.app for years and
has had few problems.


> > However, some concessions to platform convention and user
> > convenience ought to be tolerated on a case-bycase basis depending
> > on the user-benefit to obtrusiveness ratio.
> 
> I don't think that a buggy and old-fashioned looking dialog (IMO) is
> really an asset for anybody, certainly not Mac users.

Again, "buggy" is a little unfair.  If you search the Emacs.app
mailing list and bug database you find a lot of other bugs
reported, but very rarely anything with this.  Also you are the
first person to mention anything negative about the appearance.
On the other hand there have been many positive comments from
users.


> > Otherwise, at least in this case, there's no real reason not to just
> > use the X11 version on OS X
> 
> The inconvenience of having to start X11 to edit files or to read mail
> and probably missing features (e.g. does DnD work from Finder to
> Emacs?).

It would be far easier to add these features to Apple's X11 impl
than to port and maintain a separate interface to GNU Emacs.  And
they would provide wider benefit.

Re: NeXTStep port preferences

[Benjamin Riefenstahl]

Hi Adrian,


First-off, thanks for putting energy and time into this.

Adrian Robert writes:
> Some users differ.  There are many use cases calling for frequent
> font and/or modifier key changes.  We'd need a poll to get better
> data.

Right.  BTW, re modifiers, at least with a German keyboard, having Opt
as Meta by default is not a good idea.  I need that modifier to insert
important characters like ~ @ \ [ ] { }, so it's not really free.

> 'geometry' is split into Width, Height, Top, Left entries.  If
> changing this to geometry and possibly using an X11-compatible
> string would be better, a patch is welcome.

I see.  For Emacs users coming from other platforms, I think it would
be better to mimic the X resources approach here.

> Benjamin Riefenstahl <b.riefenstahl <at> turtle-trading.net> writes:
>> - The font setting mechanism doesn't work unless an Emacs frame is
>> selected.  This used to be documented in the readme, but it is
>> still a bug.
>
> Another long-standing TODO fallen victim to more urgent tasks.  Help
> is welcome.

I had a look at this, but I failed so far to make much progress,
because I don't know enough about NextStep/Cocoa.

>> - The callbacks that the Cocoa dialogs call are not protected in a
>> catch block.  If they run into an error, Emacs aborts without a
>> visible error message.
>
> I've never had a bug report on this, but if it's an easy fix we
> should do it.

I just checked my facts.  Emacs runs into an abort when
ns-save-preferences throws an error.  Ns-respond-to-change-font, the
callback for the font panel, seems to be ok.

I noticed the problem when I was changing the code and introduced my
own bugs in ns-save-preference, but than you never know what errors
might occur in real life.

>> It is not easy to be maintained anywhere.  As you notice, it is
>> broken even now, and only part of that is bit-rot.
>
> This is a bit harsh.

Maybe. 

> It has been part of Emacs.app for years and has had few problems.

Just above we are talking about at least two long-standing bugs that I
noticed in just a bit of trying it out and fixing a simple bug (BTW
you might want to look at that, it's at
<http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=578>,
with patch).

> Also you are the first person to mention anything negative about the
> appearance.  On the other hand there have been many positive
> comments from users.

Sorry, that may just be my personal impression.  Ignoring aesthetics,
the one usability thing that I noticed was that I would have liked to
see which default font is currently selected before opening the font
panel.

>> > Otherwise, at least in this case, there's no real reason not to
>> > just use the X11 version on OS X
>> 
>> [...] missing features (e.g. does DnD work from Finder to Emacs?).
>
> It would be far easier to add these features to Apple's X11 impl
> than to port and maintain a separate interface to GNU Emacs.

It would?  I didn't know it was even possible to do this kind of thing
using documented interfaces.


benny

Re: NeXTStep port preferences

[Justin Bogner]

Adrian Robert wrote:
> Some users differ.  There are many use cases calling for frequent
> font and/or modifier key changes.  We'd need a poll to get better
> data.
> 

It would probably be quite difficult, but if we're going to provide a preference 
pane for frequently changed settings, wouldn't it make sense to put something in 
the customize panes to set what options showed up in the dialog?

>> - The options to change the cursor are probably not important enough
>>   to have here.
> 
> Again, see above.  I use different types of cursors for editing
> different files (coding, text, etc.), and it's nice to switch
> quickly.
> 

This looks like a job for a hook, it would surely be more convenient if the 
cursor changed automatically when you wanted it to.

>>> Otherwise, at least in this case, there's no real reason not to just
>>> use the X11 version on OS X
>> The inconvenience of having to start X11 to edit files or to read mail
>> and probably missing features (e.g. does DnD work from Finder to
>> Emacs?).
> 
> It would be far easier to add these features to Apple's X11 impl
> than to port and maintain a separate interface to GNU Emacs.  And
> they would provide wider benefit.
> 

It is far more convenient and pleasant to use a native application than one 
nested under another window system, no matter how well integrated that other 
window system is. The behaviour of a window in X11 is inherently different 
(though perhaps subtly) from that of a cocoa window.

For example, consider the copy and paste by highlighting text semantics of X11.
  When working purely in X11 this is a nice feature, when working purely outside 
of X11 the lack of this feature isn't too much of an annoyance, but when working 
between an X window and a non-X window, the difference in behaviour is quite 
annoying.

However much fixing the deficiencies in Apple's X11 might improve the 
experience, it could not be as smooth an experience as a native interface.