User forums > Help
Accessibility
MortenMacFly:
--- Quote from: thomas on January 20, 2010, 07:41:34 pm ---For some reason which I don't curently know, the focus is on the "OK/Cancel" group by default,
--- End quote ---
Isn't that the default if you use a wxStdDialogButtonSizer?!
So you'd have to force setting the focus to another element (the tab bar?!).
--- Quote from: thomas on January 20, 2010, 07:41:34 pm ---Also we should set up some callback function that catches keypresses [...]
--- End quote ---
Do you think that possible via a plugin? I think an accessibility plugin (architecture) would come in quite nice. We could even add some notification to the SDK as helper. Why I'm asking: (Speaking for myself): I hardly know what exactly is needed, but I believe Lava knows. Giving him the ability to implement what's needed goes definitely in the right direction I'd guess. ;-)
MortenMacFly:
--- Quote from: MortenMacFly on January 20, 2010, 08:18:40 pm ---So you'd have to force setting the focus to another element (the tab bar?!).
--- End quote ---
Looking e.g. at "app_compiler_settings.xrc":
Lava: Can you try the attached XRC resource file, please? I've set the focus to the main notebook "nbMain".
Probably that's already a bit better...?!
What to do:
This XRC file is part of [CodeBlocks Install Directory]\share\CodeBlocks\resources.zip.
Just extract the ZIP archive, replace the file and re-create the ZIP archive overwriting the old one.
thomas:
I think you forgot to attach the attached xrc file :)
Putting all that's needed for accessibility into a plugin might be hard in my opionon, though some could probably be done. Still, the fact that it can be done doesn't mean it's necessarily good... I think we should try to make the main application more accessible from the beginning.
If I understood the screenreader problem right, we need to reply to a WM_GETTEXT message, which is harder than it sounds, since we don't get to see these easily.
The other problems are comparatively easy. The most difficult thing about adding a key to switch from the editor to the project window is to agree on what key to use.
Adding arrow up / down to the settings dialog should be as much as adding one more message listener and sending a list select event.
MortenMacFly:
--- Quote from: thomas on January 21, 2010, 01:12:30 am ---I think you forgot to attach the attached xrc file :)
--- End quote ---
Call me an idiot. I've attached it now.
--- Quote from: thomas on January 21, 2010, 01:12:30 am ---If I understood the screenreader problem right, we need to reply to a WM_GETTEXT message, which is harder than it sounds, since we don't get to see these easily.
--- End quote ---
I am not sure about that. The equivalent to WM_GETTEXT in Scintilla is SCI_GETTEXT which is processed (look at wxString wxScintilla::GetText() in wxscintilla.cpp. If I got Lava right than this is only a problem with Code::Blocks and not with Scintilla itself. I would like to have that clarified:
@Lava: Do other application like e.g. SciTE or Notepad++ work correctly with Screenreader?
Ps: Is it correct that the Screenreader software actually costs more than 1000 US$? Profit is all that counts here, right?!
[attachment deleted by admin]
thomas:
--- Quote from: MortenMacFly on January 21, 2010, 10:38:45 am ---
--- Quote from: thomas on January 21, 2010, 01:12:30 am ---...need to reply to a WM_GETTEXT message, which is harder than it sounds
--- End quote ---
I am not sure about that. The equivalent to WM_GETTEXT in Scintilla is SCI_GETTEXT which is processed...
--- End quote ---
As I understand it, the screen reader uses SendMessage with WM_GETTEXT, which will target the main window as well as the first-class windows owned by it. Or, if a dialog comes up, then this window and its children... whichever window has focus.
It probably has to do some nasty DLL injection hackery too, since the WM_GETTEXT message includes a writeable data pointer, so it would have to own a memory range in the same address space as the application -- but that isn't our problem, JAWS has to deal with that.
Now the thing is, this message arrives in the main window's message loop which is handled by wxWidgets. The main window does not own the Scintilla control. wxAUI, or rather wxAUI panels (which are not first-class windows) own all the editors, so the Scintilla control never gets to see a message. It doesn't matter if it's SCI_GETTEXT or something else, because still the control won't get to see it.
What we would need to do is intercept the message, then see which wxAUI panel has the focus, and forward the message to that panel's child. So we would need to insert our own low-level message handling into wxWidget's. Or, we would have to patch wxAUI into forwarding messages, which probably isn't much easier.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version