Joey Hess, le Wed 29 Mar 2006 10:17:49 -0500, a écrit :
Samuel Thibault wrote:
And it happens that for now, the default frontend is the newt frontend
(which is fine) in bterm (which is not yet accessible to blind
users). So a bterm-accessibility solution needs to be found, so that
Samuel Thibault wrote:
And it happens that for now, the default frontend is the newt frontend
(which is fine) in bterm (which is not yet accessible to blind
users). So a bterm-accessibility solution needs to be found, so that
dumb-Bob _blind_ user won't either have to tinker anything and yet
Samuel Thibault wrote:
Joey Hess, le Wed 29 Mar 2006 10:17:49 -0500, a écrit :
Samuel Thibault wrote:
And it happens that for now, the default frontend is the newt frontend
(which is fine) in bterm (which is not yet accessible to blind
users). So a bterm-accessibility solution needs to
Joey Hess, le Wed 29 Mar 2006 11:59:26 -0500, a écrit :
Samuel Thibault wrote:
Joey Hess, le Wed 29 Mar 2006 10:17:49 -0500, a écrit :
Samuel Thibault wrote:
And it happens that for now, the default frontend is the newt frontend
(which is fine) in bterm (which is not yet accessible
Samuel Thibault wrote:
What are you thinking about? Preseeding? Kernel command line arguments?
These are non-trivial. I actually wonder what non-interactive process
can be trivial enough for dumb-Bob user :)
if brltty_device_detected; then
debconf_set debconf/frontend whatever
[quoted lines by Joey Hess on 2006/03/29 at 10:17 -0500]
Changing the frontend could be easily done when bterm is started up.
How would I, being completely blind and incapable of seeing the screen without
my braille display being able to view what's on it, be able to do that? Please
have someone
Joey Hess, le Wed 29 Mar 2006 13:24:41 -0500, a écrit :
Samuel Thibault wrote:
What are you thinking about? Preseeding? Kernel command line arguments?
These are non-trivial. I actually wonder what non-interactive process
can be trivial enough for dumb-Bob user :)
if
Samuel Thibault wrote:
The problem is that it would not only solve the problem only for debian,
but that new front-end would also probably be only developped and tested
by blind people, i.e. very _few_ people, compared to the whole debian
community, hence foresee bugs such. And I wonder how
Samuel Thibault, le Thu 30 Mar 2006 01:12:57 +0200, a écrit :
cdebconf's text frontend is probably the most appropriate frontend for
use with brtltty anyway,
Are you sure this is really true?
I'm not blind so my voice might be suspicious, but I find it a lot
easier to use the newt
Joey Hess, le Wed 29 Mar 2006 18:03:31 -0500, a écrit :
The current approach --i.e. brltty reads everything that runs on the
system-- is just fine: programmers write their applications, and only
very few blind people are needed for maintaining brltty.
What you are proposing (rewriting
[quoted lines by Samuel Thibault on 2006/03/30 at 01:12 +0200]
I'm not blind so my voice might be suspicious, but I find it a lot
easier to use the newt frontend than the text frontend: choosing an
option in a long newt list is just a matter of pressing arrows, while
browsing through the text
[quoted lines by Samuel Thibault on 2006/03/30 at 01:18 +0200]
I forgot to mention that for speakup, the text frontend seems to me much
better than newt indeed (that's why it is included on speakup floppies).
What works well for speech doesn't necessarily work all that well for braille.
Braille
Samuel Thibault wrote:
I'm not blind so my voice might be suspicious, but I find it a lot
easier to use the newt frontend than the text frontend: choosing an
option in a long newt list is just a matter of pressing arrows, while
browsing through the text list is quite tedious.
Could be fixed
Joey Hess, le Wed 29 Mar 2006 19:03:58 -0500, a écrit :
Samuel Thibault wrote:
I'm not blind so my voice might be suspicious, but I find it a lot
easier to use the newt frontend than the text frontend: choosing an
option in a long newt list is just a matter of pressing arrows, while
Hi,
Here are quick-and-dirty-but-working implementations.
Regards,
Samuel
diff -ur bogl-0.1.18/bogl-term.c bogl-0.1.18-mine/bogl-term.c
--- bogl-0.1.18/bogl-term.c 2003-11-05 05:38:22.0 +0100
+++ bogl-0.1.18-mine/bogl-term.c2006-03-28 04:09:07.0 +0200
@@ -26,24 +26,84
Joey Hess wrote:
Samuel Thibault wrote:
I'm not saying that. I'm seeing that debian-installer uses bterm by
default now.
d-i uses bterm, or writes raw data to a serial port, or to the console,
or it uses GTK. d-i is frontend independant and it would be trivial to
make it dump
Joey Hess, le Tue 28 Mar 2006 14:49:00 -0500, a écrit :
Samuel Thibault wrote:
I'm not saying that. I'm seeing that debian-installer uses bterm by
default now.
d-i uses bterm, or writes raw data to a serial port, or to the console,
or it uses GTK. d-i is frontend independant and it would
Samuel Thibault wrote:
I'm not saying that. I'm seeing that debian-installer uses bterm by
default now.
d-i uses bterm, or writes raw data to a serial port, or to the console,
or it uses GTK. d-i is frontend independant and it would be trivial to
make it dump well-formatted text to bterm, which
Joey Hess, le Tue 28 Mar 2006 15:11:26 -0500, a écrit :
Joey Hess wrote:
Samuel Thibault wrote:
I'm not saying that. I'm seeing that debian-installer uses bterm by
default now.
d-i uses bterm, or writes raw data to a serial port, or to the console,
or it uses GTK. d-i is frontend
Hi,
Dave Mielke, le Tue 28 Mar 2006 15:40:43 -0500, a écrit :
solving the problem as a whole in one place for all cases. This can easily be
done by changing bterm to passively export its view of the screen in a
software-readable way.
For which I already proposed a working implementation.
Hi:
I, personally, don't want to see any solution which is Debian-specific, or any
other distribution-specific either. The Debian installer uses betrm. So does
RedHat when Asian characters are used. So/ probably/ do other distributions.
Regardless of what any individual installer does, bterm can
Samuel Thibault wrote:
The Debian installer now uses bterm for better i18n. However, brltty
(the daemon that permits visually impaired people to access debian)
isn't able to fetch what bterm displays, and hence visually impaired
people can't use the Debian installer. Of course, some solution
Hi,
Joey Hess, le Mon 27 Mar 2006 15:44:58 -0500, a écrit :
Samuel Thibault wrote:
The Debian installer now uses bterm for better i18n. However, brltty
(the daemon that permits visually impaired people to access debian)
isn't able to fetch what bterm displays, and hence visually impaired
Joey Hess wrote:
All brltty-udeb needs to do to disable the use of the framebuffer is
install a /lib/debian-installer.d/S40brltty that does:
TERM_FRAMEBUFFER=
Then any boot media that includes brltty-udeb will automatically run
without bterm.
Hmm, it might be cleaner to stick a test for
Samuel Thibault wrote:
Mmm, you're missing the point: we would rather have brltty-udeb included
in official CDs for letting blind people just boot the official CD
and install debian. And there's no reason why asian blind people (for
instance) shouldn't be able to install debian, so brltty
Hi,
Joey Hess, le Mon 27 Mar 2006 16:26:48 -0500, a écrit :
Samuel Thibault wrote:
Mmm, you're missing the point: we would rather have brltty-udeb included
in official CDs for letting blind people just boot the official CD
and install debian. And there's no reason why asian blind people
Samuel Thibault wrote:
There's also no necessary connection that I can see between bterms's
display of asian characters in an utf-8 font and brltty. The installer
is not dependent on bterm to emit asian characters, all bterm provides
is a way to display said characters at the linux
Joey Hess, le Mon 27 Mar 2006 17:04:09 -0500, a écrit :
Samuel Thibault wrote:
There's also no necessary connection that I can see between bterms's
display of asian characters in an utf-8 font and brltty. The installer
is not dependent on bterm to emit asian characters, all bterm
[quoted lines by Samuel Thibault on 2006/03/28 at 00:13 +0200]
Hi:
I'm not saying that. I'm seeing that debian-installer uses bterm by
default now. Well, fine, but brltty needs to get that utf-8 stream
somehow, for being able to display it on braille devices.
Where does bterm maintain the
Hi,
Dave Mielke, le Mon 27 Mar 2006 17:50:48 -0500, a écrit :
[quoted lines by Samuel Thibault on 2006/03/28 at 00:13 +0200]
I'm not saying that. I'm seeing that debian-installer uses bterm by
default now. Well, fine, but brltty needs to get that utf-8 stream
somehow, for being able to
Dave Mielke, le Mon 27 Mar 2006 18:19:56 -0500, a écrit :
[quoted lines by Samuel Thibault on 2006/03/28 at 00:57 +0200]
In its own memory, which I proposed (in the very first mail of the
discussion) to export somehow to brltty, via some /dev/bterm mmap()ed
file for instance (very easy to
On Tue, Mar 28, 2006 at 12:57:32AM +0200, Samuel Thibault wrote:
In its own memory, which I proposed (in the very first mail of the
discussion) to export somehow to brltty, via some /dev/bterm mmap()ed
file for instance (very easy to implement in bterm's code: a mere open()
then mmap() instead
[quoted lines by Samuel Thibault on 2006/03/28 at 00:57 +0200]
Hi:
In its own memory, which I proposed (in the very first mail of the
discussion) to export somehow to brltty, via some /dev/bterm mmap()ed
file for instance (very easy to implement in bterm's code: a mere open()
then mmap() instead
Package: debian-installer
Version: 20060304
Severity: important
Hi,
The Debian installer now uses bterm for better i18n. However, brltty
(the daemon that permits visually impaired people to access debian)
isn't able to fetch what bterm displays, and hence visually impaired
people can't use the
34 matches
Mail list logo
