RE: Accessibility-dev Digest, Vol 4, Issue 73
RE: Accessibility-dev Digest, Vol 4, Issue 73
- Subject: RE: Accessibility-dev Digest, Vol 4, Issue 73
- From: "Andrew Quinn" <email@hidden>
- Date: Tue, 27 Nov 2007 08:05:47 -0000
OK, thanks
If you can send me the deck as soon as its done I will send out
Also - had a good chat with Mark yesterday and in summary he is in more than
ever and wants to increase his holding.
I am drafting a short proposal for him to discuss with peter tonight around
a loan for Ecosoft with good returns.
Also - you mentioned a while ago a personal friend of Rhona who is a private
investor, did you manage to speak with them?
Talk later
Thanks
Andy
Andrew Quinn
Chief Executive & Founder
Ecosoft
T - +44 (0) 207 887 6018
F - +44 (0) 207 887 6001
M - +44 (0) 7977 539 680
W - www.ecosoft-global.com
Berkeley Square House, Berkeley Square
London, W1J 6BD
Carbon Emission Reductions
-----Original Message-----
From: accessibility-dev-bounces+aquinn=email@hidden
[mailto:accessibility-dev-bounces+aquinn=email@hidden]
On Behalf Of email@hidden
Sent: 26 November 2007 20:02
To: email@hidden
Subject: Accessibility-dev Digest, Vol 4, Issue 73
Send Accessibility-dev mailing list submissions to
email@hidden
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.apple.com/mailman/listinfo/accessibility-dev
or, via email, send a message with subject or body 'help' to
email@hidden
You can reach the person managing the list at
email@hidden
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Accessibility-dev digest..."
Today's Topics:
1. Re: AXPosition and AXSize during window drags (Eric Schlegel)
2. Re: AXPosition and AXSize during window drags (Michael Ash)
3. Re: AXPosition and AXSize during window drags (Bill Cheeseman)
4. Re: AXPosition and AXSize during window drags (Bill Cheeseman)
5. Re: AXPosition and AXSize during window drags (James Dempsey)
----------------------------------------------------------------------
Message: 1
Date: Sun, 25 Nov 2007 19:42:24 -0800
From: Eric Schlegel <email@hidden>
Subject: Re: AXPosition and AXSize during window drags
To: Bill Cheeseman <email@hidden>
Cc: Accessibility-Dev Mail <email@hidden>
Message-ID: <email@hidden>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
On Nov 25, 2007, at 9:18 AM, Bill Cheeseman wrote:
> My sole reason for hope is that the Finder updates its position
> during a
> drag session very nicely. If the Finder's technique (whatever it is)
> is
> somehow accessible underneath Cocoa, maybe I could tap into that.
HIToolbox listens to notifications from the window server about window
position change, and updates its internal state to record the new
position (as well as sending appropriate Carbon events). I had thought
that AppKit did something similar, but it might just be on window drag-
complete.
-eric
------------------------------
Message: 2
Date: Mon, 26 Nov 2007 00:23:06 -0500
From: Michael Ash <email@hidden>
Subject: Re: AXPosition and AXSize during window drags
To: Accessibility-Dev Mail <email@hidden>
Message-ID: <email@hidden>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
On Nov 25, 2007, at 10:42 PM, Eric Schlegel wrote:
> HIToolbox listens to notifications from the window server about
> window position change, and updates its internal state to record the
> new position (as well as sending appropriate Carbon events). I had
> thought that AppKit did something similar, but it might just be on
> window drag-complete.
From observing the behavior of the returned frame and the
notifications Cocoa sends, it would appear that it does indeed do
something similar, but only when the mouse stops moving for a short
period of time. Even more inexplicably it also waits this short period
of time before updating even after the mouse is released, something
which has caused great hilarity in one of my apps when attempting to
position a new overlay window after a drag.
Mike
------------------------------
Message: 3
Date: Mon, 26 Nov 2007 11:56:52 -0500
From: Bill Cheeseman <email@hidden>
Subject: Re: AXPosition and AXSize during window drags
To: Accessibility-Dev Mail <email@hidden>
Message-ID: <C3706504.6373C%email@hidden>
Content-Type: text/plain; charset="US-ASCII"
on 2007-11-26 12:23 AM, Michael Ash at email@hidden wrote:
> On Nov 25, 2007, at 10:42 PM, Eric Schlegel wrote:
>
>> HIToolbox listens to notifications from the window server about
>> window position change, and updates its internal state to record the
>> new position (as well as sending appropriate Carbon events). I had
>> thought that AppKit did something similar, but it might just be on
>> window drag-complete.
>
> From observing the behavior of the returned frame and the
> notifications Cocoa sends, it would appear that it does indeed do
> something similar, but only when the mouse stops moving for a short
> period of time. Even more inexplicably it also waits this short period
> of time before updating even after the mouse is released, something
> which has caused great hilarity in one of my apps when attempting to
> position a new overlay window after a drag.
The CGWindow solution detailed in my other message should be adaptable to
this situation in Leopard Cocoa.
--
Bill Cheeseman - email@hidden
Quechee Software, Quechee, Vermont, USA
www.quecheesoftware.com
PreFab Software - www.prefabsoftware.com
------------------------------
Message: 4
Date: Mon, 26 Nov 2007 12:13:50 -0500
From: Bill Cheeseman <email@hidden>
Subject: Re: AXPosition and AXSize during window drags
To: Accessibility-Dev Mail <email@hidden>
Message-ID: <C37068FE.6373E%email@hidden>
Content-Type: text/plain; charset="US-ASCII"
on 2007-11-25 1:14 PM, Bill Cheeseman at email@hidden wrote:
> on 2007-11-25 12:24 PM, Michael Ash at email@hidden wrote:
>
>> On Nov 25, 2007, at 12:18 PM, Bill Cheeseman wrote:
>>
>>> As I outlined in another message, Quartz Event Taps gives me an
>>> opportunity
>>> to do something repeatedly during a drag of any application's
>>> window, Cocoa
>>> or otherwise. The question is, what can I look at during each of those
>>> repetitive opportunities?
>>
>> Your mention of Leopard-only brings to mind the CGWindow APIs, which
>> allow you to get the bounds of any window on screen. I would hope that
>> since this API seems to talk directly to the window server, it will
>> get you the real location of any window no matter what the
>> circumstances. You may experience tearing due to synchronization
>> issues but it's certainly better than the alternative.
>
> Thanks for the tip. I had started looking at that yesterday but got
> sidetracked. It does look promising. I'll give it a shot.
It works! My overlay window now moves and resizes in nearly perfect
synchronization with the underlying window, Cocoa or not. I say "nearly"
because, if I wildly snap the mouse back and forth, I can see the slightest
lag on one window edge, on a 2.5G dual G5 machine. In more normal use, the
appearance is perfect.
Here's my code. You'll have to treat this as pseudocode in part, because
there are a number of calls to my private PFAssistive and PFEventTaps
frameworks. The nomenclature should make them self explanatory. Note again
that this requires Leopard.
When turning on my overlay window (a borderless semitransparent highlighting
window), I locate the target window in the global window list by matching
the pid of the application that owns the target window and the window
bounds. Then I save its CGWindowID for later use.
- (CGWindowID)getHighlightedWindowNumber {
CGWindowID windowNumber = kCGNullWindowID;
NSArray *windowList = (NSArray
*)CGWindowListCopyWindowInfo(kCGWindowListOptionAll |
kCGWindowListOptionOnScreenOnly | kCGWindowListExcludeDesktopElements,
kCGNullWindowID);
if (windowList) {
PFUIElement *element = ([[self highlightedElement]
isRole:NSAccessibilityWindowRole]) ? [self highlightedElement] : [[self
highlightedElement] AXWindow];
NSRect elementWindowBounds = {[[element AXPosition] pointValue],
[[element AXSize] sizeValue]};
int elementPID = [element pid];
NSDictionary *highlightedWindowDictionary = nil;
for (NSDictionary *thisWindowDictionary in windowList) {
// Get the window of the target application containing a
highlighted UI element by matching the window dictionary's pid to the
element's pid and the window dictionary's bounds to the element's window's
bounds.
int targetPID = [[thisWindowDictionary objectForKey:(NSString
*)kCGWindowOwnerPID] intValue];
if (targetPID == elementPID) {
CGRect bounds;
CGRectMakeWithDictionaryRepresentation((CFDictionaryRef)[thisWindowDictionar
y objectForKey:(NSString *)kCGWindowBounds], &bounds);
NSRect targetWindowBounds = NSRectFromCGRect(bounds);
if (NSEqualRects(targetWindowBounds, elementWindowBounds)) {
highlightedWindowDictionary = thisWindowDictionary;
break;
}
}
}
windowNumber = [[highlightedWindowDictionary objectForKey:(NSString
*)kCGWindowNumber] unsignedLongValue];
CFRelease(windowList);
}
return windowNumber;
}
When my event tap's delegate method fires repeatedly while the target window
is being dragged or resized, I reset the frame of the overlay window by
getting the new bounds of the target window, using the saved CGWindowID.
- (void)eventTap:(PFEventTap *)tap didPostEvent:(PFEvent *)event {
// Delegate method per PFEventTap to monitor left mouse dragged, mouse
down and mouse up events, in order to move and resize the highlighting
overlay window synchronously with the underlying highlighted UI element.
NSRect highlightRect = NSZeroRect;
NSArray *windowNumbers = [NSArray arrayWithObject:(void *)[self
highlightedWindowNumber]]; // windowNumber is pointer
NSArray *windowList = (NSArray
*)CGWindowListCreateDescriptionFromArray((CFArrayRef)windowNumbers);
if ([windowList count] == 1) {
NSDictionary *thisWindow = [windowList objectAtIndex:0];
CGRect bounds;
CGRectMakeWithDictionaryRepresentation((CFDictionaryRef)[thisWindow
objectForKey:(NSString *)kCGWindowBounds], &bounds);
highlightRect = NSRectFromCGRect(bounds);
if (!NSEqualRects(highlightRect, NSZeroRect)) {
highlightRect.origin.y = NSMaxY([[[NSScreen screens]
objectAtIndex:0] frame]) - NSMaxY(highlightRect); // flip
if ([[NSUserDefaults standardUserDefaults]
boolForKey:HIGHLIGHT_ANIMATES_DEFAULTS_KEY]) {
[[[self overlayWindow] animator] setFrame:highlightRect
display:YES];
} else {
[[self overlayWindow] setFrame:highlightRect display:YES];
}
}
CFRelease(windowList);
}
}
Sorry about the messy line breaks.
--
Bill Cheeseman - email@hidden
Quechee Software, Quechee, Vermont, USA
www.quecheesoftware.com
PreFab Software - www.prefabsoftware.com
------------------------------
Message: 5
Date: Mon, 26 Nov 2007 09:42:54 -0800
From: James Dempsey <email@hidden>
Subject: Re: AXPosition and AXSize during window drags
To: Bill Cheeseman <email@hidden>
Cc: Accessibility-Dev Mail <email@hidden>
Message-ID: <email@hidden>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
On Nov 26, 2007, at 9:13 AM, Bill Cheeseman wrote:
> on 2007-11-25 1:14 PM, Bill Cheeseman at email@hidden wrote:
>
> It works! My overlay window now moves and resizes in nearly perfect
> synchronization with the underlying window, Cocoa or not. I say
> "nearly"
> because, if I wildly snap the mouse back and forth, I can see the
> slightest
> lag on one window edge, on a 2.5G dual G5 machine. In more normal
> use, the
> appearance is perfect.
Bill - I'm glad that it works and gives you a workaround. Definitely
file a bug against accessibility, most notably because the behavior is
different between Cocoa and Carbon apps.
Hope your Thanksgiving was a good one,
James
--------------------------------------------------
James Dempsey
AppKit Engineering
Apple
email@hidden
------------------------------
_______________________________________________
Accessibility-dev mailing list
email@hidden
http://lists.apple.com/mailman/listinfo/accessibility-dev
End of Accessibility-dev Digest, Vol 4, Issue 73
************************************************
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Accessibility-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden