Re: Gnome-braille.

Hi All:

I think a while back we had the discussion of rolling better i18n
support (e.g., a lot of the extra stuff that gnome-braille does) into
BrlTTY/BrlAPI, thus simplifying the setup and use of braille.  It also
puts the functionality into the hands of people who are properly
resourced to support it.  I thought we concluded that was probably the
right way to go.  

What happened to that idea?

Will

On Thu, 2006-10-19 at 00:04 +0100, Bill Haneman wrote:
> Samuel Thibault wrote:
> > As discussed a few months ago, gnome-braille depends on
> > - libgobject for contraction/language module management
> > - libglib for tricky stuff like unicode handling.
> >   
> I don't have any objection to reworking this to remove
> GObject, but it makes no sense to do that without removing the glib 
> dependency as well.  The problem with removing glib is that 
> gnome-braille needs very sophisticated unicode support, which is much 
> harder to come by that one would think.
> 
> If we have a fully desktop-agnostic unicode library alternative then I'd 
> be happy to work on swapping out glib/gobject.  The other problem though 
> is that gnome-braille is very modular/object-oriented and trying to do 
> nice lifecycle management in C without something like GObject is not 
> much fun.
> 
> So what does gnome-braille do that BriAPI and libbraille don't already 
> do?  Well, it provides an extremely general pluggable/chainable 
> conversion API (so that very complex braille conversions can be done, 
> like all sorts of Grade2 and Asian language braille), 
> multi-lang/multi-locale braille, optional braille context switching 
> markers, and some other localization stuff. Also, it provides a 
> bidirectional mapping between braille cell offsets and character/glyph 
> offsets throughout, so you always know what braille cell corresponds to 
> which character offset in the input string.  As far as I know, these are 
> things that the other APIs either don't offer or have difficulty with.
> 
> gnome-braille also supports several sorts of hardware and software 
> events, and both hardware and software "regions" within a braille display.
> 
> This is all stuff that probably isn't urgent for our English braille 
> users _yet_, but which I think will become increasingly important as we 
> get the more fundamental platform stuff working well.  While I wrote 
> gnome-braille as a testbed initially, it'd be very nice if we could 
> morph it into something everybody could make use of.  It already has 
> support for about 40 languages including some exotic stuff like 
> Devanagari/Hindi and Kanji Japanese braille; it also has a simple Grade2 
> English engine.
> 
> Best regards,
> 
> Bill
> > Else it can be used in any application, the output being done either via
> > BrlAPI or libbraille (or a gtk fake braille device)
> >
> > Samuel
> > _______________________________________________
> > gnome-accessibility-list mailing list
> > [email protected]
> > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
> >   
> 
> _______________________________________________
> gnome-accessibility-list mailing list
> [email protected]
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list