Re: [xougen] Re: Adding cruft to X

[Boris Tschirschwitz]

I followed the advice given on Xouverts home page and looked at "The Art
of UNIX Programming". It's interesting.
My questions: What does a blind person think of X? Should it matter?

I think it should. X is what most applications interact through, and
that's why it matters.
So maybe separating the keyboard and mouse drivers from the X server is
not such a bad idea. Have X connect to general input and output drivers,
or let it load the neccessary modules.

There's a link in the book mentioned above to an article by one of the
creators of X, Jim Gettys, called "The Two-Edged Sword" worth reading.
In this article he mentiones one UI goal: talk to your UI and have it
answer to you. He states that X has all the hooks for this.

So, even though we should certainly not build the hands-off sights-off
user interface in this project, we should set our sights on making this
possible.

Let's not argue about having a sound server in Xouvert or not, let's just
make it possible to build an UI for the blind on top of Xouvert.

Make interfacing to Xouvert for this UI as easy as for your run-of the
mill UI--eveybody would benefit.

Boris.


On Mon, 8 Sep 2003, Johann Henriquez L. wrote:

> Hi,
> here is my U$0,01 apport...
>
> >> >NAS, Esound, arts..
> >> >
> >> >We have three already thank you
> >> >
> >> >
> >> Agreed, that remote audio already exists, and works fine.
> >> However...there are disadvantages to using a system that doesn't ride
> >> within the X protocol. These include:
> >> 1) Prolifiration of APIs
> >> 2) Complexity of configuration (particularly firewalls, etc.)
> >> 3) Most importantly, strong synchronization. Unless the audio and
> >> display information travel through the same stream, and go through the
> >> same event handling API, there is no way to guarantee tight
> >> coupling(e.g. <20 milliseconds) between audio and display events.
> >
>
> > 3) MAS (www.mediaapplicationserver.net) does this.
>
> > As to 1), yes there are several network transparent sound servers, and
> > yes there are different apis. Main problem with that isn't the api
> > though, it's the fact that none of them are designed to be able to
> > synchronize audio/video over the network, with audio and video possibly
> > being displayed on different boxes. Afaik MAS is designed to do this.
>
> and there is other problem...
> you just can't use a KDE program in GNOME or a GNOME program in KDE if this
> programs use sound because one use ARTS and other use ESD... and what about
> non-KDE, non-GNOME applications? (e.g. AMSN, Mozilla) to use them i have to
> use: or artsdsp or esddsp (with both the result is very rare, and not in all
> apps this dsps work) or simply dissactive the deamon of sound.
>
> I think X, is a standard/procolol in the user graphic interface, this
> include: mouse, monitor, video card, keyboard, and sound.
>
> Having an X extension about sound, it will get transparent network, and
> finally an standard in desktop, because not only KDE or GNOME will be
> benefit, the alone apps will be benefit with this. (well, if everyone start
> to use it)
>
> but, there is another problem, let's pretend the X sound extension is
> adopted for all graphic-apps. What about non-X apps? (e.g. mpg321) this apps
> will have to do a plug-in to play, just like this apps have for esd and
> arts.
>
> i think the main reason to have an X sound extension is to become a standard
> for all apps that use sound, and the network transparency.
>
>
>
> Regards
> Johann Henriquez Lucero
> ________________________________________
> mailto:address@hidden
> ICQ #137470123   GNU/Linux user #279323
> ________________________________________
>
>
>
> _______________________________________________
> xouvert-general mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/xouvert-general
>