Thanks. This does help and is very interesting. Maybe we can get a desktop application and a Web application at the same time. I'm not changing course, but this is a possibility worth looking at. One problem is that we might not know about accessibility until we tried it. John On Wed, Feb 02, 2011 at 09:13:09AM -0800, Chris von See wrote: > Up front: I'm not necessarily advocating use of the SWT browser > control as a UI - it was more of a response to some of the concerns > expressed about the accessibility of SWT. I've been curious about the > accessibility of the SWT browser control for my own purposes - Freedom > Scientific won't say that they support it, and I haven't talked to the > WindowEyes folks yet - so this seemed like a good opportunity to both > throw out a possibly viable option and get some info myself. > > Having said that, if you chose to use the SWT browser control you > would in essence be writing a web-based braille application, most > likely using an embedded servlet container such as Jetty. What you > end up with may well be something similar to Google Docs; similar > approaches are used in numerous applications, but whether it works for > BrailleBlaster would depend on the functionality you want to > implement. Our TAMC application uses an embedded Jetty container to > render a HTML UI, but it uses a regular browser window (whatever the > user's default browser is) and not the SWT browser window. The system > default browser can be launched using the Desktop.browse() or > Desktop.open() methods in JDK 1.6 and later. > > Here's a half-formed possible approach: Much of the back-end > functionality of BrailleBlaster (file load/save, search/replace, > translation, etc.) would be implemented much as it is envisioned now, > except that the user interface would be implemented using some > combination of HTML, JavaScript, Java servlets and/or other > technologies (UI builders such as Java Server Faces or Freemarker, and/ > or a web framework such as Apache Struts, Apache Wicket or even > Spring, for example). Editing would be done in an HTML text control > or in an ActiveX text editor (not sure about accessibility in this > case, but there are lots of options out there), with buttons, > checkboxes, and other controls implemented using HTML. It's possible > to call Java from JavaScript inside the SWT browser control, so if you > need an immediate reaction to the changing of control state you should > be able to do it with Java if JavaScript isn't enough. For multiple > views you would probably open multiple SWT shells, each with its own > browser control. > > There are lots of code snippets for the browser control at > http://www.eclipse.org/swt/snippets/#browser , and the SWT example set > includes a BrowserExample application which can be downloaded from > http://help.eclipse.org/helios/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/api/org/eclipse/swt/browser/package-summary.html > > Hope this helps... > > > Cheers > Chris > > On Feb 2, 2011, at 3:22 AM, John J. Boyer wrote: > > >Chris von See, could you elaborate on your idea of making the > >framework > >of BrailleBlaster in SWT and presenting the GUI content with html in > >the > >browser control? When it is asked to produce UTDML liblouisutdml > >produces output in Daisy xml format. This would work ni cely with a > >browser if we have a way of presenting the menus and the Daisy and > >Braille views. > > > >What does the SWT browser control do if it gets a text file? > > > >Thanks, > >John > > > >-- > >John J. Boyer; President, Chief Software Developer > >Abilitiessoft, Inc. > >http://www.abilitiessoft.com > >Madison, Wisconsin USA > >Developing software for people with disabilities > > > > > -- John J. Boyer; President, Chief Software Developer Abilitiessoft, Inc. http://www.abilitiessoft.com Madison, Wisconsin USA Developing software for people with disabilities