On Wed, 2007-08-29 at 15:14 -0300, Carlos Eduardo Rodrigues Diógenes wrote: > > * Eliminating the Bonobo dependency from accessibility stuff in GNOME. > > Note that this doesn't necessarily equate to eliminating CORBA. > > I really have no idea how much impact this would cause. I learned only > basic things about Bonobo and understand that it only turn easier the > IPC work. CORBA appear to be much more low-level and I have no idea > how it will still be used in GNOME desktop. I'm goingo in D-BUS > direction, since it's appear to be much more simple for desktop IPC > and it's also appear to have much more documentation available.
Keep in mind that migrating to D-BUS would end up causing incompatible changes for gnome-mag users (e.g., Orca would have to now talk D-BUS instead of CORBA/IDL). If the community moves in this direction, this incompatibility represents an opportune time to really discuss what we think is the 'right' approach given our collective experiences. As such, it really is great that you opened this discussion up on the list. I thank you for that, even if you might eventually regret it. :-) > 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 This brings up a very good point with respect to what we want the beast to do. There was some discussion of alpha blending, but I wonder if we want to be able to support more sophisticated things. For example, do we want it to re-render text with a larger/different font and/or with a different foreground/background? Do we want to do so for the entire zoomed area, or do we want to do selective levels of zooming and image filtering across the area (e.g., the character/word/line around the caret gets special treatment)? My mantra for Orca has been "let the user requirements drive the architecture, not the other way around." I think the same should apply here. I'd really like to encourage the involvement of end users in this discussion. If we are going to redo the GNOME magnification world (I think we should), we really need to take a step back and understand the user models. > Yeah, this is something possible from my POV and this is something > that happened with the introduction of the colorblind-applet. Probably > we can have a configuration option in System => Preferences where the > user can adjust magnification options and have the API where ATs can > tweak the magnifier behaviour on the fly. Sounds good. I think the things to think about are what the user models will be (sorry to be a broken record). I suspect we will have magnifier-only users as well as magnifier plus speech and/or braille. When we get a better understanding of that, we should then work with users to determine where the best place(s) for magnification configuration/control should be. It very well may be that Orca should configure/control it all, but I'd still like to discuss the various alternatives. If we end up going down the path of Orca configuring/controlling it all, we should also consider what to do in other spaces (dyslexia, learning disabled, etc.) and where those things should live. Do we want separate assistive technologies for them? Do we want Orca to turn into a manager of assistive technology plug ins? Etc. > I think that we must things simple and > only engineering a complex solution with lots of options with concrete > use cases that can't be addressed by the current API. Ha - given the various user requirements I've seen to date, the complexity will be there. It just depends where the complexity lives and whether or not it makes sense to spread it across processes. > If there is no one oppositing to implement gnome-mag API inside > metacity I will start this work without further discussions (I think > that I was the only one against it in the past :-) starting with the > actual gnome-mag API, since this is the basic that we need, than we > can start to think how these interaction can be done, since they must > be carried on by the WCM. For the path of least resistance, least disruption, and least design by committee, supporting gnome-mag (as it exists today using Bonobo/CORBA) in metacity might be the easiest thing to do. We could then continue focusing on the current approach where Orca drives gnome-mag and provides the UI to it. If the plan is to ditch Bonobo/CORBA and basically rewrite the IPC mechanism to gnome-mag, however, I think we should take pause and rethink the approach to the magnification. BTW, I'm not sure the concern about metacity rejecting Bonobo/CORBA is truly valid. Because Metacity is an application that must be accessible by Orca, it already participates in the AT-SPI and bears the Bonobo/CORBA requirement for communicating via the AT-SPI. > > Are you coming to GNOME Boston 2007? Magnification is one of the > > critical things we want to talk about for the accessibility summit. > > Ow... it would be a dream :-), but I don't have passport and don't > have money, so no :-(, but I really like to know what become > discussed. Bummer. This discussion, however, will be of great use for the summit and we should continue having it. Thanks! Will _______________________________________________ Gnome-accessibility-devel mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
