[Olpcaustria] [Linaccess] Fw: AW: Kopfmaus

Tue Jul 24 03:17:55 CEST 2007

Hallo Christoph,

die Mail wird ein wenig laenger...

ich fange mal mit dem Positiven an.

- Headtracker
Das Headtracking Projekt ist relativ ueberschaubar, wie es scheint. Das hat zwei Gruende:
1.
Es hat nicht primaer etwas mit dem XO zutun, ich kann mit USBcam, Filtern, IR LEDs und Software experimentieren, ohne einen XO in Haenden zu halten.
Genau das habe ich getan und habe schon ein paar Erfolge bzw. bin auf Probleme gestossen, die ich loesbar finde. Getestet habe ich mit meiner uralt Webcam 320x240 12f/s - kann nur besser werden.
2.
Es wird nur eine Maus emuliert. Alle Aktivities, die mit der Maus bedienbar sind, koennen auch mit der Kopfmaus gesteuert werden. Juchhu. Onscreenkeyboard zum Schreiben ist noch noetig, aber das ist ein anderes Projekt.

- TextToSpeech (TTS)
Es gibt Espeak. Das ist klein, hat wenig Abhaengigkeiten und unterstuetzt viele Sprachen. Es klingt grausam, aber man kann es verstehen. Ohne Screenreader allerdings relativ nutzlos. Naja, nicht Nutzlos, aber dann eher Spielerei. Erst durch den Screenreader wird TextToSpeech zum Accessibility Projekt. Screenreader fuer die Konsole waeren kein grosses Problem, aber fuer die GUI/Activities schon. Andere TTS Systeme klingen besser, sind aber fuers XO wegen der groesse vermutlich nicht geeignet.
Im Gespraech sind noch earcons, aber auch dafuer braucht man einen Screenreader.

- Alternative Eingabemethoden zum Keyboard.
Morse und Onscreenkeyboard haben wenig Schwierigkeiten. Hier muessen wir nicht alle Funktionen von ATK/AT-SPI nutzen. AT-SPI? kommt gleich...
Fuer Matchbox gibt es schon ein Keyboard, libfakekey, aber das hilft nicht viel. Ein variables wie GOK waere super. Aber da ist wieder das boese Wort: AT-SPI
Ebenfalls denkbar: dasher
Alles Software, die vorhanden ist, aber an Sugar angepasst werden muss. Wie lange das dauert, sehen wir ja beim olpc-Projekt. Die Tuecke liegt im Detail.

- Screenreader (orca). 
rasante Entwicklung, Python, hat Gnopernicus abgeloest. Benoetigt AT-SPI, ja, komm ich noch drauf.
Alternativ LSR, bei den Abhaengigkeiten auch nicht besser.
- Bildschirmlupe, in orca integriert, ebenfalls AT-SPI
- Brailleunterstuezung
ist erstmal nicht geplant, Braillezeilen kosten mehrere tausend Euro. Bauen wir aber vielleicht trotzdem ein, die libs sind sehr klein und tuen nicht wirklich weh.

Nun die Schwierigkeiten.

1.
Ich brauche unbedingt einen echten XO in Haenden, oder brauchbare Versionen fuer einen standard PC bzw fuer QEMU. Ich vertroedel meine Zeit mit Huerden in der Emulation und dreh mich im Kreis.
2.
Auch mit XO wird es schwer sein, weil Accessibility nahezu ignoriert wurde. Es gibt eine Accessibility Mailingliste seit etwa einem halben Jahr. Die Archive kann man in einer halben Stunde lesen. Accessibility Guidelines fuer Sugar und den Activities? Rudimentaer vorhanden und sehr lose formuliert. Was davon wiederum wirklich umgestetzt wurde weiss keiner.
3.
AT-SPI (Assistive technolgy service provider interface). Hier gibt es ein Blockdiagramm zum besseren Verstaendnis: http://developer.gnome.org/projects/gap/guide/gad/index.html
Wir wollen kein AT-SPI fuer den XO benutzen.
Der alte Streit zwischen Gnome und KDE kommt mal wieder zum tragen. Jetzt ist das Problem AT-SPI, das eigentlich alle gerne loswerden moechten. Es hat zu viele, grosse und leistungshungrige Abhaengigkeiten, siehe weiter unten. Aber: AT-SPI funktioniert. Deshalb wird es bei GNOME nicht beseitigt und man lebt mit der uneleganten Loesung. Trolltech wird es vermutlich nicht bei QT4 unterstuetzen, sie setzen auf D-BUS oder noch lieber IAccessile2, um ihre QT Produkte mit Windows A11Y Software kompatibel zu halten. SUN sieht es aehnlich wie GNOME und keiner hat die Resoucen ein Bruecke von ATK nach D-BUS zu schreiben. Alle sagen, AT-SPI muss weg und alle warten darauf, dass es jemand macht. Das bedeutet, alle Accessibility Programme fuer GNOME brauchen derzeit AT-SPI, was mit Abhaengigkeiten vermutlich fuer den XO zu fett wird.
BlaBla, es gibt tagelange flamewars zu diesem Thema, um den Schuldigen auszumachen. Die Darstellung des Problems ist hier stark verkuerzt :-)
Einen Stand der Diskussion gibt es hier: http://www.linux-foundation.org/en/AT-SPI_on_D-Bus
und nochmal mit Blockdiagramm: http://accessibility.kde.org/developer/bridge.php
Aber egal, was KDE/Trolltech/Sun etc machen, momentan haengt alles von AT-SPI ab.
4.
Wir werden AT-SPI erstmal einsetzen muessen. Dazu muss ich ne Menge Software nachinstallieren und hoffen, dass sich der XO noch regt. Mit QEMU hab ich das nicht geschaft.
5. 
Ist AT-SPI inkl. dependencies installiert, beginnt die Testphase. Fuer alle Activities. Bugtracking. Guidelines schreiben. Etc.

