Aquamacs distro for OS X like behavior

Aquamacs distro for OS X like behavior

[David Reitter]

Hi,

I would like to announce a new distribution for OS X, which we call 
'Aquamacs'. It's a ready-to-run application for OS X that combines the 
Carbon Emacs (a CVS build) with a range of packages and customizations 
from a number of people that all try to make Emacs behave more like a 
normal OS X application.

This includes keyboard shortcuts, a one-file-one-frame paradigm and a 
good-looking default font, plus other well-known add-ons that we 
consider standard on OS X.

The user-oriented description is at

	http://www.wordtech-software.com/Aquamacs.html

  and slightly more technical and opinionated introduction is provided 
here:

http://www.davids-world.com/archives/2005/04/aquamacs_an_ema.html

At this point, we consider the distribution experimental (it's version 
0.9). Kevin Walzer and I welcome your feedback.
Depending on whether people use it, we would work towards a 1.0. Source 
is provided in the .app bundle, except for what's in the CVS anyways.

-- Dave

Re: Aquamacs distro for OS X like behavior

[David Kastrup]

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

> I would like to announce a new distribution for OS X, which we call
> Aquamacs'. It's a ready-to-run application for OS X that combines
> the Carbon Emacs (a CVS build) with a range of packages and
> customizations from a number of people that all try to make Emacs
> behave more like a normal OS X application.

For starters, you could put up information about what you actually do
and include.  None of the referenced web sites bother to mention any
of the included packages.

> The user-oriented description is at
>
> 	http://www.wordtech-software.com/Aquamacs.html
>
>   and slightly more technical and opinionated introduction is provided
>   here:
>
> http://www.davids-world.com/archives/2005/04/aquamacs_an_ema.html
>
> At this point, we consider the distribution experimental (it's version
> 0.9). Kevin Walzer and I welcome your feedback.
> Depending on whether people use it, we would work towards a
> 1.0. Source is provided in the .app bundle, except for what's in the
> CVS anyways.

You make a big point out of berating the Emacs development team for a
lack of cooperation.  However, changes in user interface take a lot of
persuasion and preparative work as you can easily see if you follow
emacs-devel even superficially.  Emacs has a much longer history than
all currently "modern" (and conflicting) user interface guidelines.
Should one make people abandon Emacs that have been using it for 20
years, so that a newcomer will take an hour instead of half an hour
before giving up on it?

In addition, catering to the idiosyncrasies of a specific platform
like MacOSX is a lot of work if you want to keep Emacs fully
functional and reasonably consistent (where appropriate) across
platforms.

Given the amount of work that is needed for implementing and
harmonizing a platform specific port of Emacs, I can't help but notice
that your rants about Emacs developers at least to me appear somewhat
disproportionate with the amount of involvement I seem to remember
from you on this list.  So I recommend that you replace them with
actually mentioning what packages you are including in your offering,
and maybe thinking about how you could constructively help Emacs user
interface design while keeping in mind that there are more platforms
than just MacOSX around: this means that one has to make good choices
about where and how to modularize design decisions for a platform.

For the sake of consistency, it might be an idea at some point of time
to have, at least for a limited time period, a single person being
responsible for user interface decisions.  But this person needs to be
at least acquainted with all major user interfaces, and it would need
to have reasonably good contacts with active developers for all of
them.  I have actually played with the thought of offering to do that,
but my style of communication is likely to cause more permanent damage
than good in a sensitive area, and I don't have the time available to
invest myself that would be required for somebody taking the lead in
some area, even if just for making him appear a mostly uncontentious
necessary evil.

Anyway: interface work is hard work, and "let us do everything the
Apple way" is not going to cut it for a number of other platforms, so
in the core Emacs development it is important to keep track of how to
make it possible to do things the Apple, Windows, GNOME, whatever way
reasonably well without losing sight of the Emacs way.

If you want to invest your time in that area cooperatively, it
certainly would be appreciated, and the results would probably be
beneficial to Emacs at large, but you have to realize that moving
Emacs as a whole, while the most effective way in the long run, can be
lots of hard work and frustrating at times.  Of course, it is easier
to rant about how hard it would be instead of trying, but it probably
does not lead anywhere much.

Anyway, for the sake of projects of mine, I am glad that there at last
seems to be a precompiled recent Aqua version of the CVS Emacs around
again.

Without any usefully available information about what packages and
detailed changes from where have gone into it, I still can't recommend
it or give out instructions about how software is probably going to
get installed there.  So I recommend that you fix at least that
deficiency.  All other OSX compilations, outdated as they may be, at
least mention what they include into the package.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Aquamacs distro for OS X like behavior

[David Reitter]

Hi David,

thanks for your friendly comments.

You are of course very right in that we should list the packages that 
we include in the distribution. We haven't done so as we have included 
a lot of things from people's publicly available .emacs files in 
addition to a number of large customizations, e.g. those from Drew 
Adams. We will include a list pretty soon though.

Please note that I didn't complain a lot about a lack of cooperation or 
attack anyone, and I also didn't suggest to make the main-stream Emacs 
more OS X like ("let us do everything the Apple way").  If possible, I 
would very much like to see that Emacs /allows/ us to customize its UI 
for a particular environment.

We can certainly help if the friendly people handling the Mac port 
would like to pick up some of the UI elements, such as the keyboard 
shortcuts, which probably do not conflict with other functionality. I 
have submitted bug reports on other UI problems, such as the scrollbars 
(not fixed), or a little patch for the file selector (fixed) already.

Best
David

Re: Aquamacs distro for OS X like behavior

[Stefan Monnier]

> If possible, I would very much like to see that Emacs /allows/ us to
> customize its UI for a particular environment.

I think we all agree about it.

The mainstream Emacs will never be like the one you distribute because an
important consideration for it is that it should behave like Emacs
on other platforms, as opposed to your distribution which places more
emphasis on having it behave like other apps on Mac OS X.

But it's still a good goal to try and minimize the difference between
the two.  At least, to the point where your distribution is not a full
Emacs install but only an add-on.  An important consideration here is that
the same Emacs install should be able to accomodate users who want MacOSX
behavior and users who want Emacs behavior.


        Stefan

Re: Aquamacs distro for OS X like behavior

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> If possible, I would very much like to see that Emacs /allows/ us
>> to customize its UI for a particular environment.
>
> I think we all agree about it.
>
> The mainstream Emacs will never be like the one you distribute
> because an important consideration for it is that it should behave
> like Emacs on other platforms, as opposed to your distribution which
> places more emphasis on having it behave like other apps on Mac OS
> X.

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.

