On 9/24/06, Joachim Staib <[EMAIL PROTECTED]> wrote:
I think it would be the best solution to have the licq backend do the work again. Plugins should deliver all information in UTF-8 or something like that to the backend and it will do an intelligent character set conversations (or if a preferred encoding is set for the specific user it will use this encoding). This would require some more building alterations but would finally make encoding work the way it should - reliable and independent from GUI plugins. I'd like to start with such a work in the backend if this doesn't interfere with some plans you have :)
I use the console plugin. I have many friends in China, and they use a mix of Unicode, BIG5 and GB encodings. At the moment, Licq with the console plugin doesn't handle this gracefully at all. I would be interested in working on suitable changes for the console plugin. One thing which I've already done is I've modified my version of the console plugin so it's linked against cursesw (the wide char version) not curses. This paves the way for making changes so that the plugin can handle Unicode to and from the backend properly. Unfortunately I had to drop out the CDK library, which is unsupported and not available in a wide char version. Since the CDK library is only used for the scrolling of the contact list and a context menu for each contact, I rolled back to the last non-CDK version of the code for the contact list. I'm tempted to make my changes so that configure looks for CDK, and if it's available, compiles in CDK, otherwise it compiles things as I do. Any thoughts? Mitch.
