[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Carbon: window close via accessibility API is broken

From: David Reitter
Subject: Carbon: window close via accessibility API is broken
Date: Mon, 4 Sep 2006 16:50:45 +0100

Emacs (Carbon port) seems to have trouble with Accessibility API events.

- AXPress action on the Closer button of a frame doesn't do anything
- AXPress action on Minimize seems to work
- AXPress action on Maximize produces garbage, with the window width being wrong. Subsequent manual redraws or scrolling lead to worse garbage. (I can make a screenshot available if needed.)

I'm attaching a user's bug report (below) with regard to AXPress on the Closer, which I can reproduce as described by him.

I looked into the reference documents he mentions but I couldn't see what events we're waiting for, and why this click on the window closer needs to be dealt with separately (does it?).

- David

Begin forwarded message:

From: Alexis Gallagher <address@hidden>
Date: 4 September 2006 16:23:23 BDT
To: David Reitter <address@hidden>
Subject: Re: [Aquamacs-bugs] window close via accessibility API is broken


Yes. I mispoke to call them the "Cocoa accessibilty event actions". They are not Cocoa-specific. Both Carbon and Cocoa apps can support the accessibility api and in theory they both should. In practice, much of this support comes automatically in Cocoa. It requires a bit of work in Carbon, where it is therefore often neglected.

Here are two relevant pages for understanding how it's supposed to work:

This Apple developer document "Getting Started with Accessibility", especially the subsection "Developing an application", links out to the differences between Cocoa and Carbon support:

http://developer.apple.com/referencelibrary/GettingStarted/ GS_Accessibility/

Another relevant page for background is the section "The Mac OS X Accessibility Protocol" in the "Accessibility Overview" document:

http://developer.apple.com/documentation/Accessibility/Conceptual/ AccessibilityMacOSX/index.html#//apple_ref/doc/uid/TP40001078

Before filing the bug, I pulled the source from cvs and tried to to understand where the relevant changes would go. But C is not my strong suit, I've never touched a project of that size before, and I got lost pretty quickly. Also I had some kind of problem with the build script. So I thought it'd wiser just to document the bug as accurately as possible. I hope this helps.


On 4 Sep 2006, at 15:39, David Reitter wrote:


is this API supposed to be supported by Carbon applications as well?

Aquamacs isn't Cocoa-based, yet.

- David

On 4 Sep 2006, at 15:19, Alexis Gallagher wrote:

I believe Aquamacs does not correctly support the Cocoa
accessibiltity event actions for closing a window.

I noticed this because I use a program called "Witch", a Preference
Pane which offers enhanced keyboard controls for switching between
applications and menus (http://www.petermaurer.de/nasi.php?
section=witch). This app uses the accessibility API to send apps
instructions to close individual windows. I have encoutered only two
apps don't respond to those commands correctly: Firefox and Aquamacs.
This is a known issue in Firefox. It seems worth reporting it for
Aquamacs as well.

You can verify this behavior by using the Accessibility Inspector
tool to artificially generate an AXPress event on the close button of
an Aquamacs window.  Here's how.

1) Open two frames in Aquamacs
2) Open the Accessibility Inspector (/Developer/Applications/
Utilities/Accessibility Tools/Accessibility Inspector.app)
3) Place the mouse pointer over an Aquamacs window's close button
4) Type CMD-F7 to lock on that UIElement wih Accessibility Inspector
5) Hit the Perform button, which will generate an AXPress action on
the close button through the accessibility API
6) Notice that the Aquamacs window fails to close, which it should do.

Since I don't know if the bug tracking machinery can take
attachments, I am hosting a screenshot which demonstrates the exact
behavior at the following address: http://www.alexisgallagher.com/

In GNU Emacs (i386-apple-darwin8.6.1)
  of 2006-06-27 on plume.sr.unh.edu - Aquamacs Distribution 0.9.9d
X server distributor `Apple Computers', version 10.4.7
configured using `configure '--without-x' '--prefix=/usr/local''

Important settings:
   value of $LC_ALL: nil
   value of $LC_COLLATE: nil
   value of $LC_CTYPE: nil
   value of $LC_MESSAGES: nil
   value of $LC_MONETARY: nil
   value of $LC_NUMERIC: nil
   value of $LC_TIME: nil
   value of $LANG: nil
   locale-coding-system: iso-8859-1
   default-enable-multibyte-characters: t

Major mode: Text

Minor modes in effect:
   iswitchb-mode: t
   shell-dirtrack-mode: t
   smart-frame-positioning-mode: t
   aquamacs-styles-mode: t
   recentf-mode: t
   encoded-kbd-mode: t
   osx-key-mode: t
   mac-inline-input-method-mode: t
   show-paren-mode: t
   delete-selection-mode: t
   pc-selection-mode: t
   cua-mode: t
   tooltip-mode: t
   mouse-wheel-mode: t
   menu-bar-mode: t
   file-name-shadow-mode: t
   global-font-lock-mode: t
   font-lock-mode: t
   blink-cursor-mode: t
   unify-8859-on-encoding-mode: t
   utf-translate-cjk-mode: t
   auto-compression-mode: t
   column-number-mode: t
   line-number-mode: t
   transient-mark-mode: t

Recent input:
h t t p : / / w w w . g o o g l e . c o m C-a C-c m
b r o <backspace> o w s e SPC u r l <return> <return>
C-k <menu-bar> <help-menu> <report-emacs-bug>

Recent messages:
Loading cl-extra...done
Loading /Users/alexis/.xemacs/haskell/haskell-mode-2.1/haskell-site-
file.el (source)...done
Loading iswitchb...done
Loading /Users/alexis/.xemacs/init.el (source)...done
Loading /Users/alexis/Library/Preferences/Aquamacs Emacs/
customizations.el (source)...done
Loading /Users/alexis/Library/Preferences/Aquamacs Emacs/frame-
positions.el (source)...done
For an introduction to Aquamacs Emacs, type Apple-?. Copyright (C)
2006 Free
Software Foundation, Inc., & D. Reitter. No Warranty. You may
Aquamacs under the GNU General Public License. Type C-h C-c to view.
Loading emacsbug...done


reply via email to

[Prev in Thread] Current Thread [Next in Thread]