Emacs already tends to blend quite better with its environment than
XEmacs does (which looks like, well, XEmacs everywhere), and this is
not a mistake, in my opinion.

> But it's still a good goal to try and minimize the difference
> between the two.  At least, to the point where your distribution is
> not a full Emacs install but only an add-on.  An important
> consideration here is that the same Emacs install should be able to
> accomodate users who want MacOSX behavior and users who want Emacs
> behavior.

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.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Aquamacs distro for OS X like behavior

[David Reitter]

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.

>
> 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. People with other needs - a 
cross-platform compatible Emacs - will then be happy to use the 
'conservative' version instead.

I see a trend towards the first - UI integration - because it's more 
comfortable when you use a lot of applications (and people use more 
applications, not less), and there has been a great uptake on mobile 
devices: people use laptops much more than they used to (say, 7 years 
ago), and people don't switch from one system to another as often. Of 
course, individual mileage will vary!

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. If you look at the way themes work in 
GNOME / KDE, you'll find huge emphasis on the graphics, and only little 
theme-defined behavior and pretty much no theme-defined layout.

Successful OS X software pretty much always uses the native user 
interface. Even though OS X has superb Java integration (at least for 
not-quite-cutting-edge Java versions), we don't see many wide-spread 
Swing based applications. Similarly, the XUL based browser versions 
from Mozilla aren't as popular as Safari and Camino - even though they 
offer good or better functionality.

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.

- Dave

Re: Aquamacs distro for OS X like behavior

[David Kastrup]

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

Re: Aquamacs distro for OS X like behavior

[Stefan Monnier]

> 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.  People with other needs - a cross-platform
> compatible Emacs - will then be happy to use the 'conservative'
> version instead.

It does the job, but it's more work for you.  And having two slightly
different distributions is a pain in the rear.  Better to have one
distribution plus an add-on.  You can bundle them of course, but the point
is that I want to be able to install your Aquamacs (for other people) and
still use it as a "normal Emacs" myself.

> I see a trend towards the first - UI integration - because it's more

We're in favor of UI integration as well, mind you.  We just don't have the
manpower/experience/time/will to do more of it ourselves.  Note that UI
integration is different from issues such a default keybindings, etc...

> 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.

You're confused about what is meant by "theme" in the context of Custom.
It's new in Emacs-CVS and is still very poorly supported/documented, but the
basic idea is that you can take your .emacs and say "here is my
DavidReitterTheme".

> Consequently, I'm arguing for native widgets wherever possible.

You're preaching to the choir.  We're using native menus, native scrollbars,
native tooltips, ...

> In this case, I would be grateful if someone would implement
> more Carbon (or Cocoa) based UI stuff, and if better internal interfaces
> existed,

So would we.

> for example to handle scrollbars correctly.

Please report any complaint you have against the scrollbar with
M-x report-emacs-bug.


        Stefan

Re: Aquamacs distro for OS X like behavior

[David Reitter]

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


> You're confused about what is meant by "theme" in the context of  
> Custom.
> It's new in Emacs-CVS and is still very poorly supported/documented,  
> but the
> basic idea is that you can take your .emacs and say "here is my
> DavidReitterTheme".

Oh, then I see - well that's exactly what I would want. That would  
allow us to integrate something like an OS X theme without mandating  
it.  If such a theme would be supplied with a main version and switched  
on by default on OS X, I suppose one would want it to be well-tested.  
Even though the collection has been around for a while, I feel that we  
need some more feedback from users. We're getting this now - with some  
problems being genuinely due to our distribution.

>> for example to handle scrollbars correctly.
>
> Please report any complaint you have against the scrollbar with
> M-x report-emacs-bug.

I have reported this in various places, for example on  
emacs-pretest-bugs here:

http://lists.gnu.org/archive/html/emacs-pretest-bug/2004-03/ 
msg00110.html

and Steven Tamm and Yamamoto Mitsuharu have been made aware of it a  
while ago.
I have no plans to report the same problem again :-)

-- Dave



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

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Aquamacs distro for OS X like behavior

[Stefan Monnier]

>>> for example to handle scrollbars correctly.
>> Please report any complaint you have against the scrollbar with
>> M-x report-emacs-bug.
> I have reported this in various places, for example on
> emacs-pretest-bugs here:

> http://lists.gnu.org/archive/html/emacs-pretest-bug/2004-03/ msg00110.html

> and Steven Tamm and Yamamoto Mitsuharu have been made aware of it a  while
> ago.  I have no plans to report the same problem again :-)

Sorry I missed it.  I have no knowledge of Carbon Emacs, but I do have a lot
of experience trying to get non-Xaw scrollbars to work with Emacs.
So I can answer some of the issues you raise in your post:

> Under OS X, Emacs behaves very strangely with regard to the scrollbars and
> sliders. When you just click on a slider without moving it (after you've
> scrolled to the middle of the document), you will see that the text
> scrolls right away, often far beyond the document.  Intended behavior
> would be not to do anything.

The description of the behavior is not sufficiently precise for me to be
sure, but it looks like a genuine bug.  I'm not sure what you mean by "far
beyond the document", tho.

> When the slider is moved, scrolling looks fine at first.  However, I can
> then move beyond the document.

You mean you can scroll til the point where the very end of the document is
at the very top of the window.  That's normal Emacs behavior.  And there are
sound technical reasons why it's done this way.

> Good behavior under OS X would be to stop scrolling just when one line
> after the document is located at the bottom end of the screen
> (i.e. frame).

Other than being slightly different, in what case is it a problem?

