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
