Open Source Digital Talking Book Player

Discussions around miscellaneous technologies and projects for the general membership.
Post Reply
gkearney-p40
New Member
Posts: 15
Joined: Tue Aug 28, 2007 5:18 pm

#11

Post by gkearney-p40 »

tomw wrote:One comment in favor of Java is the platform independence. Building in Python still requires you to call specific platform GUI calls. However, I love the idea. Who wants to participate?

Tom
An issue with Java is ensuring that the GUI can be accessed by all the various screen readers used by the blind and disabled. Take it from someone who has tried to interact with some of the Church's Java software with the Mac screen reader not all is well and programmers seldom give thought to how people who can not see the screen will use their software. Take, as an example, this reply to my concern about visual only input on new.familysearch.org:

Dear Greg,
Thank you for your concern. You are correct. Those that have vision problems will have to have the assistance of a sighted person to sign up. If the patron is unable get assistance from anyone, they are welcome to call support and we will work with them to help them sign in.

Sincerely,
FamilySearch Support
MEM
<CaseID:458576>

gkearney@gmail.com 8/25/2007 4:55:42 PM >>>
Subject: Picture text and the blind

Given that the sign in requires a membership number and date is the
picture text really needed? What are the chances that an automated
script could guess both?

Such pictures make it impossible for the blind to sign up without
sighted help.

Greg Kearney
Casper, Wyoming


----------------------
<CaseID:458576>
----------------------


So even though there is no good reason to even have the check, no automated system would ever be able to guess both a file number and a date correctly, the answer was basically tough, go get sighted help.

Greg
cannona-p40
Member
Posts: 79
Joined: Sat May 19, 2007 2:32 pm
Location: Iowa City, IA

#12

Post by cannona-p40 »

RussellHltn wrote: Would anything special need to be done to support Braille devices?

Daisy supports synchronizing Braille with the text and audio, though no players support this, that I know of. However, if we are designing the player, then there's no reason why such functionality couldn't be added.

The only problem I see is that Braille is only produced for a few of our publications. But, if there were enough demand...
RussellHltn wrote: Going back to what you are envisioning, I'd see it as something that could be "flavored" to go to the initial download. For example, since you would be downloading it from the lds.org site, it would go back to that site to find content on install. But another group could do the same thing to have it go to their site.

This is also something that I've thought about. Of course, if enough organizations began offering feeds of their DAISY content, then it might also make sense to give the user the ability to add additional locations to their library.
mkmurray wrote: Out of curiosity, which standard(s) would you support? the 2005? the 2.02?

Currently, we are creating books in the 2002 format. The format changed significantly from version 2.02 to 2002, but the differences between 2002 and 2005 are not that great. The 2005 format just added some specialized features that we probably won't need.
Still, I would eventually like to have it support all formats, but Daisy 2002 would be a good start.

Nearly all of the hardware players can support the 2002 standard, although some of the older models may need to have their firmware updated.
RussellHltn wrote: Another question: what is the standard computer interface for blind users? The reason I ask is I'd assume that most programmers on this project would be sighted will little experience in coding or even using products aimed at the blind. That creates some user interface issues.

Most blind computer users (though not all) are using Windows with a screen reader. Some also have Braille displays. Other than that, our computers are generally no different.
Creating interfaces for the blind or folks with low vision should not be too much different than creating one for a sighted user. If one is careful to use standard windows controls (as aposed to nonstandard controls that are used by some cross platform gui kits), and if the developer makes sure that all controls have text associated with them and are accessible via the keyboard, then there really shouldn't be any problem.

Under Python, the best answer I have found is the WxPython toolkit. This is cross platform, but it also utilizes the standard windows GUI controls.

I plan on being as involved as possible with the development of the interface, to make sure that this doesn't become an issue. Even though I would like us to make the interface self-voicing, I would also like to make it work well with screen readers, because most screenreader users would rather use their screenreader to get access to the screen. (Sorry for the tongue twister.)
JamesAnderson wrote: One other thing, since the files would be in mp3 format, would one also be able to download them for use on anything that otherwise would play mp3 files? That way even if one was not disabled but wanted the same content, they could grab that off the site and listen to it, just like any other mp3 file now published by the Church and others, albeit without the special/enhanced features that using a DAISY player would bring.