The behavior you want is a behavior I find inconvenient in many cases
(e.g. I find it unpleasant to type text on the very last line of a window,
and I sometimes like to move the text higher up in the window (even if it's
at the bottom of the buffer) so I can align it on screen with some other
window's text).

I sometimes actually even wish the same would hold for the beginning of the
buffer (being able to place (point-min) at the bottom of the window).

> Also, during scrolling, the size of the slider changes. That should never
> be, as the size indicates the length of the document in relation to the size
> of the whole scrollbar.

That's exactly what it represent: the ratio slider/total is the same as the
ratio shownchars/buffercharsize.  But depending on where you are in the
buffer the window will not always show the same number of chars, so the size
of the slider changes accordingly.

In order for the slider to have a fixed size independent from the position
in the buffer it would have to show "shownpixels/bufferpixelsize".
Problem is that bufferpixelsize is very costly to compute so we currently
can't do that.

> That's an old paradigm! Consequently, the size of the slider only changes
> if the document size changes.

"Old paradigm" is not an argument I care about.  I still haven't heard of
any scenario where the current behavior causes an actual problem.  The worst
I've heard is that users are surprised and then go on with their life.
I've never heard of any user actually getting confused by it.

I'm not claiming that the current behavior is a feature, but I'm just saying
that the cost of a fix is just too high compared to the very minor
improvement it would bring.  Maybe the situation will be different ten years
from now, but before then I don't see things changing on this front.

BTW, in Emacs-CVS you can actually "try it out" by calling
`count-screen-lines'.  On reasonably large buffers, it takes a while.
Also the bufferpixelsize can be changed by font-lock fontification, so we'd
have to throw away jit-lock and go back to plain font-lock.

> Furthermore, clicking on one of the little arrows doesn't result in an
> immediate scroll action (one line). It only scrolls when the mouse button is
> released. Good behavior would be to scroll as soon as the button is down,
> and then scroll again (line by line, but continuously), after a short
> delay -- just like pressing a key will repeat that letter on and on after
> a delay.

That looks like a genuine bug.


        Stefan

Re: Scrollbar bug on OS X (was: Aquamacs distro for OS X like behavior)

[David Reitter]

On 6 Apr 2005, at 15:08, Stefan Monnier wrote:

>> Under OS X, Emacs behaves very strangely with regard to the 
>> scrollbars and
>> sliders. When you just click on a slider without moving it (after 
>> you've
>> scrolled to the middle of the document), you will see that the text
>> scrolls right away, often far beyond the document.  Intended behavior
>> would be not to do anything.
>
> The description of the behavior is not sufficiently precise for me to 
> be
> sure, but it looks like a genuine bug.  I'm not sure what you mean by 
> "far
> beyond the document", tho.

It overscrolls: it scrolls down beyond the end of the buffer, so that 
the screen is all empty.
It shouldn't jerk when you click and drag - very often, I grab the 
slider to scroll down a little. When the window jumps to a totally 
different document position, the slider becomes practically useless in 
that usage context.

I acknowledge your explanations on the other points - thanks. In the UI 
that I'd like to implement in order to conform to standards in my 
environment, the vertical slider size shows a proportion of _ displayed 
lines_ not document characters or real lines (those that end with a CR 
or LF). Whether that is better or not, I don't know, but what I do know 
is that a) "less visual change on the screen is more", and that b) both 
Windows and Mac software has sliders with a stable size.

But the slider size should have less priority.

Is there a way to store count-screen-lines statically and just update 
it when necessary?

-- Dave

Re: Scrollbar bug on OS X

[Stefan Monnier]

> I acknowledge your explanations on the other points - thanks. In the UI that
> I'd like to implement in order to conform to standards in my environment,
> the vertical slider size shows a proportion of _ displayed lines_ not
> document characters or real lines (those that end with a CR or LF). Whether

Since the height of lines can vary, the number of displayed lines can change
from one part of the buffer to another, so it's still not stable.
You really need to use the pixel size.

> visual change on the screen is more", and that b) both Windows and Mac
> software has sliders with a stable size.

The closest kind of software would be things like web-browsers for which
some details are relevant:
- the slider size changes as the page is being filled and rendered, so it's
  not nearly as stable as you make it out to be.
- html pages are typically small and web-browsers's algorithms are taylored
  for that case, they tend to become unusable when browsing large pages
  (like more than a megabyte), whereas it is considered important for Emacs
  to be able to comfortably edit multi-MB files (although there is also
  a limit).
- html-rendering becomes even more unusable if you start to actually
  interactively edit the 1MB page.
I.e. it's not just that Emacs hackers are incompetent, but it's that the
problem is difficult.

> Is there a way to store count-screen-lines statically and just update it
> when necessary?

Of course.  That's one of the tricks we'd have to use in order to get
"stable" slider sizes.  Problem is, I haven't yet heard of other useful
things we could do with that kind of extra info, so again: the amount of
work seems unjustified.


        Stefan

Re: Scrollbar bug on OS X (was: Aquamacs distro for OS X like behavior)

[Miles Bader]

On Apr 6, 2005 11:32 PM, David Reitter <david.reitter@gmail.com> wrote:
> that I'd like to implement in order to conform to standards in my
> environment, the vertical slider size shows a proportion of _ displayed
> lines_ not document characters or real lines (those that end with a CR
> or LF). Whether that is better or not, I don't know, but what I do know
> is that a) "less visual change on the screen is more", and that b) both
> Windows and Mac software has sliders with a stable size.

The only way I can see to truly have stable scroll-bar size is to base
the size calculation on displayed pixels (lines are not necessarily a
constant height, so the number of displayed lines is not a fixed
proportion of total lines in the document).

I'm curious how _any_ program manages to do this calculation in a
reasonable amount of time; do they really lay-out the _entire_
document ahead of time?  Do they use some sort of heuristic instead? 
What happens when the heuristic fails?

-MIles
-- 
Do not taunt Happy Fun Ball.

Re: Scrollbar bug on OS X

[David Kastrup]

Miles Bader <snogglethorpe@gmail.com> writes:

> On Apr 6, 2005 11:32 PM, David Reitter <david.reitter@gmail.com> wrote:
>> that I'd like to implement in order to conform to standards in my
>> environment, the vertical slider size shows a proportion of _ displayed
>> lines_ not document characters or real lines (those that end with a CR
>> or LF). Whether that is better or not, I don't know, but what I do know
>> is that a) "less visual change on the screen is more", and that b) both
>> Windows and Mac software has sliders with a stable size.
>
> The only way I can see to truly have stable scroll-bar size is to
> base the size calculation on displayed pixels (lines are not
> necessarily a constant height, so the number of displayed lines is
> not a fixed proportion of total lines in the document).

I think you are laboring under the delusion that the scroll bar
actually displays something sensible, namely that mouse-2 exactly at
the bottom of the slider will take you exactly one page of screen
material further.  I think you'll find that users are much less
surprised if this goal is not exactly established than if the slider
grows and shrinks in size.  So the solution is to base the slider size
on some more-or-less sensible metric like lines-in-file (where
available) to lines-on-screen, and anyway, don't muck with it while
dragging.

> I'm curious how _any_ program manages to do this calculation in a
> reasonable amount of time; do they really lay-out the _entire_
> document ahead of time?  Do they use some sort of heuristic instead?
> What happens when the heuristic fails?

What should happen?  The user will correct over/undershoot, probably
not even considering that the computer could be at fault.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Scrollbar bug on OS X

[Stefan Monnier]

> I think you are laboring under the delusion that the scroll bar
> actually displays something sensible, namely that mouse-2 exactly at
> the bottom of the slider will take you exactly one page of screen
> material further.  I think you'll find that users are much less
> surprised if this goal is not exactly established than if the slider
> grows and shrinks in size.  So the solution is to base the slider size
> on some more-or-less sensible metric like lines-in-file (where
> available) to lines-on-screen, and anyway, don't muck with it while
> dragging.

That's what the code does with the Motif scrollbar, BTW.
I think it's also what's used with Gtk.


        Stefan


PS: The only problem is that those toolkits have the idiotic idea to enforce
that the bottom of the thumb cannot go further than the bottom.  And they
enforce it by hiding the events corresponding to "user moves the mouse
yet-further-down".  I.e. they're throwing away valuable information before
the application can even decide whether it's indeed useless or not.
It's idiotic because it requires *more* code in the toolkit and has as its
only effect to reduce the flexibility of the toolkit.

Re: Scrollbar bug on OS X

[Richard Stallman]

    PS: The only problem is that those toolkits have the idiotic idea to enforce
    that the bottom of the thumb cannot go further than the bottom.  And they
    enforce it by hiding the events corresponding to "user moves the mouse
    yet-further-down".

I can talk with the GTK developers about this.  And also with the
LessTif developers.  Should I do that?

Re: Scrollbar bug on OS X

[Stefan Monnier]

>     PS: The only problem is that those toolkits have the idiotic idea to
>     enforce that the bottom of the thumb cannot go further than the
>     bottom.  And they enforce it by hiding the events corresponding to
>     "user moves the mouse yet-further-down".

> I can talk with the GTK developers about this.  And also with the
> LessTif developers.  Should I do that?

Feel free to try, but I don't have much hope:
- The LessTif people are probably bound by compatibility.
- The Gtk people are usually bound by dogmatism.


        Stefan

Re: Scrollbar bug on OS X

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>     PS: The only problem is that those toolkits have the idiotic
>>     idea to enforce that the bottom of the thumb cannot go further
>>     than the bottom.  And they enforce it by hiding the events
>>     corresponding to "user moves the mouse yet-further-down".
>
>> I can talk with the GTK developers about this.  And also with the
>> LessTif developers.  Should I do that?
>
> Feel free to try, but I don't have much hope:
> - The LessTif people are probably bound by compatibility.
> - The Gtk people are usually bound by dogmatism.

Didn't Miles in the context of "David would welcome Athena semantics
even with fancy-looking scrollbars" mention that it would be possible
to process the scrollbar events without even passing them into the
scrollbar widgets in the first place?

Looks like another reason here for thinking about that approach.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Scrollbar bug on OS X

[Jan D.]

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>>     PS: The only problem is that those toolkits have the idiotic
>>>     idea to enforce that the bottom of the thumb cannot go further
>>>     than the bottom.  And they enforce it by hiding the events
>>>     corresponding to "user moves the mouse yet-further-down".
>>
>>> I can talk with the GTK developers about this.  And also with the
>>> LessTif developers.  Should I do that?
>>
>> Feel free to try, but I don't have much hope:
>> - The LessTif people are probably bound by compatibility.
>> - The Gtk people are usually bound by dogmatism.
>
> Didn't Miles in the context of "David would welcome Athena semantics
> even with fancy-looking scrollbars" mention that it would be possible
> to process the scrollbar events without even passing them into the
> scrollbar widgets in the first place?
>
> Looks like another reason here for thinking about that approach.

It may have been me that said that.  I have tried that approach but 
there is some difficulties, i.e. not all parameters of the GTK 
scrollbar are available, most notably thumb pixel size.  But I've tried 
to get overscrolling better with this approach, Athena sematics may be 
easier to do.

	Jan D.

Re: Scrollbar bug on OS X

[David Reitter]

On 7 Apr 2005, at 20:30, David Kastrup wrote:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>>     PS: The only problem is that those toolkits have the idiotic
>>>     idea to enforce that the bottom of the thumb cannot go further
>>>     than the bottom.  And they enforce it by hiding the events
>>>     corresponding to "user moves the mouse yet-further-down".
>>
>>> I can talk with the GTK developers about this.  And also with the
>>> LessTif developers.  Should I do that?
>>
>> Feel free to try, but I don't have much hope:
>> - The LessTif people are probably bound by compatibility.
>> - The Gtk people are usually bound by dogmatism.
>
> Didn't Miles in the context of "David would welcome Athena semantics
> even with fancy-looking scrollbars" mention that it would be possible
> to process the scrollbar events without even passing them into the
> scrollbar widgets in the first place?

I understand something like that is happening in the mac port, which 
makes it very hard to get decent behavior in the first place.

Users exert their freedom to chose a particular UI environment. GTK can 
be seen as part of an environment, as it creates compatible behavior 
across applications. As mentioned earlier in this thread, UI is more 
than the pretty visual image of a widget - it's the behavior that 
counts.

Consistency is extremely important. While I respectfully disagree with 
Stefan's view that it is an "idiotic idea" to not let the 'thumb' 
extend beyond the bottom of the scrollbar, and while I think that this 
commonly used scrollbar behavior is actually consistent with the 
document/window metaphor put forward in most modern windowing 
environments since the mid-80's (which implies no over-scrolling), I 
think that a discussion about what the right behavior is is not 
necessary at all. Instead, suffice it to say that it should be up to 
the UI layer to implement the exact behavior.

That would respect the user's choice of environment (provided GTK 
implements things correctly.)

Re: Scrollbar bug on OS X

[Miles Bader]

On Apr 8, 2005 4:59 AM, David Reitter <david.reitter@gmail.com> wrote:
> Users exert their freedom to chose a particular UI environment. GTK can
> be seen as part of an environment, as it creates compatible behavior
> across applications. As mentioned earlier in this thread, UI is more
> than the pretty visual image of a widget - it's the behavior that
> counts.

Yeah, well as a user, I'm always a bit miffed by the all-or-nothing
attitudes of many GUI zealots.

As a user, I know that I choose an "environment" like GTK/Gnome
because I like the way it behaves/looks _on average_ better than other
choices.  None-the-less, there are very often things I dislike about
it, and I'm very appreciative when the GUI developer had the foresight
to allow me to override his defaults (however well considered they
are).

It's great to provide defaults that match expectations of the
majority, but die-hard dogmatism in the name of the "users" is not
great at all.

> Consistency is extremely important.

Consistent _defaults_, and guidelines that encourage consistent
behavior are good things; consistency at all costs often causes more
damage than good.

> while I think that this
> commonly used scrollbar behavior is actually consistent with the
> document/window metaphor put forward in most modern windowing
> environments since the mid-80's (which implies no over-scrolling)

Er, how exactly does the "document/window metaphor" imply no
over-scrolling?  It seems more a case of "gee maybe users will get
confused if their document is scrolled too much ... let's prevent it!"
(which is all fine and good, but it's merely a practical heuristic).

> Instead, suffice it to say that it should be up to
> the UI layer to implement the exact behavior.

The UI layer should be able to specify defaults; the final decision
should be up to the user.

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: Scrollbar bug on OS X

[David Reitter]

On 8 Apr 2005, at 03:05, Miles Bader wrote:

>> Instead, suffice it to say that it should be up to
>> the UI layer to implement the exact behavior.
>
> The UI layer should be able to specify defaults; the final decision
> should be up to the user.

Either the user choses an environment, i.e. operating system, that 
specifies these defaults, or he gets more fine-grained control over the 
interface. That's all fine - like I said in my earlier message: it 
shouldn't be up to the application. For that reason stuff like 
wxWidgets has architectural advantages over the non-native widgets used 
by GTK. Non-native UI usually doesn't feel as nice and comfortable. To 
give a practical example, Java Swing applications always feel clunky 
and somehow "not right" on the Mac. (But then again, I concede that Mac 
users tend to me more picky about UI than your average GNU/Linux or 
Windows user.)

Re: Scrollbar bug on OS X

[Stefan Monnier]

> Consistency is extremely important.

I think Ralph Waldo Emerson would disagree.

There's consistency and there's consistency.  In my experience, what people
care about is "in which direction and by how much does my thingy move when
I click with button X on part Y of the scrollbar" and "does the slider's
position and size reflect the part and quantity of my thingy that is
currently displayed".  The size of the slider while dragging is often
something they barely notice since while dragging they're not looking at the
scrollbar but at the thingy instead.  [ replace "thingy" with "buffer",
"spreadsheet", "html page", ...]

The precise size of a slider seems to only annoy GUI-fanatics (aka people
who know what is "the document/window metaphor"), and the only justification
I've ever heard for their complaint is "that's not how God meant it to
work", which reinforces me in my belief that it's just dogmatism rather than
an actual concern for the unenlightened user.

As for overscrolling: yes, it has puzzled a few users occasionally, because
it's not obvious where the buffer actually ends.  But note that this problem
is not specific to overscrolling since it already appears when viewing
a buffer too small to fill the window.

> While I respectfully disagree with Stefan's view that it is an "idiotic
> idea" to not let the 'thumb' extend beyond the bottom of the scrollbar,

The only reason why you disagree is because you haven't tried to write the
code that interfaces something like Emacs with one of those silly
scrollbars.  After working on such code you realize that GUI guidelines
might be great, but they shouldn't be "cast in code" directly in the GUI
library because there are always exceptions.


        Stefan

Re: Scrollbar bug on OS X

[David Reitter]

On 8 Apr 2005, at 13:42, Stefan Monnier wrote:

> There's consistency and there's consistency.  In my experience, what 
> people
> care about is "in which direction and by how much does my thingy move 
> when
> I click with button X on part Y of the scrollbar" and "does the 
> slider's
> position and size reflect the part and quantity of my thingy that is
> currently displayed".  The size of the slider while dragging is often
> something they barely notice since while dragging they're not looking 
> at the
> scrollbar but at the thingy instead.  [ replace "thingy" with "buffer",
> "spreadsheet", "html page", ...]

Of course there are priorities, and absolutely, the size of the 
scrollbar is less important than good scrolling behavior when you click 
underneath it or when you drag it. _Exact_ size - as pointed out by 
others before - might be totally unimportant.
As it stands now, the scrollbars are jerking around in size, however, 
and when you try to drag the scrollbar, the displayed portion of the 
buffer will jump somewhere unpredictable.

Anyways, can I as a user please get the freedom to configure whether I 
like over-scrolling or not?
( cf.   
http://lists.gnu.org/archive/html/emacs-devel/2003-03/msg00593.html )

> The only reason why you disagree is because you haven't tried to write 
> the
> code that interfaces something like Emacs with one of those silly
> scrollbars.  After working on such code you realize that GUI guidelines
> might be great, but they shouldn't be "cast in code" directly in the 
> GUI
> library because there are always exceptions.

What would be a good argument for such an exception?

The fact that it's hard to interface with the event-driven (or 
whatever) interface models of certain current APIs might be due to 
other players in this game than the UI toolkit.

Let's say one can state what would be good from a UI perspective, and 
then one will have to figure out what is reasonably doable from a 
technical standpoint. Arguments IMHO start with the user-centric view!

Either way, I would humbly suggest that the bugs be fixed first; I know 
it's hard and I know that I can't do it lacking knowledge of the 
technical implementation. And I understand these things are difficult, 
so I won't even try.

Re: Scrollbar bug on OS X

[Stefan Monnier]

> As it stands now, the scrollbars are jerking around in size, however, and
> when you try to drag the scrollbar, the displayed portion of the buffer will
> jump somewhere unpredictable.

Yes, and these are just plain bugs.

> Anyways, can I as a user please get the freedom to configure whether I like
> over-scrolling or not?

Of course, as soon as someone implements it.

>> The only reason why you disagree is because you haven't tried to write the
>> code that interfaces something like Emacs with one of those silly
>> scrollbars.  After working on such code you realize that GUI guidelines
>> might be great, but they shouldn't be "cast in code" directly in the GUI
>> library because there are always exceptions.
> What would be a good argument for such an exception?

Who cares?  Every rule bumps into an aexception sooner or later.
Every "model" or "metaphor" has its limits.

> The fact that it's hard to interface with the event-driven (or whatever)
> interface models of certain current APIs might be due to other players in
> this game than the UI toolkit.

Event-drivenness is usually just a technical detail which may make the code
ugly, buggy, and/or brittle, but rarely if ever has any real impact on the
feasible behavior.

> Let's say one can state what would be good from a UI perspective, and then
> one will have to figure out what is reasonably doable from a technical
> standpoint.  Arguments IMHO start with the user-centric view!

Who said otherwise?

> Either way, I would humbly suggest that the bugs be fixed first; I know it's
> hard and I know that I can't do it lacking knowledge of the technical
> implementation. And I understand these things are difficult, so I won't
> even try.

There's no evidence that it's hard, actually.  It's probably just plain and
simple bugs, and like most bugs they can probably appear trivial and obvious
if you happen to look at it from the right angle.  Give it a try.


        Stefan

Re: Scrollbar bug on OS X

[Kevin Rodgers]

Stefan Monnier wrote:
> As for overscrolling: yes, it has puzzled a few users occasionally, because
> it's not obvious where the buffer actually ends.  But note that this problem
> is not specific to overscrolling since it already appears when viewing
> a buffer too small to fill the window.

Why can't the overscrolled portion of the window (or any portion beyond
the end of the buffer) be displayed differently?  I think the fringe
face would be good for that.

-- 
Kevin Rodgers

Re: Scrollbar bug on OS X

[Eli Zaretskii]

> From: Kevin Rodgers <ihs_4664@yahoo.com>
> Date: Fri, 08 Apr 2005 09:46:23 -0600
> 
> Why can't the overscrolled portion of the window (or any portion beyond
> the end of the buffer) be displayed differently?  I think the fringe
> face would be good for that.

There's already an optional feature to do this:
default-indicate-unused-lines.

Re: Scrollbar bug on OS X

[Luc Teirlinck]

Kim Storm wrote:

   > From: Kevin Rodgers <ihs_4664@yahoo.com>
   > Date: Fri, 08 Apr 2005 09:46:23 -0600
   > 
   > Why can't the overscrolled portion of the window (or any portion beyond
   > the end of the buffer) be displayed differently?  I think the fringe
   > face would be good for that.

   There's already an optional feature to do this:
   default-indicate-unused-lines.

I am always wary about changing default values close before a release,
but in this case, it would seem completely harmless to enable this by
default.  This would make sense, since the purpose is to avoid
confusing inexperienced users, who would typically not worry about
customizing an option like this.

The description of the option in the Emacs manual needs updating
regardless, as it currently uses obsolete variable names.

Sincerely,

Luc.

Re: Scrollbar bug on OS X

[Miles Bader]

On Apr 10, 2005 1:04 AM, Luc Teirlinck <teirllm@dms.auburn.edu> wrote:
>    default-indicate-unused-lines.
> 
> I am always wary about changing default values close before a release,
> but in this case, it would seem completely harmless to enable this by
> default.

I seem to recall a previous flamewar about that...

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: Scrollbar bug on OS X

[Luc Teirlinck]

Miles Bader wrote:

   On Apr 10, 2005 1:04 AM, Luc Teirlinck <teirllm@dms.auburn.edu> wrote:
   >    default-indicate-unused-lines.
   > 
   > I am always wary about changing default values close before a release,
   > but in this case, it would seem completely harmless to enable this by
   > default.

   I seem to recall a previous flamewar about that...

I must have missed that one.  So much about it being "completely
harmless", I guess.

Sincerely,

Luc.

Re: Scrollbar bug on OS X

[Luc Teirlinck]

>From my previous message:

   The description of the option in the Emacs manual needs updating
   regardless, as it currently uses obsolete variable names.

I have just fixed this, since the required changes were trivial.

Sincerely,

Luc.

Re: Scrollbar bug on OS X

[Kevin Rodgers]

Eli Zaretskii wrote:
>>From: Kevin Rodgers <ihs_4664@yahoo.com>
>>Date: Fri, 08 Apr 2005 09:46:23 -0600
>>
>>Why can't the overscrolled portion of the window (or any portion beyond
>>the end of the buffer) be displayed differently?  I think the fringe
>>face would be good for that.
> 
> 
> There's already an optional feature to do this:
> default-indicate-unused-lines.

Wow, that is cool.  I don't know how I missed it!

-- 
Kevin Rodgers

Re: Scrollbar bug on OS X

[Jan D.]

>     PS: The only problem is that those toolkits have the idiotic idea 
> to enforce
>     that the bottom of the thumb cannot go further than the bottom.  
> And they
>     enforce it by hiding the events corresponding to "user moves the 
> mouse
>     yet-further-down".
>
> I can talk with the GTK developers about this.  And also with the
> LessTif developers.  Should I do that?

We already had this discussion, and Owen Taylor said (27 Mar 2003):

>  * Allowing dragging the scrollbar thumb past the end of the
>    trough is something I'm quite hesitant to do:
>
>     - It will look like a bug to the user
>     - Some themes may not be able to handle such a case nicely (think
>       of a theme where the stepper arrows are round circles in the
>       trough instead of being as wide as the trough ... in that
>       case the thumb can't simply be truncated by the stepper arrow)


http://lists.gnu.org/archive/html/emacs-devel/2003-03/msg00609.html

	Jan D.

Re: Scrollbar bug on OS X

[Richard Stallman]

I looked back at the 2003 conversation.  Taylor simply refused to
implement behavior that fits logically with Emacs, demanding that we
change Emacs to put actual blank lines in the bottom of the screen.

It would be absurd to change Emacs's text model to fit the demands of
a GUI toolkit.  However, we could consider computing the "total size"
for scrolling to include N fictitious final blank lines, N = window
height.

With this technique, the slider would not touch the bottom until you
have scrolled as far as you can.

This has an undesirable feature: it would mean that you can't scroll
to put point-max at the bottom of the screen just by looking at the
scroll bar.  However, I am not sure that matters terribly, since you
can manage to see when you're at the end in other ways (such as by
looking for Bot in the mode line).  Also, it avoids another
undesirable feature, which is that the visible slider would shrink as
fewer lines remain at the top of the screen.

Perhaps we should try this for GTK and LessTif scroll bars.

Re: Scrollbar bug on OS X

[Stefan Monnier]

> It would be absurd to change Emacs's text model to fit the demands of
> a GUI toolkit.  However, we could consider computing the "total size"
> for scrolling to include N fictitious final blank lines, N = window
> height.

> With this technique, the slider would not touch the bottom until you
> have scrolled as far as you can.

AFAIK that's what we do for LessTif and Gtk,


        Stefan

Re: Scrollbar bug on OS X

[Richard Stallman]

    > It would be absurd to change Emacs's text model to fit the demands of
    > a GUI toolkit.  However, we could consider computing the "total size"
    > for scrolling to include N fictitious final blank lines, N = window
    > height.

    AFAIK that's what we do for LessTif and Gtk,

Jan, is that what we do for GTK?

Re: Scrollbar bug on OS X

[Jan D.]

>> It would be absurd to change Emacs's text model to fit the demands of
>> a GUI toolkit.  However, we could consider computing the "total size"
>> for scrolling to include N fictitious final blank lines, N = window
>> height.
>
>     AFAIK that's what we do for LessTif and Gtk,
>
> Jan, is that what we do for GTK?

Yes,and for Lesstif/Motif.  There has been bug reports on this 
approach.  The main confusion seems to be that when a small buffer is 
used (like the three initial lines in the *scratch* buffer), the 
scrollbar thumb does not extend to the bottom, since we have added the 
fictitious lines at the bottom.  The assumtion is that if you are 
seeing the whole buffer, the scroll bar thumb should indicate that by 
extending from top to bottom.

	Jan D.

Re: Scrollbar bug on OS X

[Miles Bader]

On 4/10/05, Jan D. <jan.h.d@swipnet.se> wrote:
> Yes,and for Lesstif/Motif.  There has been bug reports on this
> approach.  The main confusion seems to be that when a small buffer is
> used (like the three initial lines in the *scratch* buffer), the
> scrollbar thumb does not extend to the bottom, since we have added the
> fictitious lines at the bottom.  The assumtion is that if you are
> seeing the whole buffer, the scroll bar thumb should indicate that by
> extending from top to bottom.

Yes; while this workaround allows the scrollbar to be used fully, it's
just that -- a workaround.  It makes the scrollbar display quite
unintuitive in the (common) situation Jan described.

[IOW, the GTK maintainers aren't off the hook yet... :-]

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: Scrollbar bug on OS X

[Richard Stallman]

    Yes,and for Lesstif/Motif.  There has been bug reports on this 
    approach.  The main confusion seems to be that when a small buffer is 
    used (like the three initial lines in the *scratch* buffer), the 
    scrollbar thumb does not extend to the bottom, since we have added the 
    fictitious lines at the bottom.  The assumtion is that if you are 
    seeing the whole buffer, the scroll bar thumb should indicate that by 
    extending from top to bottom.

Yes, it is not perfect.  But all the alternatives have drawbacks.
This might be the best of all the possibilities.

Re: Scrollbar bug on OS X

[Stefan Monnier]

> I'm curious how _any_ program manages to do this calculation in a
> reasonable amount of time; do they really lay-out the _entire_
> document ahead of time?

AFAIK, yes.  HTML rendering engines do the rendering "eagerly" as they
receive the HTML data.  They typically do it in a separate thread, so while
the page is being rendered things aren't stable on screen (objects may
still move, and the slider may change size).


        Stefan

Re: Scrollbar size flaky on OS X (was: Aquamacs distro for OS X like behavior)

[David Reitter]

Addendum:

> That's exactly what it represent: the ratio slider/total is the same 
> as the
> ratio shownchars/buffercharsize.  But depending on where you are in the
> buffer the window will not always show the same number of chars, so 
> the size
> of the slider changes accordingly.

Not sure if that gets updated correctly.
Take a look at the three screenshots I put up here:

http://homepages.inf.ed.ac.uk/dreitter/scrollbar-issue/

You'll see some random document in a buffer. Screenshots 1 and 2 show 
different parts of the document, and you see that the slider has a 
totally different size. To me as a user, it looks like we're seeing 
about the same amount of the buffer in the window. So why does the 
slider have a different size?
If I play around (scroll back and forth) a little more, you can see 
what happens - screenshot 3 shows the same portion of the buffer as in 
2, but this time with a very small slider.

According to your explanation and looking at the size of the buffer, 
screenshots 1 and 3 are correct, but 2 is not.

-- Dave

Re: Scrollbar size flaky on OS X

[Stefan Monnier]

>> That's exactly what it represent: the ratio slider/total is the same as
>> the
>> ratio shownchars/buffercharsize.  But depending on where you are in the
>> buffer the window will not always show the same number of chars, so the
>> size
>> of the slider changes accordingly.

> Not sure if that gets updated correctly.
> Take a look at the three screenshots I put up here:

> http://homepages.inf.ed.ac.uk/dreitter/scrollbar-issue/

> You'll see some random document in a buffer. Screenshots 1 and 2 show
> different parts of the document, and you see that the slider has a totally
> different size. To me as a user, it looks like we're seeing about the same
> amount of the buffer in the window. So why does the slider have
> a different size?
> If I play around (scroll back and forth) a little more, you can see what
> happens - screenshot 3 shows the same portion of the buffer as in 2, but
> this time with a very small slider.

> According to your explanation and looking at the size of the buffer,
> screenshots 1 and 3 are correct, but 2 is not.

Looks like a bug indeed.


        Stefan

Re: Aquamacs distro for OS X like behavior

[Richard Stallman]

     From a UI and an OS X perspective, customization buffers should 
    definitely go into proper dialogues with native widgets.

Most cases, perhaps nearly all, would be easily handled with those
native widgets.  But it might be hard to make this support everything
that Emacs customizations actually do.

Meanwhile, we could afford to maintain this for one set of widgets,
such as GTK.  But if the idea were to use the native widget set of
every system, you're talking about a tremendous amount of work.

    Successful OS X software pretty much always uses the native user 
    interface.

The purpose of Emacs is to enhance the GNU operating system of which
it is part, and thus to contribute to the liberation of computer users
from non-free software.

Mac OS is a non-free operating system.  Viewed amorally, as mere
technology, it may be useful; but it is fundamentally unethical.
Our goal is to replace it with free software, not to enhance it.
To produce "successful OS X software" is a distraction from the goal.

Re: Aquamacs distro for OS X like behavior

[Lennart Borgman]

----- Original Message ----- 
From: "Richard Stallman" <rms@gnu.org>

> Meanwhile, we could afford to maintain this for one set of widgets,
> such as GTK.  But if the idea were to use the native widget set of
> every system, you're talking about a tremendous amount of work.

What about wxwidgets?

Re: Aquamacs distro for OS X like behavior

[Richard Stallman]

    What about wxwidgets?

I don't know anything about them technically, but if they make
the job easier and they are free software, there is no theoretical
reason we could not use them.

However, our priority should be GTK, I think.

Re: Aquamacs distro for OS X like behavior

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     What about wxwidgets?
>
> I don't know anything about them technically, but if they make
> the job easier and they are free software, there is no theoretical
> reason we could not use them.
>
> However, our priority should be GTK, I think.

wxwidgets take GTK+ as one of their backends, so one does not exclude
the other.  However, AFAICS wxwidgets supports just C++.  I don't
think that it would make sense to move Emacs to C++.

Also they are third-party software.  Basing Emacs ports to rely on
them in favor of other approaches would seem like a strategical risk
to me.  Such a commitment, I think, would require some securities.

Anyway, given the C++ problem, I don't think that we need to think
about that.

If somebody wants to invest time taking a look how to combine Emacs
with xwidgets without having to replace our build and memory
allocation infra structure, that's fine.  But I can't see it as a
viable porting path at the moment.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Aquamacs distro for OS X like behavior

[Richard Stallman]

    wxwidgets take GTK+ as one of their backends, so one does not exclude
    the other.  However, AFAICS wxwidgets supports just C++.  I don't
    think that it would make sense to move Emacs to C++.

Yes, that is a pretty severe drawback.  Thanks for analyzing the issue.

Re: Aquamacs distro for OS X like behavior

[Lennart Borgman]

----- Original Message ----- 
From: "Richard Stallman" <rms@gnu.org>
To: "David Kastrup" <dak@gnu.org>
Cc: <lennart.borgman.073@student.lu.se>; <monnier@iro.umontreal.ca>;
<david.reitter@gmail.com>; <emacs-devel@gnu.org>
Sent: Thursday, April 07, 2005 8:27 PM
Subject: Re: Aquamacs distro for OS X like behavior


>     wxwidgets take GTK+ as one of their backends, so one does not exclude
>     the other.  However, AFAICS wxwidgets supports just C++.  I don't
>     think that it would make sense to move Emacs to C++.
>
> Yes, that is a pretty severe drawback.  Thanks for analyzing the issue.

I wrote to wx-users@lists.wxwidgets.org and asked and got this promising
answer (and some other too):

> Can wxWidgets be used from C?

You might want to have a look at wx.NET (the C# bindings
for wxWidgets) which have (or at least used to have)
intermediate C-bindings.

  mvh,

   Robert Roebling

Re: Aquamacs distro for OS X like behavior

[Johan Vromans]

"Lennart Borgman" <lennart.borgman.073@student.lu.se> writes:

>> Yes, that is a pretty severe drawback.  Thanks for analyzing the issue.
>
> I wrote to wx-users@lists.wxwidgets.org and asked and got this promising
> answer (and some other too):

Also, I think the number of widgets that emacs will use is rather
limited.

-- Johan

Re: Aquamacs distro for OS X like behavior

[David Reitter]

On 8 Apr 2005, at 10:17, Johan Vromans wrote:

> Also, I think the number of widgets that emacs will use is rather
> limited.

Using a UI toolkit represents a long-term commitment. Given that UI 
toolkits seem to live in a fashion-driven biosphere, it might be 
interesting to consider alternatives.

How about documenting interfaces for the most commonly used functions, 
starting with tasks where a good GUI would be helpful? For example, one 
could define a structured language to serialize customization settings, 
which could then be parsed by little external modules - written by the 
community or the port people in order to implement system-native 
behavior. This would not preclude the use of the default behavior, i.e. 
customization buffers. I understand (and I know very little about the 
technical side of emacs!) that custom options have such an API anyways 
- it would come down to defining a serialization (to write stuff into a 
file and read it out again) and an update protocol.

Re: Aquamacs distro for OS X like behavior

[Richard Stallman]

    How about documenting interfaces for the most commonly used functions, 
    starting with tasks where a good GUI would be helpful? For example, one 
    could define a structured language to serialize customization settings, 
    which could then be parsed by little external modules - written by the 
    community or the port people in order to implement system-native 
    behavior. This would not preclude the use of the default behavior,

This sounds like a research project to me.  It might be an interesting
research project, for whoever is minded to do research in this area.

Re: Aquamacs distro for OS X like behavior

[Richard Stallman]

    Emacs already tends to blend quite better with its environment than
    XEmacs does (which looks like, well, XEmacs everywhere), and this is
    not a mistake, in my opinion.

To the extent that we can make Emacs fit the general GUI environment
without altering the core features of Emacs, it is a usually good
thing to do so.  I would be against altering keyboard keys, except
in very narrow was such as swapping DEL and BS.  And changing the main
mouse commands such as Mouse-1 between systems seems like a bad idea too.

Re: Aquamacs distro for OS X like behavior

[Aidan Kehoe]

 Ar an ceathrú lá de mí Aibréan, scríobh David Kastrup: 

 > [...] Should one make people abandon Emacs that have been using it for 20
 > years, so that a newcomer will take an hour instead of half an hour
 > before giving up on it?

That’s a false dichotomy; people who have been using some form of Emacs for
twenty years are informed enough to be able to configure their way around
the new defaults. New users, very much less so.

 > In addition, catering to the idiosyncrasies of a specific platform like
 > MacOSX is a lot of work if you want to keep Emacs fully functional and
 > reasonably consistent (where appropriate) across platforms.

Certainly, but most of the work should be up-front--assuming stuff like
cua-mode keeps respecting the Apple key--and they’re volunteering to do
it. And, given that Andrew Choi is gone, and the Carbon port is very much
alive, it seems there is and will be a decent userbase prepared to
support GNU Emacs on that platform. 

 > [snipping stuff on the GUI development of GNU Emacs and the package list
 > of this package, neither of which I have much interest in.]

-- 
“I, for instance, am gung-ho about open source because my family is being
held hostage in Rob Malda’s basement. But who fact-checks me, or Enderle,
when we say something in public? No-one!” -- Danny O’Brien

Re: Aquamacs distro for OS X like behavior

[Eli Zaretskii]

> From: Aidan Kehoe <kehoea@parhasard.net>
> Date: Mon, 4 Apr 2005 20:25:20 +0200
> Cc: David Reitter <david.reitter@gmail.com>, emacs-devel@gnu.org
> 
>  > [...] Should one make people abandon Emacs that have been using it for 20
>  > years, so that a newcomer will take an hour instead of half an hour
>  > before giving up on it?
> 
> That's a false dichotomy; people who have been using some form of Emacs for
> twenty years are informed enough to be able to configure their way around
> the new defaults.

That depends on the amount of configuring around the defaults.  If
that amount gets too large, I, for one, would be very unpleased.  I
use Emacs for productivity, not for the dubious pleasure of wasting my
time hunting down new defaults that make Emacs behave contrary to my
expectations.

Please also don't forget that quite a few veteran Emacs users
routinely work with several different Emacs versions on different
machines, so having too many differences between versions means those
Emacs veterans will have hard time crafting customizations that work
with all of the versions.