Subject: Re: bidi status report
From: Tomas Frydrych (tomas@frydrych.uklinux.net)
Date: Wed Dec 12 2001 - 13:07:19 CST
Hi Dom,
I appolgize in advance for this longish rant.
> The overwhelming majority of our users do not need Bidi capabilities and
> it seems unfair to penalize them in terms of memory consumption,
> performance, and potential instability for a feature that they will
> neither need nor use.
>
> The Bidi build has only recieved a fraction of the testing that our
> Mono-di build has, which makes me a weary of making this change so close
> to our 1.0 release. Further, Bidi has not been tested on the
> BeOs or QNX platforms, though this is essentially only an
> argument against enabling Bidi by default on *only* those
> platforms.
That is true about BeOs and QNX, but there should be a few
problems in this respect, my estimate is that 95% of the bidi code
is XP, and virtually all the non-XP code is to do with dialogues, but
that is not the real issue here.
I personnally have no objections to having two separate builds, bidi
and non-bidi in the long term, after 1.0, or for ever. I quite agree that
most users do not need the bidi-stuff, and need not to be penalized
by it; in fact I personally favour the two separate builds precisely for
those reasons, and my request to turn it on by default had a very
pragmatic motivation. My biggest problem is that as things are, the
bidi build does not get used enough, so that the bug - identification -
fix cycle is very slow, because of the identification stage (most
recent bugs required very trivial fixes, and could have been fixed
month's ago, if I was aware of them). I am optimistic about the
stability, but then I use nothing else than the bidi build -- I
understand your apprehension with regards to the 1.0 release time
scale.
Part of the problem here is that the bidi stuff is not an add-on, but a
replacement of some core code in the layout engine, so that it is
not possible to have it on for the default debug build and not for the
default release build, because that would mean the developers
working on a different layout engine than the users. For the same
reason it is not wise to have it on as a default for some platforms
only.
What is really needed is not making the bidi build a default one,
but an enlargement of the bidi development team; on reflection
substitute 'a' for 'an enlargement of the', since team starts at 2. I
enjoy immensly hacking on it, and will keep at it, but it should not
come as a surprise that the direction and priorities which it takes
are then my own, not necessary identical to those of the normal
user in Israel or Maroko. The fact is, and it might come as a shock
to those who thought that people working on free software are
selfless individuals, that I started working on the bidi stuff in AW
not because I felt that people in places like Israel or Maroko should
be able to use AW, but because I personally need and want a bidi-
capable free wordprocessor that runs on Linux and I could not find
any (free is very elusive here, for if any of the people who regularly
contribute to AW were getting paid for it, we could all afford to buy
the latest gold-plated edition of the "The Other Wordprocessor"
every time it comes out, the necessary OS and hardware upgrades
it would require, and it still would be a bargain compared to AW).
The truth is that the overall state of bidi in AW is currently such
that it satisfies my immediate (and rather limited) personal needs,
while there are other areas where AW does not, and I will change
my priorities in working on AW once 1.0 and the feature freeze is
lifted; bidi will have to take second place behind things like
footnotes, which still stand in the way of AW becoming my work
tool rather than just a toy (my wife told me today I was turning into
an ant, and I would not be suprised if my complexion was turning
blue from the late nights and early mornings; the waist line would
come handy though).
Now, even though it is not altruism that drives my work on AW, I do
try to deal with the needs of other bidi users when I can, but there
are serious limits. In particular, many of the features requested
recently, desirable as they might be, require platform-specific code,
and I am only in position to do that for Linux, and non-bidi
Windows. The most annyoing current bug, which is a potential
stopper for the normal Israeli user, only happens on some flavours
of bidi-enabled windows, and the frustrating thing is that I know that
I cannot fix it myself, which at the moment means it will not be
fixed, which in turn means many potential users will not be able to
use AW, which brings us to the start of the viscious cycle.
I think the bottom line of this rant is, that if there are communites
and individuals out there who want or need the bidi development to
progress steadily forward in the month and years to come, then
they will have to chip in. I suppose this is why yesterday's rant by
Jesper struck so much chord with me.
Tomas
This archive was generated by hypermail 2b25 : Wed Dec 12 2001 - 13:08:49 CST