Alexandre Julliard wrote:
Shachar Shemesh wine-devel@sun.consumer.org.il writes:
If the general public here votes to remove the ac related code, I'll go along with it (no question about it making my code simpler, albeit marginally).
I suggest you write the real code first, and let us worry about the configure stuff later. There is no point in adding configure dependencies for non-existing code, and once the code is done we can have a better idea of what dependencies you actually need.
I have the creeping suspicion you don't realize just how much of a shortcut using fribidi is. All of the stuff we have there already that says "exteremely preliminary" is going to be replaced with approximately four to five lines of code.
Then again, since you will probably only have time to look at it on Monday, and since "the rest of the code" is hopefully going to be ready by then, let's just postpone the discussion a bit :-)
As mentioned already, I think including the fribidi algorithms directly in the code is a better approach, but the only way to really say which is the right way is to get something working.
I talked to Behdad (one of the libfribidi maintainers) about this some time ago. Basically, the Unicode BiDirectional code is fully Unicode 3.2 complient, and no changes are expected there (assuming Unicode don't change the algorithm itself again, like they did between 3.0 and 3.2, 2.1 and 3.0, 2.0 and 2.1, and that's just the versions I have on record. Everything before 2.0 is a total blank to me).
The thing that is not yet complete, and which I have neither the resources nor the knowledge to handle, is the glyphing support (read - Arabic). Since it is interesting to me to have the working (but not interesting enough to try and dust off my extremely rusty Arabic), and since no Arabic speaking programmer vulonteered to step up to the task on either this list, the Israel Linux mailing list, or the Ivrix mailing list (where libfribidi was originally brewed), and since the only Arabic representative who did contact me disappeared with no trace after two emails, if we don't use an external library for this, we won't have any support for this at all.
At the moment, I think it is particularily counter-useful to have mandatory BiDi support in Wine, as this means (among mere applying the BiDi algorithm) translating each string printed to UTF-32 and back (unless we can say for sure that no BiDi is going to be required - havn't found a really good algorithm for that yet, but I'm working on it). Not having the proper library on your machine is a pretty good way of indicating that BiDi is not interesting to you (and is, more or less, the way MS tackled the exact same dillema).
The only thing that can cause me to change my mind about this is if porting libfribidi to UTF-16 will, indeed, be as easy as Behdad suggested. Personally, I have my doubts where sarrogates are used in right-to-left context (hi-lo order may get reveresed, and the characters hopelessly mangled). If, however, we can invest minimal effort and get a UTF-16 fork of libfribidi, I will see no sense in non-Wine distribution of this fork. Please understand, however, that this is a fork, and it will need to remain synchronized with the main branch.
Personally, I think my time would be better spent trying to get the edit control to work BiDi (a problem not solved in mozilla, for example), hunt down why DrawText doesn't always use the correct charset, add the charset selection to the "ChooseFont" dialog, make sure that switching keyboards send out the WM_KEYCHANGE message, or any other of the endless list of tasks still waiting to be done before we can truely say that Wine supports BiDi. There is still a long long way to go, and this is really just the begining.
Shachar