Re: gnome-mag and gnopernicus magnifier services TODOs
- From: Carlos Eduardo Rodrigues Diogenes <cerdiogenes yahoo com br>
- To: Bill Haneman <Bill Haneman Sun COM>
- Cc: gnome-accessibility-list gnome org
- Subject: Re: gnome-mag and gnopernicus magnifier services TODOs
- Date: Mon, 19 Sep 2005 16:38:55 -0300
Hi Bill:
Bill Haneman wrote:
Hi Carlos:
Carlos Eduardo Rodrigues Diogenes wrote:
What are the plans in gnome-mag, mainly for the full-screen. There is
any roadmap of what can be used to acquire a good full-screen service.
Fullscreen magnification now works if you use a recent Xserver with
the DAMAGE and XFIXES extension, and with the 'dummy driver' virtual
frame buffer configured. Please see a recent version of the Gnome
Accessibility Guide appendices for technical information on
configuring this.
I really like the results using this way of fullscreen magnification.
This works much faster then the 'diopter' program developed by Keith
Packard. Otherwise, I don't know if this is the best way to follow,
because I don't know much about the underlay involved, someone can
clarify this?
I saw this video http://vizzzion.org/stuff/xgl_wanking.avi and is
showed some operations in zoom in and out with very amazing results
(anyone can identify what was used to acquire that?). The Composite
Extension is a good solution?
That demo uses GL to do lots of its rendering. There is talk of
moving much of the X server to using GL for its rendering, so we'd get
a lot of this performance "for free" then.
If I'm uderstading how gnome-mag works, this is because gnome-mag uses
Gtk to capture and to expose the images on screen and because Gtk always
try to use the resources from Xserver to improve it's perform? I saw
that the Gtk 2.8 supports Cairo, what permits anti-aliased render and
other good thinks with an X server using GL in it's underlaying.
Anyone have ideia how the magnification is acquired in the video cited
above? There is anything in the OpenGL API that permits scale
transformations with that quality?
Composite will help too, but gnome-mag doesn't include any code that
uses COMPOSITE yet; doing so will require a significant amount of new
gnome-mag development.
Do you think that this a way that we can follow? Or you think that we
must clarify other things to take a decision?
If you think that this is a way that we can follow I'm want to help.
Otherwise, what are the points that must be clarified?
Either Olaf or Gunnar Schmidt (sorry, I can't remember which of the
two is working on this at the moment) is currently working on a
COMPOSITE-based magnifier for the free desktop. There are a few
technical issues which need to be solved in the extensions/xserver
itself before such a composite-based magnifier can become a practical
reality. The primary issues have to do with conversions between the
two resulting mouse coordinate systems, and ensuring that the mouse
pointer appears at the appropriate position on screen (and the no
"extra" mouse cursor appears).
How I yet said, I saw the 'diopter' application developed by Keith
Packard that do a COMPOSITE-based magnifier in the xapps directory of
the free desktop cvs tree. Is this software that you are saying about?
Do you have any reference where to find informations about this and
contact the developers?
Someone here saw Lunar or ZoomText magnifier for Windows? They have
some resources very interesting in half magnifier screen mode. How
the same effect can be acquired? I think that using the composite
extension can be a way. What do you think?
The documentation of gnopernicus (the magnifier part) and gnome-mag
are very poor. What is the better thing to do, an API reference with
doxygen or class diagrams? An API reference is simple to generate
with doxygen, why this was not done yet? There is no need for it yet?
We haven't introduced a dependency on doxygen yet, but I agree that it
would be a good idea. If someone wants to produce a patch to run
doxygen if it is available, then I will update the inline source
documents so that the result is more clear.
produce a patch is modify the configure.in file to the generated
configure script verify if the doxygen is avaliable and use it to
generate the documentation? I think that it is what must be done, but I
never play with the autotools, so I get in doubt. If is this I can do it...
Carlos.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]