Hi Tomas, > 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.
Fair enough. This wasn't really a hanging point for me. In fact, your whole "rant" never contradicted a single point of mine and mostly just let out your frustrations. Sounded like you needed it. I do realize that the BiDi build is probably not getting stress-tested enough for *any* of our likings, mine included. But whether we should make our users be those stress testers is an entirely different matter. For the record, I would *not* be opposed to making BiDi the default build in DEBUG builds only. That way, you'll potentially get more feedback from people like Hub, Martin, and myself, and this could definitely be useful. The reason I say "potentially" here is that: 1) I don't ever do BiDi work, so my tests will be even more of a "toy" level than yours are 2) I probably wouldn't know what to look for even if I was able to test So basically, even if this was on by default, all I could report is that my toy test-suite worked and it didn't fsck up anything in my normal mono-di writing mode. I imaging that this is the same for Hub and Martin, though I may be wrong. So even if we turn this on by default in DEBUG builds, we're still not gaining much (if anything) in terms of bug reports and usability info for you. Those who download CVS and play with BiDi will continue to do so. Those who don't probably don't know what to look for, and therefore are of little use to you. We all have our reasons for working on the projects that we do. I started working on wv because I was just recently in college and needed to read/print MSWord documents. wv saved my ass quite a few times when I had to read/print a DOC and I was staring at a Solaris box in my computer lab... wv->Netscape->lpr did the trick. I also was a literature and germanic lit/language minor and had to write a huge amount of papers over the last 4 years, starting with ~Abi 0.5.3. I've honestly probably logged more hours typing into AbiWord as a user than anyone on the planet. But none of this is really important. We all contribute in ways that make us happy. In the end, even our most selfless acts are selfish. I'd love to help make the BiDi team larger, but I don't see how this suggestion will accomplish that. > 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. I'm all for this, and I see Jesper's document yesterday as part of a much larger plan. I have set up a paypal.com account, and will set up a kagi account shortly. I'm trying to set up a revenue model for AbiWord based on an aggragation of small sums from users + contractural work from more serious individuals. While abiword is free, some people might like to give us $5 or something for our work, just as a donation. Others might want to contact a developer directly and contract work to fix a bug or implement a new feature. I've done the latter, and it's quite rewarding, since I got paid and we got some cool new features. Others might like to contribute by code, bug reports, and just general help like web site maintanance. This is all welcomed as well, and will go into my forthcoming "how to contribute to abiword" document. I have not worked out how we might distribute funds from the "general $5 donation" pot. Contractural work is cut&dry - the money goes to the developer who did the work. Suggestions are welcomed. To wrap up, I'm not sure how we can get more people to test the BiDi build for you between release cycles, and making it the default probably won't accomplish this. Dom
