Shachar Shemesh <[EMAIL PROTECTED]> writes: > I may have came across wrong. I am not suggesting we stick to > libfribidi forever, whatever it can do is fine, and what it can't > won't be done. To emphasize this point, you will notice that my patch > does not export any of libfribidi's functions. In retrospect, I think > I'll rename the .c file to "bidi" - will be more apropriate. > > I am saying that it is covering all of our current needs, and thus we > should go for it as it saves us somewhere between a month of work and > half a year (calendaric time, estimates based on assumption that I'm > the only one working on it). If at some future time we come to the > conclusion that libfribidi is not enough, we can either add the > required functionality to it, integrate it into Wine or replace it > altogether. I am hoping that, by that time, interest in wine will be > high enough for more people to be involved.
What I'm saying is that it's not a good idea to start using fribidi, create dependencies and problems for packagers, etc. if we know that it's a wrong design and that we will need to replace it. The truth is that bidi is not really a priority feature (as shown by the number of people interested in making it work), and so it doesn't really matter if it works tomorrow or only in 3 months. What matters is to pick a correct design so that if more people start to care they can build on it, instead of having to throw it away and restart from scratch. -- Alexandre Julliard [EMAIL PROTECTED]
