Re: gnome-terminal awfully slow

["Jeff Waugh" <jdub perkypants org>]

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

It specifically mentioned on all of the proposed module lists, and the
final modules list that vte would replace zvt:
  "vte: Terminal widget with improved font and internationalisation
  support. Designed to replace libzvt."
Again, I'm not entirely sure how we could have made this clearer, earlier.
(In fact, you did reply to one of the earlier announcements that
mistakenly pimped vte's superior a11y support.)
> Jeff: in that case we should abandon mention of a11y as a feature.

An inane logical extreme does not help your case.

> 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!

A component that was not maintained, largely deemed to be unmaintainable,
and had serious issues with i18n (which happens to make up a larger
portion of our user and, importantly, developer base than a11y).
> 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 objections.

So, whilst the docs, i18n and usability teams are fully capable of
tracking d-d-l and gnome-announce, for some reason we must go out of our
way to make sure that the a11y project is kept 100% up to date on
everything? I'm sorry, but that's a ridiculous expectation. Everyone in
this community tends to work, lobby for and concentrate on their own areas
of interest, and if they're not sufficiently motivated to work with the
rest of the project, they may not get what they want.
Everyone has a grand scheme ("GNOME") and their niche (be it
project-oriented, particular modules, whatever). a11y does not get special
treatment.
> 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.

In my head, I'm adding up what you're saying here, and your
involvement/input over the course of the 2.2 release process. It ends up
roughly sounding like "I didn't make an effort to get what I wanted
previously, and now I'm stuck with something I don't want, and it's your
fault". There was a very long period of time during the 2.2 process for
you to say either "no, this is unworkable" or "okay, as long as I can make
these changes". You didn't, and the community moved on. We can't take
responsibility for this stuff, *you* need to do so by helping us out.
Otherwise, *you* will be dissatisfied.
> yes, I know zvt was broken in many ways; why is accessibility
> brokenness less important?

In the grand scheme of things, the i18n and maintainability issues won out
- if you're not happy with that now, consider your involvement and help to
rectify the a11y issues during the 2.2 process.
> 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.

Both of these comments are going to sound trite, but they're 100% on the
money when it comes to working within the community:
  a) GNOME helps those who help themselves
  b) help us help you

It's really tiring being flamed for decisions long after the horse has
well and truly bolted.
- Jeff