Re: gnome-terminal awfully slow
- From: Bill Haneman <bill haneman sun com>
- To: James Henstridge <james daa com au>
- Cc: Jeff Waugh <jdub perkypants org>, Havoc Pennington <hp redhat com>, Hidetoshi Tajima <hidetoshi tajima sun com>, desktop-devel-list gnome org, marney beard sun com
- Subject: Re: gnome-terminal awfully slow
- Date: 13 Feb 2003 13:12:43 +0000
On Thu, 2003-02-13 at 12:29, James Henstridge wrote:
> Bill Haneman wrote:
>
> >Jeff: in that case we should abandon mention of a11y as a feature. From
> >an a11y perspective a fully-working accessible terminal is a
> >cornerstone, it would be like shipping gnome-2.2 without
> >internationalization support on the basis that an english-only component
> >had fewer bugs and was better maintained.
> >
> This is an interesting example to bring up given that the libzvt we
> shipped in gnome 2.0 had bad i18n support. So it seems we have moved to
> a terminal widget with much better i18n support (UTF-8, etc), but with
> incomplete accessibility support. The new widget also has a
> maintainable code base _and_ a maintainer which is a plus.
I agree with this. My point is that we want to know that we are
partners in this decision-making process and not just bystanders. . I
think it's likely that if we'd all sat down physically or virtually to
discuss this, we'd have in the end reached the same decision about
zvt/vte. What was lacking was an explicit notice to the accessibility
team when zvt support was actually swapped out for vte support in the
codebase (as opposed to the statements of intent, which were also
important but not quite the same thing). I expect that if I combed the
archives I could find it; what I am requesting is more explicit
notification.
I don't mind admitting that I need some extra help in this regard; the
combined depth and breadth of accessibility issues makes it impossible
to follow all the relevant threads in full detail.
It's not always obvious that GNOME has made the necessary level of
committment to accessibility as a goal; though most folks see the value
in it, the expectation is that it's up to the "accessibility folks" to
make it work. I accept that on a 90/10 basis, and am grateful for the
support which some people have shown and the time that they have
dedicated to helping make it work.
Accessibility isn't just a big feature, it's a new feature; so we have a
hard task to demonstrate our importance, i.e. "if it's not being used,
how can it regress". We cannot solve this bootstrapping problem without
good communication with all GNOME maintainers, the RT, etc.
> Maybe it would be a good idea to give Nalin some pointers on what he
> should do to finish off the a11y support. It would probably be quite
> helpful to know exactly what needs to be done in VTE rather than just
> hearing that it's support is broken over and over again.
I agree, and Nalin has been very cooperative in this regard; the problem
is that the accessibility team was not able to respond in a timely
enough fashion for 2.2. And we have given direct feedback and
suggestions whenever we have encountered issues; but nonetheless testing
VTE accessibility is a highly specialized task.
With regard to 2.next, perhaps I should post a general proposal for
accessibility in 2.4 to the list, so that we can discuss the feasibility
of meeting various goals in the 2.4 timeframe, and decide on which
features/goals to punt, and discuss areas where we need to avoid
regression and areas where we can expect that new work will be required
due to newly introduced widgets, etc. In general I think that avoiding
regression is more important than adding new features, so we may
conclude that some accessibility goals will need to wait for 2.6. This
would however be an unpopular conclusion for many distributors/bundlers
since accessibility is becoming an increasingly sought-after feature
set.
- Bill
> James.
--
Bill Haneman <bill haneman sun com>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]