Re: Minimized Cocoa windows say that kAXMainAttribute can't be set
Re: Minimized Cocoa windows say that kAXMainAttribute can't be set
- Subject: Re: Minimized Cocoa windows say that kAXMainAttribute can't be set
- From: Mike Engber <email@hidden>
- Date: Thu, 20 Mar 2003 10:22:45 -0800
No. The purpose of the IsAttributeSettable API is to see if you can
change
an attribute's value *right now*.
Take this to heart. This is our intention, if you find cases where it's
not true
then it's a bug
If you want to see if an element supports an attribute, just look to
see if
the attribute name is in the element's attribute list. The fact that
kAXMainAttribute is in the attribute list implies that -- in the right
situation -- the window can be main.
Taken literally, this is a bit misleading. Just because an attribute is
supported, doesn't
mean that it's possible to set that attribute. There are many
attributes that provide useful information that can never be set
(AXRole, ...).
That may be true in theory, that is not what I have found in practice:
For example:
In Safari (v60) The Downloads window has the AXMain attribute, but it
is
always "0"
Also in Safari, the Activity window always has AXMinimized, but the
window
can never be minimized.
There are many more such examples, some of which combine the above
problems:
E.g. Cocoa's Font Panel always has the AXMain and AXMinimized
attributes,
but neither can ever be set.
In fact it seems that any 'palette' style window always have these two
always "0" attributes.
When it comes to attributes like AXMain, which are settable for some
windows
(under the right circumstances) and never settable for other windows -
they're still useful in that you can to test any window to see if it's
main.
But as shown above, sometimes the answers given on this list aren't
supported by the reality of how things work now (as of 10.2.4). They
seem to
be based on how the AX routines are intended to behave, but currently
can't
because of limitations in existing Applications and frameworks.
In the case of settability - I think theory and practice are in pretty
close agreement.
In a nutshell, what I want is the ability to create a list of all of
the
windows that the user could bring to the front at any given time. i.e.
if a
window shows up in the Dock's menu of windows for each app, it should
show
up in mine.
You want more than a list of windows (i.e. their titles) - you want
objects you can query and manipulate (and you think/wish
AXUIElementRefs would fit the bill).
Believe it or not, what you're asking for is more than the Dock gets.
The Dock really only has the info it needs to create that menu -
nothing more.
-ME
_______________________________________________
accessibility-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/accessibility-dev
Do not post admin requests to the list. They will be ignored.