| Summary: | [kopete] now listen plugin works poorly | ||
|---|---|---|---|
| Product: | TDE | Reporter: | Slávek Banko <slavek.banko> |
| Component: | tdenetwork | Assignee: | Timothy Pearson <kb9vqf> |
| Status: | RESOLVED FIXED | ||
| Severity: | minor | CC: | bugwatch, slavek.banko |
| Priority: | P5 | ||
| Version: | 3.5.13 [Trinity] | ||
| Hardware: | All | ||
| OS: | All | ||
| Compiler Version: | TDE Version String: | ||
| Application Version: | Application Name: | ||
| Attachments: | Fix of cooperation now listen plugin with the media applications | ||
TQSTRING_OBJECT_NAME_STRING is *supposed* to be set to "TQString" by tqtinterface. Therefore, this needs to be debugged at that level. From what I can tell the object types set in tqt.h are correct, at least in GIT. Did you compile TDE against TQt3 or Qt3 when you ran into this problem? (Odpověď na komentář #2)
> From what I can tell the object types set in tqt.h are correct, at least in
> GIT. Did you compile TDE against TQt3 or Qt3 when you ran into this problem?
I deal with 3.5.13, so is compiled with Qt3. In this case is TQSTRING_OBJECT_NAME_STRING defined as QString. But the programs send their answers as TQString. Therefore, I propose a patch, with which will be accepted to both. It would probably be better if I instead TQSTRING_OBJECT_NAME_STRING gave directly QString.
When compiled against Qt3 TDE should be using QString, not TQString, for its DCOP return values. I wonder where this is defined and why it is happening. (Odpověď na komentář #4)
> When compiled against Qt3 TDE should be using QString, not TQString, for its
> DCOP return values. I wonder where this is defined and why it is happening.
I just noticed that it happens :). Therefore, it seemed to me useful to expect both. Even with regard to it, that the user can combine programs with Tqt3 and with Qt3. tqtinterface in 3.5.13.1 is (yet) unchanged, so it is possible that it's somewhere in it. The nightly-builds I've not tested.
This problem should be fixed in GIT hashes c06a639 and 2366375. If not, please reopen this report, as other applications may need to be modified to use the correct DCOP types as well. Improved Kaffeine support pushed in GIT as hash f6708531. (In reply to comment #7) > Improved Kaffeine support pushed in GIT as hash f6708531. You removed the "replyType == "TQString"" checks before pushing that, correct? (Odpověď na komentář #8)
> (In reply to comment #7)
> > Improved Kaffeine support pushed in GIT as hash f6708531.
>
> You removed the "replyType == "TQString"" checks before pushing that, correct?
Of course :)
But it is still necessary to correct Kopete::Message::RichText.
For messages sent via /media (slotMediaCommand) is already fixed. For messages sent through the menu (advertiseToChat) this can be also easily fixed - change the format to Kopete::Message::Plaintext.
But adding text to the sent message is completely broken. originalBody is readed by msg.plainBody, then added '<br>', then is added advert and finally sent as RichText. Not only does it possible break formatting of the original report, but added advert is plain (which may contain for example &).
(Odpověď na komentář #6)
> This problem should be fixed in GIT hashes c06a639 and 2366375. If not, please
> reopen this report, as other applications may need to be modified to use the
> correct DCOP types as well.
I tried to incorporate c06a639 and 2366375 into v3.5.13.1. I recompile tqtinterface, kdelibs, kdebase, amarok, and the result is not good. KWin does not start during login. In. Xsession-errors I see:
WARNING: DCOPReply <TQStringList>: cast to 'QStringList' error
When i run it manually from the console, so it works.
In any case - in kdcop I still see the types of returned values as TQString. So I'll solve it by this way: specifically for the 3.5.13.1 I'll incorporate "ugly" patch with both - TQString and QString. And "correct" solution will be done in R14.
Can it be?
Reopening as there seems to be some loose ends with twin and kdcop. However, as TDE builds and operates correctly under the preferred TQt3 I am bumping the importance down to minor. Because the issue is for v3.5.13-sru branch treated, and in R14 branch is resolved, I'm closing this bug report. |
Created attachment 616 [details] Fix of cooperation now listen plugin with the media applications I like to listen to music and I sometimes share information about what I am listening. In Kopete I use /media. In 3.5.12 but mistakenly cooperates with Kaffeine (with Amarok works). In 3.5.13 it does not work with anything. I found that the problem is in condition that test DCOP response type. Expected is QString (TQSTRING_OBJECT_NAME_STRING), but gets TQString. Therefore, I modified the condition to accept not only QString, but also TQString. I'm just not sure if this is the right solution? But it works :) I also improved support for Kaffeine.