Re: gnome-terminal awfully slow

On Thu, 2003-02-13 at 11:11, Jeff Waugh wrote:
> <quote who="Bill Haneman">
> > I think this is one instance of an ongoing problem with GNOME, in that
> > consensus is not always reached and the actual end decision (which
> > usually falls to the maintainer) is not, in the end, telegraphed
> > appropriately. i.e. 
> > 
> > objector: "The issues I raised are still open"
> > maintainer: "I told you what I was planning to do, why should I tell you
> > after I've done it"
> > 
> > IMO in the above case (where there are clear open issues), the
> > maintainer should always explicitly let the concerned parties know that
> > the change under discussion has actually taken place.
> In the case of vte for 2.2, it was made absolutely abundantly clear by the
> release team, which modules were "new and included" in the release at the
> feature freeze date, with constant reminders of these modules at every pre-
> release before the feature freeze. I'm not entirely sure how we could have
> made it any more clear what the decision was regarding vte.

Bundled doesn't mean "compiled in default", whenever this was mentioned
I (and others) raised concerns about vte in the 2.2 timeframe.

> > I think that if we are going to say anything publicly about GNOME
> > accessibility (and we have already), we must avoid replacing code that's
> > broken in one way with code that's broken or regressed accessibility-wise.
> > Regression is not generally tolerated in other areas, it should not be
> > tolerated in accessibility either.
> The decision came down to unmaintained code vs. maintained code. If a11y or
> general feature regression (unrelated to a11y) are more important than
> maintained code, colour me inordinately surprised. We cannot be enslaved to
> the needs of a11y at the expense of our ability to maintain and improve our
> software, I'm sorry.

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.

We either do it or we don't IMO.  There will always be tradeoffs when
swapping in replacements - but regressions are regressions, and it's
wrong to swap in an inaccessible component when an admittedly broken but
accessible component has already been shipped in a previous release!

My primary point is that explicit heads-ups about such actions should be
made.  It is simply not true that the accessibility project team (which
I believe has been cited as a core GNOME project) was explicitly given
the heads-up that this switch, compiled=in, was being made over their

If there is disagreement then explicit warning should be given.  And if
accessibility is something that GNOME has any committment to, then there
are certain kinds of regressions that are unacceptable; to that extent I
*do* believe that accessibility, like any desktop feature, must be taken
into account when making these changes.  Regressing accessibility is
explicitly _disimprovement_ of GNOME, it makes no sense to say
"GNOME-2.2 is improved" without taking into account the regressions from
2.0 as well as the bugfixes and enhancements.

You must trust your project teams a little; certainly i18n concerns were
part of the vte transition, my point is that the a11y team should have
similar input which is just as valid.  I am not promoting "accessibility
over all else", but relegating accessibility to "nice to have if those
a11y guys can keep up" is not IMO acceptable.  As I made clear on
several occasions, terminal widget accessibility is:

* a cornerstone of accessibility
* very hard to get right, and
* working in zvt

yes, I know zvt was broken in many ways; why is accessibility brokenness
less important?  The massive task of keeping up with the moving target
that is GNOME, accessibility-wise, falls to only a couple of individuals
at the moment.  We need respect and assistance from the rest of the
GNOME community in order to provide meaningful accessibility to our
users and avoid embarassing and tragic failure in this arena.

- a discouraged Bill

> - Jeff
Bill Haneman <bill haneman sun com>

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