Re: [g-a-devel]gnopernicus robustness and a11y tools in the GNOME2.2 release

On Wed, 2002-08-28 at 17:43, Luis Villa wrote:
> On Wed, 2002-08-28 at 04:40, Michael Meeks wrote:
> > 	Yep - you need both gnopernicus and gnome-speech; try running the
> > driver by itself though - it seems to be the only way to get debug how
> > gnopernicus is failing. It'd be _really_ good if someone had the time to
> > file several bugs against gnopernicus' robustness, and it not warning
> > sensibly when things fail - both on the console and on-screen [ frankly
> > the amount of debug spew at startup is quite amazing and unneccessary as
> > well - which makes it hard to see any errors ].
> Is gnopernicus at the point where filing bugs in bugzilla will be
> useful? If so... 

Yes, please log plenty of bugs, so they can be tracked down, etc... I
think it's time.

> I built it out of CVS yesterday and couldn't get
> anything to work, and I'd be happy to track down and file specific
> issues wrt warnings, failures, and such. It may just be a
> documentation/usability problem, to be honest- I have no idea if my
> gnome-speech is set up correctly, for example, and no idea how to test
> that. Ditto for gnome-mag- it built and did 'make install' fine, but I
> have no idea if it actually works/is installed correctly. 
> FWIW, gok built and ran well. It's pretty nifty, especially the word
> prediction stuff. It doesn't at all look and feel like a GNOME app,
> though :/

It *can't*, it's an onscreen virtual keyboard ;-)

(see below)

> Which brings me to explaining why I was building all of this stuff. The
> release team feels it would help the visibility of the a11y team a great
> deal if gok and gnopernicus were included in the GNOME2.2 release. As it
> currently stands, there is little-to-no visibility for a11y amongst
> either the average user community or the hacker community, and we feel
> that including tools for a11y in our standard distribution would help
> alleviate that problem. So... we'd like to include gok and gnopernicus
> (and any other related GNOME-based a11y applications) in the GNOME 2.2
> Desktop- it would be good for the a11y effort and it would be good for
> GNOME. There would suddenly be thousands of people (even hundreds of
> thousands, once the main distributions pick up the Desktop release) who
> have these tools available and working, and we think that can't help but
> raise interest and awareness.

Yes, I think this would be a fantastic thing.  Certainly without
client-side programs like gnopernicus and GOK, the accessibility
framework won't get the needed exercise and attention, and of course it
won't do anything for end-users until assistive technologies are
available.  Bundling them would also be a great step towards "universal
access" for GNOME.

> But... that will require a lot of work.
> Among other things[1]:
> *neither project, to the best of my knowledge, has done an actual
> release yet. To be included in the Desktop release there must be tarball
> releases on a fairly regular basis, so that people can build and test
> the programs.[2] There also has to be a committment to UI and feature
> freezes in the stable branch- which may or may not be acceptable.

I think it's too soon to freeze UI or strings in these projects. 
Perhaps something can be done for STABLE in the 2.2 timeframe, I don't

If not 2.2, then 2.4, but I'd like to hear the GOK and Gnopernicus
teams' feedback on UI freeze in the 2.2 timeframe, at least on a branch.

> *gok uses bugzilla, it appears, but gnopernicus does not (as far as I
> can see.) Responsiveness to quality issues raised in bugzilla is
> important to reaching the quality goals we expect of GNOME releases.
> *Neither application /looks/ like a GNOME app. Obviously, because they
> are intended primarily for a different audience than the typical GNOME
> user, a certain amount of deviation from the GNOME look and feel is
> probably acceptable and possibly even very necessary. But we do intend
> to look like an integrated desktop, and so minimal steps that shouldn't
> interfere with a11y (like using GNOME toolbars, using standard spacing,
> and having help and close buttons when appropriate) should be
> considered. [GOK, for example, should probably look at the very minimal
> toolbar that gnome-calculator has.]

The GOK "onscreen keyboard" windows are a special case; it doesn't make
sense for these to have ordinary toolbars, etc.  It's debatable whether
they should even have decorations.  However the GOK "Settings" dialog
clearly should follow GNOME conventions.

As for gnopernicus, it does use gtk+ and GNOME, but again it's
questionable as to whether it should follow all the UI conventions since
it is actually a sort of meta-app.  Again I think it makes sense for
things like settings dialogs, etc. to pay attention to GNOME conventions
> *the application must be robust. We can't ship something that will only
> work for some people and only after much work has gone in. As far as I
> can tell, that's the current state of Gnopernicus. If I (or others)
> identify problems for a more 'average' user, will gnopernicus get fixed
> and made robust? Or is the focus still on core functionality without
> much thought/time being given to those types of issues? [If so, then
> Gnopernicus might be more appropriate for GNOME 2.4.]
> At any rate, I know these sound like fairly onerous responsibilities,
> but the release team feels that there would be a lot of benefits for
> a11y in GNOME if these issues are dealt with in the 2.2 time frame, so
> we hope that the gok and gnopernicus devels (as well as the rest of the
> a11y team) will think hard about trying to fulfill them.
> We're of course happy to answer any questions you may have about these
> requirements, as well as what we feel the benefits to you will be.
> Please let us know as soon as you can, of course, about whether or not
> you intend to try to become part of the official GNOME 2.2 Desktop
> release.
> Luis
> P.S. It is worth noting that saying 'yes, we'll try but we can't
> guarantee anything' is a perfectly worthwhile answer. We can get you
> into the early betas, get some widespread testing and feedback, and if
> at that point everyone agrees it is just not going to work out in this
> timeframe, we can always back things out and re-focus on the 2.4
> release. 
> [1] a complete generic list can be found here:
> [2]As detailed in the schedule:
> _______________________________________________
> Gnome-accessibility-devel mailing list
> Gnome-accessibility-devel gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]