Re: Lubuntu and Accessibility

[bando?ers]

yes, that's what I understand, and it can't access very standard and important aps that we are used to using with gnome in Ubuntu, e.g. gpartit, and several others.
I've hardly put it throught it's paces, and as you say I'm not running anything so minimalist as is being discussed. I really don't think full fledged access to a graphical computing invironment can be done with less than 256mb, and this means forget the multi tasking that most ppl want to do these days.
Please prove me wrong, but of course every year one waits the less low spec hardware will be around in good enough shape to be worth keeping on life-support.
I've not seen major fall-off in screen-reader performance until droping below 1GHz, but conbine a slow processer with low ram, and you are talking frustration.

I think if accessibility is pretty responsive with 256MB then you would have something useful that could fill in quite a few gaps, but make it work with lots of programs.
B.H.

On Mon, May 23, 2011 at 11:27:56PM -0400, Alex H. wrote:
> Hi,
>
> Doesn't Adriane Knoppix run some form of LXDE with Orca? From the
> little I've used it, it's not slow, but then again I've got much
> better specs than what we're aiming for in this thread.
> I agree that running Orca on anything slower than 1.5Ghz is just
> simply painful, even with the increasing responsiveness of it. It's
> certainly a resource hog and with a system that slow, might as well
> just run CLI.
>
> I think a more useful goal to pursue would be making XFCE more usable.
> http://wiki.xfce.org/releng/4.10/roadmap/accessibility
>
>
> On 5/23/11, Luke Yelavich <the...@ubuntu.com> wrote:
> > On Tue, May 24, 2011 at 09:58:58AM EST, Phill Whiteside wrote:
> >> >From a general chat to our head of development on lubuntu, he is of the
> >> opinion that if the code is really (and I mean really) tight, that it
> >> would
> >> be possible to include within the very tight constraints that we are
> >> committed to be able to uphold the inclusion of accessibility and has
> >> agreed
> >> that we should really strive to attain this.
> >
> > The first thing is making sure LXDE is actually accessible, i.e make sure it
> > has keyboard shortcuts, and supports the launching of the accessibility
> > framework at startup etc. As to using the LXDE GUI with Orca etc, I think
> > the biggest problem here is the use of python. The components of the stack
> > written in c should be performant enough to work, and if they're not, then I
> > am sure upstream would be willing to help try and optimize them a little
> > more, but Orca being python is unfortunately a rather big blocker for this
> > environment. I remember running Orca on a dual Celeron 466 a few years back
> > in GNOME, and it was rather laggy in performance, I.e a quarter to half a
> > second would go by before I got speech feedback from my action.
> >
> > So while I think the goals of getting Lubuntu more accessible are noble, I
> > am not sure it will be possible for it to be doable with acceptable
> > accessibility performance for users. I am not saying don't try, but unless
> > Orca or another screen reader was developed in c, then using orca on LXDE is
> > likely to be somewhat painful.
> >
> > Luke
> >
> > --
> > Ubuntu-accessibility mailing list
> > Ubuntu-acc...@lists.ubuntu.com
> > https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
> >
>
> --
> Ubuntu-accessibility mailing list
> Ubuntu-acc...@lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility

[Jen]

Hi,
Would a screen-reader written in C++ solve some of these issues, because
it's pre-compiled? If so does a C++ screen-reader for any Linux GUIs
exist, and how good is it?

Cheers,
Jen.

[Tony Sales]

Hi Jen, I suspect if would speed it up a little but I think many of the bottlenecks are caused by the way Orca works e.g. on Firefox - this is slow because everything has to be loaded into Orca from the Firefox window and this would not be sped up by writing this process in C++ - It is also my understanding that while python takes more time to start a program because it is compiled once it is actually running in the ram I don't think there should be any obvious lag based on the choice of language - but I could be wrong (I often am )

--
You received this message because you are subscribed to the Google Groups "The Vinux Support Forum" group.
To post to this group, send email to vinux-...@googlegroups.com.
To unsubscribe from this group, send email to vinux-suppor...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/vinux-support?hl=en.

Vinux Home Page:  http://vinuxproject.org/
Vinux Wiki Documentation:http://wiki.vinuxproject.org/

[Alex H.]

Hi,

I agree with Tony here, Python itself isn't that slow. Look at NVDA on
Windows. Fast as ever even on slow hardware. The issue i think is the
underlying Linux a11y stuff and that can't exactly just be re-written.
This is going to be a long painful road, I think.

Alex

[Christopher Chaltain]

Are you saying that NVDA was written in Python? I thought that lower
level junks of NVDA were rewritten in C or C++ to get better
performance, but maybe I'm getting my screen readers mixed up.

--
Christopher (CJ)
chal...@gmail.com

[Alex H.]

Hi Christopher,

Yes, parts of NVDA are written in C, like the code to handle
VirtualBuffers on a web page. That code was originally written in
Python but they converted it to C and introduced some in-process stuff
which really sped up the loading of pages. In that respect, C was
faster than Python. The rest of NVDA, as far as I'm aware, is still
coded in Python.
Python can be faster than C, it really just depends on the application
and how things are written.

Alex