Hi quentinC.
Your choice and reasoning regarding java is quite sound. I would also
not consider using java's ui with access bridge. Even using grid
layout or some other layout results are unpredictable and different on
different os's.

If you ever consider using your screen reader API from java, take a
look at the java native interface (jni). Once you've created a wrapper
it is easy to use. I think you can even use something like swig to
generate a useable entry point to use from java.

On 12/2/11, QuentinC <quent...@cfardel.net> wrote:
> Hi Thomas,
> You are going to a central point here. As you know, I'm still a big java
> fan, I wrote past games in java, and upcoming games outside of the
> playroom will very likely to be in java again. Why I haven't written the
> playroom in java ? There is two reasons for this:
>
> 1. You might have experienced the problem I had with magic blocks most
> notablyy: speech via screen reader support was totally absent. I tried
> to arrange something myself using COM and DLL proxy libraries and failed
> to make something really reliable. All screen reader supports including
> SAPI were quite buggy and it mades the application to crash randomly,
> especially on 64 bit machines but also on 32 bit ones.
> As reliable speech output via screen reader is a very capital point in
> the playroom, I had first to find a solution for that problem before
> going further, and nothing came to mind at that time.
>
> 2. The playroom is a little different to most of audiogames we have out
> there. It uses true windows GUI components, when most audiogames simply
> open a blank window and directly react to user input from there. Most
> audiogames actually use virtual menus and controls that are not shown on
> screen at all. Why this choice ? Again, there are multiple reasons:
> a. Initially the playroom was in french only. At the very beginning, I
> received comments telling that it would be good to be able to play with
> braille display. As you know, direct speech output to screen reader does
> not use braille, and the easiest way to have all so different braille
> displays behaving correctly is to place text into standard controls so
> that the screen reader does the job nicely in the way the user usually
> set in his preferences.
> b. I found also nice to be able to navigate through the game's text
> freely, to allow easy review, easy copy/paste, easy saving, and as easy
> to use as in normal applications. In fact this feature is quite rare,
> even on mud clients (where it's indeed a must-have in my opinion). I
> suffered not having easy review and copy/paste on mud clients I had, and
> I'm still suffering not having this feature on console windows and
> SSH... In playroom this is important because there's a lot of text to
> deal with, just like in a mud.
> c. Using normal GUI components has a nice edge effect: it allows sighted
> people to play. Of course, the playroom is not as interesting for
> sighted people as other common games because there's no graphics, but
> still, I know that there are a couple of sighted players in the
> playroom, they wouldn't be able to play if I had used virtual menus and
> controls in a blank window.
> To come back to java, standard GUI controls in java with a screen reader
> remain problematic: they are slow, sluggich and somewhat buggy. The bugs
> there are are very stupid indeed: before very latest jaws 13, backspace
> in an edit field says empty instead of the character being cleared, and
> NVDA sometimes says empty instead of reading a line of text in a edit
> field. For all screen readers, when you press up or down arrow sometimes
> it reads the old line instead of the one where you just arrived. Some
> less common screen readers don't support access bridge at all, etc. and
> don't forget the most important thing: java access bridge is no more
> actively maintained. In brief, all that is not very reliable, is not
> going to be more in the future, and this is not acceptable. You will
> tell me that there is scripting: yes, certainly. But if scripting is a
> working partial solution for experienced computer users, installing
> scripts is another problem on itself and especially if you aim to
> support multiple screen readers.. clearly not doable for less
> experienced computer users. And because the playroom is conceptually a
> simple game, it must be manageable by less experienced computer users as
> well.
>
> This closes my probably longest english post.
>
> ---
> Gamers mailing list __ Gamers@audyssey.org
> If you want to leave the list, send E-mail to
> gamers-unsubscr...@audyssey.org.
> You can make changes or update your subscription via the web, at
> http://mail.audyssey.org/mailman/listinfo/gamers_audyssey.org.
> All messages are archived and can be searched and read at
> http://www.mail-archive.com/gamers@audyssey.org.
> If you have any questions or concerns regarding the management of the list,
> please send E-mail to gamers-ow...@audyssey.org.
>

---
Gamers mailing list __ Gamers@audyssey.org
If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org.
You can make changes or update your subscription via the web, at
http://mail.audyssey.org/mailman/listinfo/gamers_audyssey.org.
All messages are archived and can be searched and read at
http://www.mail-archive.com/gamers@audyssey.org.
If you have any questions or concerns regarding the management of the list,
please send E-mail to gamers-ow...@audyssey.org.

Reply via email to