Re: Carbon: window close via accessibility API is broken
On 6 Sep 2006, at 01:50, YAMAMOTO Mitsuharu wrote: On Tue, 05 Sep 2006 09:37:15 +0900, YAMAMOTO Mitsuharu <[EMAIL PROTECTED]> said: It can be handled with Carbon events in kEventClassWindow. kEventWindowClose for the Close button. kEventWindowGetIdealSize and kEventWindowBoundsChanged for the Maximize button. The former is easy to handle and I'll install a handler. But the latter is not so straightforward and it may conflict with the existing code because kEventWindowBoundsChanged is called in various situations. Here's a patch for the zoom button (sorry, it was not the Maximize button). Yes, this does the job nicely for Maximize. AXPress on Close and Minimize works, too. Thanks on behalf of those who need it! - David smime.p7s Description: S/MIME cryptographic signature ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Carbon: window close via accessibility API is broken
> On Tue, 05 Sep 2006 09:37:15 +0900, YAMAMOTO Mitsuharu <[EMAIL
> PROTECTED]> said:
> It can be handled with Carbon events in kEventClassWindow.
> kEventWindowClose for the Close button. kEventWindowGetIdealSize
> and kEventWindowBoundsChanged for the Maximize button. The former
> is easy to handle and I'll install a handler. But the latter is not
> so straightforward and it may conflict with the existing code
> because kEventWindowBoundsChanged is called in various situations.
Here's a patch for the zoom button (sorry, it was not the Maximize
button).
YAMAMOTO Mitsuharu
[EMAIL PROTECTED]
*** macterm.c.~1.187.~ Tue Sep 5 10:04:06 2006
--- macterm.c Wed Sep 6 09:47:34 2006
***
*** 5805,5810
--- 5805,5861
#endif /* not TARGET_API_MAC_CARBON */
}
+ static void
+ mac_handle_origin_change (f)
+ struct frame *f;
+ {
+ x_real_positions (f, &f->left_pos, &f->top_pos);
+ }
+
+ static void
+ mac_handle_size_change (f, pixelwidth, pixelheight)
+ struct frame *f;
+ int pixelwidth, pixelheight;
+ {
+ int cols, rows;
+
+ cols = FRAME_PIXEL_WIDTH_TO_TEXT_COLS (f, pixelwidth);
+ rows = FRAME_PIXEL_HEIGHT_TO_TEXT_LINES (f, pixelheight);
+
+ if (cols != FRAME_COLS (f)
+ || rows != FRAME_LINES (f)
+ || pixelwidth != FRAME_PIXEL_WIDTH (f)
+ || pixelheight != FRAME_PIXEL_HEIGHT (f))
+ {
+ /* We pass 1 for DELAY since we can't run Lisp code inside of
+a BLOCK_INPUT. */
+ change_frame_size (f, rows, cols, 0, 1, 0);
+ FRAME_PIXEL_WIDTH (f) = pixelwidth;
+ FRAME_PIXEL_HEIGHT (f) = pixelheight;
+ SET_FRAME_GARBAGED (f);
+
+ /* If cursor was outside the new size, mark it as off. */
+ mark_window_cursors_off (XWINDOW (f->root_window));
+
+ /* Clear out any recollection of where the mouse highlighting
+was, since it might be in a place that's outside the new
+frame size. Actually checking whether it is outside is a
+pain in the neck, so don't try--just let the highlighting be
+done afresh with new size. */
+ cancel_mouse_face (f);
+
+ #if TARGET_API_MAC_CARBON
+ if (f->output_data.mac->hourglass_control)
+ {
+ #if USE_CG_DRAWING
+ mac_prepare_for_quickdraw (f);
+ #endif
+ MoveControl (f->output_data.mac->hourglass_control,
+ pixelwidth - HOURGLASS_WIDTH, 0);
+ }
+ #endif
+ }
+ }
/* Calculate the absolute position in frame F
***
*** 5885,5891
ConstrainWindowToScreen (FRAME_MAC_WINDOW (f), kWindowTitleBarRgn,
kWindowConstrainMoveRegardlessOfFit
| kWindowConstrainAllowPartial, NULL, NULL);
! x_real_positions (f, &f->left_pos, &f->top_pos);
#else
{
Rect inner, outer, screen_rect, dummy;
--- 5936,5945
ConstrainWindowToScreen (FRAME_MAC_WINDOW (f), kWindowTitleBarRgn,
kWindowConstrainMoveRegardlessOfFit
| kWindowConstrainAllowPartial, NULL, NULL);
! #if USE_CARBON_EVENTS
! if (!NILP (tip_frame) && XFRAME (tip_frame) == f)
! #endif
! mac_handle_origin_change (f);
#else
{
Rect inner, outer, screen_rect, dummy;
***
*** 5959,6008
x_wm_set_size_hint (f, (long) 0, 0);
SizeWindow (FRAME_MAC_WINDOW (f), pixelwidth, pixelheight, 0);
- #if TARGET_API_MAC_CARBON
- if (f->output_data.mac->hourglass_control)
- {
- #if USE_CG_DRAWING
- mac_prepare_for_quickdraw (f);
- #endif
- MoveControl (f->output_data.mac->hourglass_control,
- pixelwidth - HOURGLASS_WIDTH, 0);
- }
- #endif
! /* Now, strictly speaking, we can't be sure that this is accurate,
! but the window manager will get around to dealing with the size
! change request eventually, and we'll hear how it went when the
! ConfigureNotify event gets here.
!
! We could just not bother storing any of this information here,
! and let the ConfigureNotify event set everything up, but that
! might be kind of confusing to the Lisp code, since size changes
! wouldn't be reported in the frame parameters until some random
! point in the future when the ConfigureNotify event arrives.
!
! We pass 1 for DELAY since we can't run Lisp code inside of
! a BLOCK_INPUT. */
! change_frame_size (f, rows, cols, 0, 1, 0);
! FRAME_PIXEL_WIDTH (f) = pixelwidth;
! FRAME_PIXEL_HEIGHT (f) = pixelheight;
!
! /* We've set {FRAME,PIXEL}_{WIDTH,HEIGHT} to the values we hope to
! receive in the ConfigureNotify event; if we get what we asked
! for, then the event won't cause the screen to become garbaged, so
! we have to make sure to do it here. */
! SET_FRAME_GARBAGED (f);
!
! XFlush (FRAME_X_DISPLAY (f));
!
! /* If cursor was outside the new size, mark it as off. */
! mark_wind
Re: Carbon: window close via accessibility API is broken
> On Mon, 4 Sep 2006 16:50:45 +0100, David Reitter <[EMAIL PROTECTED]> said: > 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.) Thanks for the report. I could reproduce the problem. > 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?). It can be handled with Carbon events in kEventClassWindow. kEventWindowClose for the Close button. kEventWindowGetIdealSize and kEventWindowBoundsChanged for the Maximize button. The former is easy to handle and I'll install a handler. But the latter is not so straightforward and it may conflict with the existing code because kEventWindowBoundsChanged is called in various situations. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Carbon: window close via accessibility API is broken
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?). Thanks - David Begin forwarded message: From: Alexis Gallagher <[EMAIL PROTECTED]> Date: 4 September 2006 16:23:23 BDT To: David Reitter <[EMAIL PROTECTED]> Subject: Re: [Aquamacs-bugs] window close via accessibility API is broken David, 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. cheers, alexis On 4 Sep 2006, at 15:39, David Reitter wrote: Alexis, 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/ aquamacsshot.jpg In GNU Emacs 22.0.50.1 (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
