Hi Eugene, First of all, if I would add an option for a default encoding I would definitely add it to the osd config file and not parse the qt-gui file, as plugins should never know each other.
But even if i had a default encoding, I am not sure if this would solve the problem: I get a message from a user and dont know which encoding he uses. On the other hand, I know of course our own encoding, as it is set in LANG/LC_CTYPE. I dont think that it would be correct to assume the message is already in default encoding and do a conversion like default (as in config file) --> local encoding (as in LANG) Without the information about the encoding of the other user I most likely wont have the possibility to do a correct character set translation. Am I wrong here ? Did I miss something ? greetings Martin On Thursday, 12. October 2006 06:16, you wrote: > On Tue, 10 Oct 2006 19:21:05 +0300, Martin Maurer <[EMAIL PROTECTED]> > > wrote: > > sending directly, as attaching files at mails to the mailing list might > > not > > make people happy. > > > > please examine the problem using the attached licq-osd.cpp. > > Enable all debug output and check the network window. > > > > If you get an empty userencoding and the message "no translation needs > > to be > > done", then I can't do anything in the osd plugin to solve the problem. > > I need 2 encodings to do iconv translation (source, destination), where > > I have > > only 1 (destination=your local encoding). > > In my experiments this case happened. > > Let me share my imagination of how it could be done. > > qt-gui is a representation plugin. It retains its default encoding within > its configuration file. > Same goes for osd plugin, thus I see no strong objection to keep separate > default encoding for osd. Moreover, such kind of parameter is set once and > is unlikely to be changed often. > > Or you can make qt-gui file parsing for a default encoding, but this is a > bit worse, since someone might not be using qt-gui at all, so they have it > unconfigured. > > Frankly, I wonder why all this encoding stuff is not handled within the > licq core, but is relayed to plugins... > > Please let me know if you are still interested in making experiments with > your source, I will perform them as soon as I receive your reply.
pgp6MPVWPp2CC.pgp
Description: PGP signature
