Re: D-BUS based magnification API

Hi Peter,

After reading lot's of messages (from 2005 to today) about the
Metacity development, I don't think that the GNOME community want to
switch Metacity due all the maintenance that it have and the good
integration that it have with GNOME and I really don't want to start
this discussion again!

Anyway, there is still some development in it, as can be seen in the
bugzilla component related to it.

So, I get back in my comments about Compiz and reconsider Metacity as
good house for magnification.

After reading some old messages
(http://mail.gnome.org/archives/metacity-devel-list/2006-October/msg00006.html)
the idea to use "unmanaged" zoom regions was already there.

When a compositor is running, gnome-mag can create the windows needed
and pass they to the metacity (the mechanism to do it can be generic,
so we can support others WCM) compositor so it will draw the
composited scene in it. This way we can separate the Compositor from
the Magnifier, what is good from my point of view, since we can re-use
much of the code in a port of the magnifier utiliy.

I will look with more attention to the XRender operators and GL pixel
operations to see how we can implement image filters in an efficient
manner.

2007/8/30, Peter Korn <Peter.Korn <at> sun.com>:

Re: D-BUS based magnification API

On 8/30/07, Carlos Eduardo Rodrigues Diógenes <cerdiogenes <at> yahoo.com.br> wrote:
> 2007/8/29, Peter Korn <Peter.Korn <at> sun.com>:
> > Hi Carlos,
> >
> > In two places you mention going with Metacity:
> >
> > > ...
> > >
> > >> * Understanding where the masses are going with respect the
> > >>   composite extension manager.  Is it metacity, compiz, something
> > >>   else?  Where/how does gnome-mag fit in this new world?
> > >>
> > >
> > > There was a big discussion about the Metacity compositor and compiz:
> > > http://mail.gnome.org/archives/desktop-devel-list/2006-October/msg00011.html
> > > and GNOME appear that will not replace Metacity by Compiz. The
> > > discussion is quite old and things maybe changed, but I didn't saw any
> > > other discussion about a replacement, so the path, IMHO, is metacity.
> > >
> > > If Metacity doesn't introduce composite effects some day (something
> > > that I doubt) we already have basic composite (let's say that the code
> > > to track windows is there  being done in gnome-mag.
> > >
> > > We must have a compositor and appear that the best path, considering
> > > the effects cited in the other messages, is to use Metacity, since
> > > it's still have a good architecture (thanks Sandmann) IMHO. Moreover,
> > > in reply to Eitan (I send if the wrong e-mail, so it doesn't appear
> > > yet in the list), I cited about an way to keep the resolution of text
> > > and SVG images in the magnified image, that is: wrap cairo and, when
> > > the magnifier is activated, instead of draw (or instead of only draw) in the

Re: D-BUS based magnification API

2007/9/5, Kristian Lyngstøl <kristian <at> bohemians.org>:
<snip>
> I've been following this thread closely, and I think it's a bit of
> overkill to start working on a magnifier inside Metacity or doing
> major work to Metacity at this point to improve gnome-mag. Compiz does
> require GL, and it is not without problems with regards to drivers,
> but I do believe that the desktop is moving in the direction of a
> composited window manager with GL effects, be it Compiz or something
> else.
>
> As such, Metacity should either be turned into something that can
> provide the same level of effects that Compiz does, or it should be
> left as-is, as a great window manager in maintenance mode. Otherwise
> all I see is a lot of work being poured into Metacity that'll be
> mostly forgotten in a few years, or considered a fall back for the
> people who still don't have a GL card.
>

Just FYI, Metacity can do the same effects as Compiz and it's
Compositor is based upon GL. The biggest problem with Metacity
Compositor is that it still have bugs to be delivered to the user.
Although some effects are quite stable.

Please, take a loot at
http://mail.gnome.org/archives/desktop-devel-list/2006-December/msg00146.html

Best regards,
Carlos.

Re: [g-a-devel] D-BUS based magnification API

On 9/5/07, Carlos Eduardo Rodrigues Diógenes <cerdiogenes <at> yahoo.com.br> wrote:
> 2007/9/5, Kristian Lyngstøl <kristian <at> bohemians.org>:
> <snip>
> > I've been following this thread closely, and I think it's a bit of
> > overkill to start working on a magnifier inside Metacity or doing
> > major work to Metacity at this point to improve gnome-mag. Compiz does
> > require GL, and it is not without problems with regards to drivers,
> > but I do believe that the desktop is moving in the direction of a
> > composited window manager with GL effects, be it Compiz or something
> > else.
> >
> > As such, Metacity should either be turned into something that can
> > provide the same level of effects that Compiz does, or it should be
> > left as-is, as a great window manager in maintenance mode. Otherwise
> > all I see is a lot of work being poured into Metacity that'll be
> > mostly forgotten in a few years, or considered a fall back for the
> > people who still don't have a GL card.
> >
>
> Just FYI, Metacity can do the same effects as Compiz and it's
> Compositor is based upon GL. The biggest problem with Metacity
> Compositor is that it still have bugs to be delivered to the user.
> Although some effects are quite stable.

I stand corrected, I based parts of this mail on assumptions from
using GNOME, not working on the code. However, I still think my
argument applies.

With regards to GL effects, you can't even compare Compiz and
Metacity. In fact, if you are using GL in Metacity to do magnifier

Re: D-BUS based magnification API

2007/9/4, Carlos Eduardo Rodrigues Diógenes <cerdiogenes <at> yahoo.com.br>:
> * Make the "unmanaged" zoom region concept work;

I was think how this can be implemented and the only way that I can
realize to do this is using shared memory. Maybe this is due my lack
of CORBA knoweledge. Any tips about this?

Best regards,
Carlos.

LSR activities?

Hi all,

is there someone out still developing LSR, or is everybody using ORCA at
the moment? I know that the latest LSR version is from very early June,
and that at the LSR mailing list the latest mail has been created June
19.

Thanks,

Michael
--

-- 

Dipl.-Phys. Michael Zacherle    zacherle <at> szs.uni-karlsruhe.de
Studienzentrum für Sehgeschädigte       Tel: +49-721-608.6951
Universität  Karlsruhe (TH)             Fax: +49-721-608.2020
Engesserstraße 4, 76128 Karlsruhe

_______________________________________________
Gnome-accessibility-devel mailing list
Gnome-accessibility-devel <at> gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel

Re: LSR activities?

Hi Michael:

From
http://mail.gnome.org/archives/gnome-accessibility-list/2007-June/msg00000.html:

"Development on LSR as a screen reader for GNOME will cease."

Will

On Fri, 2007-09-14 at 11:11 +0200, Michael Zacherle wrote:
> Hi all,
> 
> is there someone out still developing LSR, or is everybody using ORCA at
> the moment? I know that the latest LSR version is from very early June,
> and that at the LSR mailing list the latest mail has been created June
> 19.
> 
> Thanks,
> 
> Michael
> _______________________________________________
> Gnome-accessibility-devel mailing list
> Gnome-accessibility-devel <at> gnome.org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel

[Fwd: Announcing Orca v2.20.0]

Hi All:

These have been a very busy 6 months for the Orca team.  When I look
back on where we were 6 months ago, I'm amazed at how far we've come.
Thanks everyone for your support and contributions.  Orca is truly a
community project and I feel lucky to be involved with it.

For the very brave of you, feel free to keep pulling from the Orca SVN
trunk.  It will contain all the work we're doing for GNOME 2.22, and
you'll get it as soon as we do it.  Keep in mind, though, that it will
become unstable pretty soon as we work on rolling in the pyatspi
support:

  svn co http://svn.gnome.org/svn/orca/trunk orca-trunk
  cd orca-trunk
  ./autogen.sh
  make
  sudo make install

For those of you looking for more stability, keep pulling from the Orca
gnome-2-20 branch.  The Orca gnome-2-20 branch won't be getting new
features, but we do plan on rolling in high priority bug fixes:

  svn co http://svn.gnome.org/svn/orca/branches/gnome-2-20 orca-2-20
  cd orca-2-20
  ./autogen.sh
  make
  sudo make install

The next 6 months to GNOME 2.22 will be just as busy as the past 6

gnome-speech, and audio output, moving forward.

Greetings all.
For a while now, it has been possible to have multiple audio streams playing at the same time, using ALSA's 
dmix plugin under Linux. This also has meant the ability to have speech audible at the same time as other 
audio. Users have desired the ability to do this for a while now, particularly since it has been possible in 
other operating systems for a long time.

Since eSpeak has been developed, we have had a very usable synthesizer for speech output, which supports a 
growing number of languages. Since this synthesizer is cross-platform, the choice was made by the author
to 
use PortAudio, thereby supporting all platforms where PortAudio is available. Since PortAudio v19, it
has been 
possible to use Alsa for audio output via PortAudio. In theory, this is good news, however in practice, this 
has created more problems than it should solve, for the following reasons, as far as I see things:

* PortAudio v19 has had no official release, and so seems to be in a rather constant state of flux, making it 
difficult for distros to reliably support a working version.
* PortAudio's alsa implementation seems to currently be broken, which is evident while using eSpeak, and 
attempting to speak multiple strings of text rapidly over a short period of time.
* As far as I've seen, there is no easy way for the user to select which output device portaudio should use. 
Added to that, if more than one app is using portaudio, this will affect that application as well as espeak, 
which may not be what the user desires.
* All proprietary synths only support oss output, which makes simultaneous audio and speech currently 
impossible.

What I would like to propose, is the following. Since a large porshion of GNOME's multimedia framework is
now 
using gStreamer, I would like to suggest that we make all gnome-speech drivers use gStreamer, and if
possible, 
add another option to the sound preferences, to allow the user to select which soundcard they wish to use for 

Re: [u-a-dev] gnome-speech, and audio output, moving forward.

Hi Luke:

First of all, I say "Hear, hear!"  The audio windmill is something
people have been charging at for a long time.  Users who rely upon
speech synthesis working correctly and integrating well with the rest of
their environment are among those that need reliable audio support most
critically.

I see two main proposals in the below:

1) Modify gnome-speech drivers to obtain samples from their
   speech engines and then handle the audio playing themselves.
   This is different from the current state where the
   gnome-speech driver expects the speech engine to do all the
   audio management.

   This sounds like an interesting proposal.  I can tell you
   for sure, though, that the current gnome-speech maintainer
   has his hands full with other things (e.g., leading Orca).
   So, the work would need to come from the community.

2) As part of #1, move to an API that is pervasive on the system.
   The proposed API is GStreamer.

   Moving to a pervasive API is definitely very interesting, and
   I would encourage looking at a large set of platforms:  Linux
   to Solaris, GNOME to KDE, etc.  An API of recent interest is 
   Pulse Audio (https://wiki.ubuntu.com/PulseAudio), which might
   be worth watching.  I believe there might be many significant
   improvements in the works for OSS as well.