Achja, die eigentlich Frage. Zeit. Geld.
Moechtest Du buisiness like einen Plan ohne einkalkulierte Selbstausbeutung :-?
Wenn man konzentriert Zusammenarbeitet und erste quick'n'dirty hacks macht, ist die untengenannte Auflistung natuerlich nicht haltbar. Kann man gar nicht oft genug sagen. Wenn man konzentriert Zusammenarbeitet und erste quick'n'dirty hacks macht, ist die untengenannte Auflistung natuerlich nicht haltbar. :-)
So richtig abschaetzen kann ich es nicht, zu viele unbekannte Faktoren, siehe oben.
Fuer die Wirtschaft/Sponsoren koennte es aber verkuerzt am Beispiel Headtracker so aussehen:

-Headtracker, 1. Lauffahige Version
Hardware			500.-
Entwicklung 			3PM (Personen oder auch Projekt Monate)
GUI/Activity, XO Vorraussetzung	2PM
Dokumentation			1PM
Nachtraegliche Anpassungen 	2PM

Ich habe an Simon vor kurzem eine Projektskizze fuer ein groesseres TTS Projekt geschickt, bisher leider ohne Rueckmeldung. Ich bin mir nicht sicher, was ihr zur Sponsorsuche braucht. Unabhaengig davon, wie man ein Projekt dann tatsaechlich gestaltet oder andere Projekte mit einfliessen laesst.  

Die Abhaengigkeiten fuer AT-SPI, nicht recursiv aufgeloest.

Dependencies (build time detected): atk bash binutils bzip2 cairo cf coreutils diffutils expat findutils fontconfig freetype gail gawk gcc glib glibc glitz grep gtk+ imake inputproto kbproto libart libbonobo libgnomecanvas libice libpng libsm libx11 libxau libxcursor libxdmcp libxevie libxext libxfixes libxi libxinerama libxrandr libxrender libxtst linux-header make mktemp net-tools orbit2 pango perl perl-xml-parser pkgconfig popt renderproto sed sysfiles tar util-linux xextproto xproto zlib

On Mon, 23 Jul 2007 21:18:17 +0200
Christoph Derndorfer <e0425826 at student.tuwien.ac.at> wrote:

> Hallo Yokoy,
> 
> ich habe mal eine allgemeine Frage zu den Accessability Projekten:
> 
> Wieviel Aufwand, in Zeit und Geld, schätzt du werden diese Projekte 
> circa benötigen?
>
> Bei den Text-to-Speech Sache kann ich mir a la Daumen x Pi noch 
> irgendwie was ausrechnen, aber wenn's um die Headtracking Sache (die ich 
> echt spannend finde!) geht hab ich wirklich keine Ahnung wieviele 
> Resourcen sowas erfordert, welche (halb-)fertigen Open-Source Frameworks 
> oder Projekte es da gibt, etc.
> 
> Liebe Grüsse aus dem kleinen Alpenländle,
> Christoph
> 
> linaccess at yokoy.de schrieb:
> > On Fri, 20 Jul 2007 11:04:01 +0200
> > linaccess at yokoy.de wrote:
> >
> >   
> >> Die Software hat eine Kontroll-LED und IR-LEDs zur Ausleuchtung auch im Dunkeln.
> >>     
> >
> > Hmm, waere auch nicht schlecht :-)
> > /s/Software/Kamera
> >
> > yokoy
> >   
> _______________________________________________
> Olpcaustria mailing list
> Olpcaustria at tema.lo-res.org
> http://lists.lo-res.org/mailman/listinfo/olpcaustria

-- 