Re: [linux-audio-dev] libcui - design-question

Alfons Adriaensen <fons.adriaensen@email-addr-hidden> writes:

> On Mon, Sep 19, 2005 at 10:46:26AM +0200, Mario Lang wrote:
>
>> I've feared this effect of half-hearted accessibility support
>> for graphical desktops under Linux, and it seems my fears have come
>> true: Just because there *is* an attempt to make GUIs accessible
>> doesnt necessarily mean that all people needing accessibility
>> support should immediately be forced to use the new shiny (crashing)
>> stuff. There is a reason why we blind people prefer text mode
>> UIs, and that is because they are way more efficient than every
>> Accessible GUI can ever be. That has been true when 99% of
>> the user base had to switch from DOS to Windows 10 years
>> ago, and it will continue to be true under Linux.
>
> Right. I just fail to understand why people come up with
> things like ATK and suggest that 'any GUI based app' will
> instantly be accessible - you don't need to be a genius to
> see this will never work.

Its a split problem between genericness and public relations. In a perfect
world, of course every GUI app would link to ATK, and ATK would
provide an uniform view on all ATK enabled apps for assistive
technologies (read, screen readers). But as we know, the world isn't perfect.
OTOH, to achieve most impact, accessibility library coders have to sort of
advocate ATK (or any other api in that area) as the solution for
everything, since that attitude will make more app coders have a look
at it... And, it would of course be horrible if we had to support more than
one kind of ATK. The point here is that ATK is a good solution whenever
applicable, but a pure text mode UI is still more efficient and less bloated.
Imagine, if one app I need to use had a GUI only interface with ATK bindings,
and it would actually sort of work with Gnopernicus, I'd need to fire up
the whole X thing with all related libraries and servers and all, just
to have an app (the model) make X draw a complete GUI for nothing (I dont
see it anyway), therefore consuming unnecessary resources. In addition,
another layer of software would translate that model info back to
a flat text view again, so that I can actually read it. Its pure
bloat and overkill, and to be avoided whenever possible, IMO.

> There is at least one Linux audio app that gets this right
> ATM and that is Linuxsampler

Add ecasound to the list.

> - complete separation of app and interface. You can controll all of
> it by typing commands in a terminal running netcat.

Agreed. However, I would have prefered if ecasound and LS would have
used OSC as the transport, but hey, a translator should be writable :-)

> Aeolus is going the same way: in the next official release
> the X interface will be a plugin, and a text only version
> of the UI will be provided.

Great! Do you have a PayPal account I can donate money to for this rewrite?

> If ever I find the time to do an AMS II, that will be written
> from the start with a text interface.

Isn't Om actually AMS II? :)

> It's a bit more effort, but worth it.

Whenever someone on LAD/LAU comes up with a scriptability question, I
sincerely hope this is the day the LAD coder community will realize
that merging core with GUI code is no good. I'll keep hoping, especially
now that yet another app will be deguified soon!

-- 
CYa,
  Mario