Sb6 : UI : minor : Accessibility API tweaks

I would have brought this up earlier, but I only recently discovered the details involved in the problem, and only recently purchased a program that exposes them (Zooom). There are three windows that do not react correctly to window movement calls. First, the Full Screen window should not move when you accidentally Zooom it. Second and third are more minor: The two HUD windows, Keywords in all modes and Inspector HUD in full screen, both react to movement calls, but not resize calls. This last one may be a limitation in the way the Apple class for these windows is set up, though.

I have been informed by the developer of Zooom that the modifications necessary for excluding the full screen window is a simple three lines of code. As for the HUDs, I do not know about that. In my opinion, it is more of a problem that the full screen window can get knocked about, revealing the OS beneath it, than HUDs being unable to be resized.

I don’t suppose the developer included those three lines of code, did he? :slight_smile:

As for the HUD panels - these are not Apple classes, but entirely written by yours truly. They were not easy. Apple do not provide any public way of customising the look of windows or panels, and there is no HUD class - the code for HUD windows in Apple programs is not yet public. Currently, you have to “fake” it by creating a window with no title bar and then drawing the whole thing yourself and adding your own title bar. But then there’s another catch: windows without Apple title bars cannot be resized. Thus I had to trap all mouse drags myself and add all the resizing code myself. This was veeeeeery painful. So, I’m afraid this is just a limitation that won’t change any time soon. What I am hoping is that Apple will include HUD panels in the frameworks with the release of Leopard; in fact, I would be very surprised if they did not.

What exactly happens with the full screen window? I tried installing the demo of Zooom but it doesn’t even seem to be working on my MacBook. I am surprised that the full screen window actually gets resized, given that the type of window it is shouldn’t actually be able to be resized…

Best,
Keith

Oh! Compliments on the very clever deception then. They were so convincingly done that I thought it was a simple Apple window option. Anyway, the lack of resize is only a minor annoyance, especially now that the state is correctly saved. I rarely change the keyword HUD position and size. It was more of an issue when I had to go through the task of moving and resizing every morning. :slight_smile:

Let me clarify on the full screen: I did not mean to suggest it can be resized – just that it can be moved. The entire window and all of the things contained within it, move around.

He did not in fact impart the mighty three lines of code to me, a mere citizen, but he can be contacted from this page.

Pity you couldn’t get it working on your Mac though, it is a nice little app once you get used to it. Perhaps try turning logging on (under Registration), and monitor Console while turning the Zooom daemon on and off – might be enlightening.

I got the code, it truly is quite simple:

[code]// code starts

  • (BOOL) accessibilityIsIgnored
    {
    return YES;
    }
    // code ends[/code]

It is to be placed into the “NSWindow” derived object.

Weird - that is not one I would have ever guessed to override, certainly not by the Apple description of it (which begins, “In other words, when asking for an object’s children, ignored children should not be included; instead, the ignored children should be replaced by their own unignored children…” and then goes on to become more oblique :slight_smile: ).

Anyway, I have added this code for 1.01. Could you check to see if you can move the control panel at the bottom of full screen around, too?

Thanks,
Keith

That is one horrific bit of documentation, there :exclamation:

Yes, the bottom panel can be moved independently from the full screen window, and it promptly disappears when you do so, appearing in its correct location the next time it is activated. When moving the full screen window, the console travels with it. I guess that is what it gets for being an unignored child of an ignored parent that ignored its grandparent for an unignored pet which ignored its grandchild and got sent to jail for ignoring its included unignored replacements.

I’m ignoring that last bit and just adding the code to the control panel too. :slight_smile:

Best,
Keith

P.S. Just for your reference, the next bit of the documentation continues thus: “The same applies when asking for an object’s parent; an ignored parent should be skipped and the first unignored ancestor treated as the real parent. Likewise, when a hit-test or focus test is satisfied by an ignored element, the element’s first unignored ancestor (or descendant in certain cases, such as single-celled controls) should be used instead.” So it turns out it’s not just parents and children being ignored, but their ancestors and other elements too. :frowning: (Except for the ones that are unignored, but if the unignored-ness is ignored then the double negative inverts itself and they are ignored too… Uh…)