Yes. I have been quite careful when creating our DAISY books to name the files in such a way that they should play in order on any device that sorts its playlist by file name.

The only difference between a bunch of MP3s and a DAISY book is that a DAISY book has three or four extra XML files in the directory. I assume that most players worth anything should just ignore any file they don't recognize.
tomw wrote:One comment in favor of Java is the platform independence. Building in Python still requires you to call specific platform GUI calls. However, I love the idea. Who wants to participate?

Tom

I believe that the WXPython package mentioned above takes care of this. You use the WXPython interface, and it figures out which API to interact with based on the OS. I believe in Geek Speak this would be refered to as an abstraction layer.

Finally, I have been working on a class that will parse the XML data into a nice data structure. Up until this morning, it was all pseudo-code, but it seems to be coming together nicely. It's not much, but it's a start.

Aaron
kalebpederson
New Member
Posts: 32
Joined: Tue Jul 31, 2007 10:16 pm

#13

Post by kalebpederson »

cannona wrote:
...snip...

Under Python, the best answer I have found is the WxPython toolkit. This is cross platform, but it also utilizes the standard windows GUI controls.

...snip...

I plan on being as involved as possible with the development of the interface, to make sure that this doesn't become an issue. Even though I would like us to make the interface self-voicing, I would also like to make it work well with screen readers, because most screenreader users would rather use their screenreader to get access to the screen. (Sorry for the tongue twister.)

... snip ...

I believe that the WXPython package mentioned above takes care of this. You use the WXPython interface, and it figures out which API to interact with based on the OS. I believe in Geek Speak this would be refered to as an abstraction layer.

Finally, I have been working on a class that will parse the XML data into a nice data structure. Up until this morning, it was all pseudo-code, but it seems to be coming together nicely. It's not much, but it's a start.

Aaron

Hey Aaron (et all),

