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: Matt Gough <email@hidden>
- Date: Thu, 20 Mar 2003 10:30:43 +0000
>
On 3/19/03 2:20 AM, "Matt Gough" <email@hidden> wrote:
>
>
> OK, so what this comes down to is - Conceptually, why can't a minimized
>
> window be main? What is the UI reasoning behind this?
>
>
The main window of an application must be one that the user can interact
>
with. A minimized window cannot be interacted with. Therefore, a window
>
cannot be both main and minimized.
>
>
Or, from another direction: A user must be able to glance at the screen and
>
tell which window is main. If the main window was only represented by a
>
minimized dock tile (which might not even be visible if the user chooses to
>
hide the dock), the user could not easily determine which window is main.
>
>
> After all:
>
>
>
> 1. It can be unminimized and then made main
>
>
>
> 2. When being unminimized from the Dock, it automatically becomes main
>
> straight away (i.e. the user doesn't have to do that in two stages)
>
>
>
> 3. Likewise, when a minimized window is selected from the owning
>
> application's own Windows menu, it is also made main.
>
>
>
> As such it is surely the expectation of the user that this is the expected
>
> behaviour, yet Accessibility enforces this to not be so.
>
>
No.
>
>
#1 isn't possible via the UI. (At least not as far as I've ever seen. I
>
could be wrong.)
>
>
#2 describes a user action with the syntax of "press the dock icon". It just
>
so happens that this action invokes the functionality of making the window
>
un-minimized and making the window main.
>
>
#3 describes a user action with the syntax of "choose item Foo from the
>
Window menu." It just so happens that this action invokes the functionality
>
of making the window un-minimized (if it is currently minimized) and making
>
the window main.
>
>
And in fact, neither #2 nor #3 will make a window main if the app is
>
displaying an app-modal dialog.
>
>
> Please try to put fewer roadblocks in the way of developers using AX. Leave
>
> it to us to decide what is the most appropriate behaviour for our apps.
>
>
Where's the roadblock? If you wish to make a minimized window main, you can
>
use Accessibility to do the two atomic operations in sequence: Make the
>
window un-minimized, and then make it main.
>
>
>
I got to the discussion late, so I want to touch on a couple things you said
>
in another message:
>
>
> But all I am doing is asking if the window COULD be main.
>
>
No. You're asking if the window can be made main *right now* in an atomic
>
operation. In this case, it cannot. Cocoa windows can only be made main if
>
they are not minimized.
>
>
> Surely that is the
>
> purpose of AXUIElementIsAttributeSettable - to see if the element supports
>
> such a thing.
>
>
No. The purpose of the IsAttributeSettable API is to see if you can change
>
an attribute's value *right now*.
>
>
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.
>
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.
>
>
Based on your last response, I get the feeling that you didn't really ask
>
the question you intended to ask. (After all, you seemed irritated by our
>
completely true and legitimate answer.) I get the feeling you intended to
>
ask something like:
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.
(See my other postings on this list for various disparities between Carbon
and Cocoa apps)
>
1) Can you please add some kind of convenience action or attribute which
>
allows me to set the main-ness of a window without having to worry about its
>
minimized (or other) state?
>
>
2) I'd like to use the settability of main-ness as an indication of <some
>
other application or window state>, but I can't because main-ness isn't
>
settable for minimized Cocoa windows. Unfortunately, there is no direct way
>
to query <some other application or window state>. Can you please add one?
>
>
If so, it would be much more constructive (and less adversarial) to ask your
>
real question in the first place.
>
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. I realise that that list can sometimes be 'wrong' from a UI
point of view (for example if the app I am testing has a modal dialog up, I
will not be able to make anything main, but that is no different than the
user trying to click on a window behind the modal one and getting a beep).
For a more detailed list of my requirements, please read the Feature
enhancement I added in November 2001 on Radar - 2805910
'Getting Window info on OS X'
Matt
_______________________________________________
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.