Re: [orca-list] miscellaneous Orca comments

[Janina Sajka <janina rednote net>]

You're responses are sometimes valid, and sometimes simply inflamatory.
One at a time:


David Csercsics writes:
> Well, the problem is integration.
Of course. Isn't it always whatever the app?

If you need to paste something from
> a website that you required javacrapscript or  some other bizarre GUI
> weirdness to get at into a terminal window like the one you use to
> read your mail then you can't do that from a text console because the
> data is in the GUI. That's just one example but there are others.

I'm having only two problems going back and forth between my console
based screen sessions and the gui desktop. Accessing clipboard data is
one of them. The other is tts integration. Speech Dispatcher is supposed
to fix that, but at the moment our tests suggest it's not ready for
that, so I'm using separate TTS engines in each.

The clipboard issue is a real issue, however. I've asked about that as
recently as last week onthis list. S;urely, it's a resolvable issue.
Data lives at some address somewhere, so why not create the bridge to
read from where you need?

> The
> point is that sighted people do things from GUI terminals with no loss
> in functionality so we should be able to as well.

Of course, but what do you want Orca to not work on while enhancing
terminal access?  Oh, and by the way, I know sighted folks who go back and forth
between gui and console as well. It all depends on what the task is, and
what the best available tool for that task might happen to be.

> Nevermind that the X
> server supports graphics cards much more efficiently than a framebuffer
> device for some  video cards and it is possible to get a much larger text
> area from a GUI terminal than you can with a console.

Interesting. Want to tell me how to best 64 x 160 on my consoles?

> Oh, and flipping
> between console and X all day causes a bit of lag as well because the card
> is dropping in and out of graphics mode.

I see maybe 200-400 ms lag. But that's nothing compared to the increased
key echo lag on each and every char I type. Get real. The two are not
comparable issues.

> And, yes, Speakup is not part
> of mainline so there is no guarantee it won't break something else. It
> still needs work to properly handle the kernel preempt and things like
> this so it is currently negatively affecting the performance of some
> systems.

Now we're getting to the inflamatory part. I suggest you had best
provide your evidence for negative impact. I haven't seen it,
anywhere--over ten years of using current release, or nearly current
release kernels. May I( add that we've used Speakup kernels on
production corporate servers--machines that don't really need it, just
so we can speak more authoratatively about this? We believe in eating
our own dog food, as the W3C aphorism has it.

> Not saying that raw console text access isn't required either
> because it is. If  your X bails on you for some reason you'd better be
> able to read the screen but the point is that you should be able to use
> any part of the system equally  well. Half-baked access is worse than
> no access at all usually.

Usually? Don't you mean it's always better to have access than not? But,
isn't it nice we can have choices? So, those of us satisfied with
half-baked can continue to refuse hot meals?

Janina