I would strongly recommend that you go with PyQt (http://www.riverbankcomputing.co.uk/pyqt/index.php). eg. The Python bindings to Qt. Qt (http://trolltech.com/products/qt) is a great toolkit that uses native widgets on almost every imaginable platform. Linux, Solaris, Windows, Mac, etc. They have an open source version that doesn't cost anything and a free IDE is provided as a part of the Windows Download (and you can get the packages separately for Linux/Macintosh if you want).

If you didn't want to use Python, you could use the native C++ interface, or you could use QtJambi, the Open Source Java bindings for the language.

To give you an idea of the quality of apps that are developed with it, both Google Earth and Adobe Photoshop Elements are written with Qt, as is KDE and many Linux/Unix based applications.

Qt is well designed (see http://doc.trolltech.com/4.3/index.html), well supported, and open source... you couldn't ask for much more than that. Given the commercial nature of it, it also has many accessiblity features that would be important given the target audience.

Sorry if I sound a bit like a salesman -- I develop commercial applications with it ... and still love it. I would gladly help out if it were to be written with Qt (no learning curve sure helps :)), and could mock up interfaces really quickly with a good set of specs.

--kpederson
gkearney-p40
New Member
Posts: 15
Joined: Tue Aug 28, 2007 5:18 pm

#14

Post by gkearney-p40 »

kpederson wrote:Hey Aaron (et all),

I would strongly recommend that you go with PyQt (http://www.riverbankcomputing.co.uk/pyqt/index.php). eg. The Python bindings to Qt. Qt (http://trolltech.com/products/qt) is a great toolkit that uses native widgets on almost every imaginable platform. Linux, Solaris, Windows, Mac, etc. They have an open source version that doesn't cost anything and a free IDE is provided as a part of the Windows Download (and you can get the packages separately for Linux/Macintosh if you want).

If you didn't want to use Python, you could use the native C++ interface, or you could use QtJambi, the Open Source Java bindings for the language.

To give you an idea of the quality of apps that are developed with it, both Google Earth and Adobe Photoshop Elements are written with Qt, as is KDE and many Linux/Unix based applications.

Qt is well designed (see http://doc.trolltech.com/4.3/index.html), well supported, and open source... you couldn't ask for much more than that. Given the commercial nature of it, it also has many accessiblity features that would be important given the target audience.

Sorry if I sound a bit like a salesman -- I develop commercial applications with it ... and still love it. I would gladly help out if it were to be written with Qt (no learning curve sure helps :)), and could mock up interfaces really quickly with a good set of specs.

--kpederson
I would urge a very complete testing of any such toolkit to insure that it is compatible with the various screen readers on the various platforms. My experience with Jave shows that this is a very serious problem.

Greg
User avatar
WelchTC
Senior Member
Posts: 2085
Joined: Wed Sep 06, 2006 8:51 am
Location: Kaysville, UT, USA
Contact:

#15

Post by WelchTC »

I'm very familiar with QT as well. I was not aware that they have an open source version for Windows. However if they do, I would second a vote for QT and/or PyQT. While at Linspire, we developed two major apps using Python and PyQT.

Tom
The_Earl
Member
Posts: 278
Joined: Wed Mar 21, 2007 9:12 am

QT Testing

#16

Post by The_Earl »

gkearney wrote:I would urge a very complete testing of any such toolkit to insure that it is compatible with the various screen readers on the various platforms. My experience with Jave shows that this is a very serious problem.

Greg
I will add my voice in support of QT. We use it in our commercial apps as well.

I would think that QT would have good support for accessability. Many commercial apps require this.

As long as you don't stray outside the common UI widgets, I would think that most languages would work with a screen reader. It gets more complicated when programmers try to be 'clever'.

The Earl
cannona-p40
Member
Posts: 79
Joined: Sat May 19, 2007 2:32 pm
Location: Iowa City, IA

#17

Post by cannona-p40 »

tomw wrote:I'm very familiar with QT as well. I was not aware that they have an open source version for Windows. However if they do, I would second a vote for QT and/or PyQT. While at Linspire, we developed two major apps using Python and PyQT.

Tom

I'm certainly not married to the idea of using WXPython, and if PyQT will work, then lets use it. I will do some testing today to make sure it will work with screenreaders, and I'll get back to you all. However, if it uses the native windows widgets, then there should be no problem.

Thanks!

Aaron
gkearney-p40
New Member
Posts: 15
Joined: Tue Aug 28, 2007 5:18 pm

#18

Post by gkearney-p40 »

cannona wrote:I'm certainly not married to the idea of using WXPython, and if PyQT will work, then lets use it. I will do some testing today to make sure it will work with screenreaders, and I'll get back to you all. However, if it uses the native windows widgets, then there should be no problem.

Thanks!

Aaron
Aaron I would be happy to test the Mac VocieOver compatibility of anything.

Greg
kalebpederson
New Member
Posts: 32
Joined: Tue Jul 31, 2007 10:16 pm

Qt, PyQt and QtJambi open sourced

#19

Post by kalebpederson »

tomw wrote:I'm very familiar with QT as well. I was not aware that they have an open source version for Windows. However if they do, I would second a vote for QT and/or PyQT. While at Linspire, we developed two major apps using Python and PyQT.

Tom
As of Qt-4.0, Qt was Open Sourced for Windows. When QtJambi, the Java bindings were released a while ago, they also released it under the same licensing.

By what I have heard, the next version of Qt, 4.4.X will add a lot more multimedia (audio/video) support, so that might even include all the support needed for the audio part of the project as well. Right now the audio support is quite limited.

--kpederson
cannona-p40
Member
Posts: 79
Joined: Sat May 19, 2007 2:32 pm
Location: Iowa City, IA

#20

Post by cannona-p40 »

Well, I did some checking and it appears as though QT does not use native widgets. It only emulates them. I also downloaded and tried a couple QT apps just in case, and they were not accessible.

Aaron
Post Reply

Return to “Other Member Technologies”