Re: Aquamacs distro for OS X like behavior

[David Kastrup <dak@gnu.org>]

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

> On 4 Apr 2005, at 18:47, David Kastrup wrote:
>
>> There is considerable leeway in those goals.  For example,
>> different file selection dialogs and similar are quite common, and
>> in fact, the whole widgetry stuff (like customize and co) could be
>> made to make use of the native widgets where available.
>
>  From a UI and an OS X perspective, customization buffers should
>  definitely go into proper dialogues with native widgets.

I don't think this is OS X specific.  Mapping hierarchical widgets to
native constructs would be a lot of work.  Right now only atomic
widgets like the file selection dialog are, if at all, available.  I
think that some consensus, even if I can't remember this being
discussed before, could be achieved that this would be generally
desirable at least where the actions were mouse-induced: present
people with familiar interfaces.  There are drawbacks, like not being
able to use the power of Emacs' keyboard commands to manipulate
entries, but for people annoyed by that, there would always be the
possibility to configure the Emacs text widgets as default.

>> Well, we do have something like customization themes IIRC, but I
>> don't know their extent and how they are used.  If a whole set of
>> defaults were to be changed by a single theme (and could be changed
>> back at will), then an out-of-the-box configuration that was
>> different on MacOSX would be quite tolerable.
>
> I don't know if an out-of-the-box configuration for the default
> Emacs is needed - the idea of a distribution like what we
> demonstrate with Aquamacs might already do the job.

If you change options with setq, it becomes more troublesome to
customize them than if a theme was available.  Also it has the problem
that people used to NTEmacs can't easily get the same behavior from
Aquamacs and the other way round.  Shipping all Emacs versions with
both an NTEmacs and an Aquamacs customization theme would mean that
you get something set up to match your platform best as delivered, but
if you are already acquainted to the defaults of a different platform,
a single customization will turn your NTEmacs into an Aquamacs and the
other way round.

> Either way, merely using a 'theme' with the on-board means, for
> example to make customization buffers look different, will IMHO not
> tweak the application UI enough. A user interface is more than just
> pretty buttons and a choice of colors.

Customization themes in Emacs have nothing to do with pretty buttons
and choice of colors.  They are simply a single name for a complete
set of customized variable defaults.

[Other ramplings about "theme" removed]

> Consequently, I'm arguing for native widgets wherever possible. For
> a new project - or one with less tradition and less importance,
> there is stuff like wxWidgets. In this case, I would be grateful if
> someone would implement more Carbon (or Cocoa) based UI stuff, and
> if better internal interfaces existed, for example to handle
> scrollbars correctly. This is stuff only developers experienced with
> Emacs code - yes, you! - can implement.

This is stuff only developers experienced with the native scrollbars -
yes, you! - can implement.

Basically this needs knowledge of both the native widgets as well as
Emacs.  Your point of view is that other Emacs developers should be
forced to learn the details of the widgets of your platform.  Are you
going to buy me a Mac and developer information for that?  My point of
view is that it makes more sense if the Mac developers learn the
details of Emacs.  At least, both code and documentation for Emacs are
freely available, so you need not stumble around in the dark.  And you
can actually test what you are playing with, having a Macintosh
available.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum