No text with Google Talk

[Sayak Banerjee]

Binary package hint: wine

Google talk does not display text with wine.

[Mattfinn (mattfinn)]

Created an attachment (id=2374)
Full log as google talk runs.

[Mattfinn (mattfinn)]

Google Talk also outputs these two riched fixmes:

fixme:richedit:RichEditANSIWndProc WM_SETFONT: stub
fixme:richedit:RichEditANSIWndProc EM_SHOWSCROLLBAR: stub

[konqy (fasici)]

Created an attachment (id=2498)
A log file produced from a recent version of google talk

Also fonts in GUI do not appear. I don't have this problem with the older
versions (The ones with the nsis installers).

[Gabriel Mazetto (brodock)]

i confirm the same with wine 0.9.24

...
fixme:richedit:fnTextSrv_TxSendMessage 0x1212c88: STUB
fixme:richedit:fnTextSrv_TxSetText 0x1212c88: STUB
fixme:richedit:fnTextSrv_TxSendMessage 0x1212c88: STUB
fixme:richedit:fnTextSrv_TxSetText 0x1212c88: STUB
fixme:richedit:fnTextSrv_TxDraw 0x1212c88: STUB
fixme:shell:SHAppBarMessage ABM_REMOVE broken

[Lei Zhang (thestig-google)]

added url to google talk.
problem exists in wine cvs as well.

[Jaime Rave (jaimerave)]

some of these features are afecting MSN Messenger too.

http://bugs.winehq.org/show_bug.cgi?id=10073

[Jaime Rave (jaimerave)]

Can anyone review this and see if this can help with this bug. Thanks

http://www.winehq.org/pipermail/wine-patches/2006-February/023911.html

[scguy318 (nodisgod)]

Patch fails to apply with current Git.

[Jaime Rave (jaimerave)]

Off course it will fail, is a patch from 2 years ago, I just want that some developer see if there something useful on it.

[Austin Lund (austin-lund)]

Created an attachment (id=12863)
Updated patch which applies to 1.0-rc1

[Austin Lund (austin-lund)]

Created an attachment (id=12864)
Output with updated patch applied.

I've uploaded a modified patch which applies against 1.0-rc1. Attached also is the output. Seems only to be a small incremental step.

[Austin Lund (austin-lund)]

I changed the SendMessage implementation to:

HRESULT WINAPI fnTextSrv_TxSendMessage(ITextServices *iface,
                                       UINT msg,
                                       WPARAM wparam,
                                       LPARAM lparam,
                                       LRESULT* plresult)
{
   ICOM_THIS_MULTI(ITextServicesImpl, lpVtbl, iface);

   switch(msg) {
   default:
     FIXME("%p: (%s) STUB\n", This, get_msg_name(msg));
     return E_NOTIMPL;
   }

}

This way I can see what are the common messages that it sends.

Typical output looks like:

fixme:richedit:fnTextSrv_TxSendMessage 0x1c570f8: (EM_SETCHARFORMAT) STUB
fixme:richedit:fnTextSrv_TxSetText 0x1c570f8: partial stub (L"")
fixme:richedit:fnTextSrv_TxSendMessage 0x1c570f8: (EM_SETPARAFORMAT) STUB
fixme:richedit:fnTextSrv_TxSetText 0x1c570f8: partial stub (L"Sign in")
fixme:richedit:fnTextSrv_TxGetNaturalSize 0x1c570f8: STUB
fixme:richedit:fnTextSrv_TxSendMessage 0x1c570f8: (EM_SETCHARFORMAT) STUB
fixme:richedit:fnTextSrv_TxSetText 0x1c570f8: partial stub (L"")
fixme:richedit:fnTextSrv_TxSendMessage 0x1c570f8: (EM_SETPARAFORMAT) STUB
fixme:richedit:fnTextSrv_TxSetText 0x1c570f8: partial stub (L"Sign in")
fixme:richedit:fnTextSrv_TxGetNaturalSize 0x1c570f8: STUB
fixme:richedit:fnTextSrv_TxSendMessage 0x1c570f8: (EM_SETCHARFORMAT) STUB
fixme:richedit:fnTextSrv_TxSetText 0x1c570f8: partial stub (L"")
fixme:richedit:fnTextSrv_TxSendMessage 0x1c570f8: (EM_SETPARAFORMAT) STUB
fixme:richedit:fnTextSrv_TxSetText 0x1c570f8: partial stub (L"Offline")
fixme:richedit:fnTextSrv_TxGetNaturalSize 0x1c570f8: STUB
fixme:richedit:fnTextSrv_TxSendMessage 0x1c570f8: (EM_SETCHARFORMAT) STUB

So it seems the set CHAR and PARA format are the high priorities. But that's probably good as these just pass the format structures on to the associated ITextHost implementation that the application implements as far as I can tell.

[Austin Lund (austin-lund)]

Created an attachment (id=14128)
Adds ITextServices tests

This patch tests all the features which this application needs for minimal functionality.

It was submitted to the patches archive:

http://www.winehq.org/pipermail/wine-patches/2008-June/055755.html

The trickiest function to figure out is the TxGetNaturalSize one. That is where most of the work for this will be. Not that it is hard to measure the size of a text string, but the units it uses and how the mapping mode affects it seem to be critical.

[Austin Lund (austin-lund)]

Created an attachment (id=14330)
Adds unformatted text.

This patch adds very simple code to output text with TxDraw and measure it's size using TxGetNaturalSize.

This is sufficient to get a bare bones working version of Google Talk.

Setting the default character formatting still needs to be done and I'm working on that now.

It is a long way from actually rendering richtext, but at least you can see something when loading google talk.

I've combined the old patch (which defines a variable where the current text is stored) into this patch. They need to be together.

The patch applies to git at commit dd01d39f3b8.

[Austin Lund (austin-lund)]

I'm trying to get the tests into git.

The tests are fairly long and complex so I've broken it up into a patch series.

Can people who are interested help me test this.

The first patch is here:

http://www.winehq.org/pipermail/wine-devel/2008-June/066811.html

I think I also have a strategy for proper implementation.

[Sayak Banerjee (sayakb-deactivatedaccount)]

Binary package hint: wine

Google talk does not display text with wine.

[Sayak Banerjee (sayakb-deactivatedaccount)]

Tested with Wine 0.9.59

[Vojtěch Trefný (vojtech.trefny)]

It seems to be 'normal' behaviour -- http://appdb.winehq.org/objectManager.php?sClass=version&iId=7458 -- not all windows applications are compatible with Wine...

GTalk is 'normal' jabber (XMPP) protocol, so you can use some IM client that supports Jabber (Pidgin, Gajim, Kopete, Psi...) to comunicate via GTalk...

[Scott Ritchie (scottritchie)]

Upstream bug linked

[Ben McCann (benjamin-j-mccann)]

An override of riched20 will work around this problem.

[Mattfinn (mattfinn)]

Just realized this bug is still assigned to me. I'm unable to work on it any further for legal reasons, so I'm reassigning it to the default assignee (hopefully the right choice, never done it before).

[Dylan Thacker-Smith (dylan-smith)]

I have been interested in working on it, but haven't gotten around to it yet. When I do start coding, I would like to not interfere with work in progress by others. So, let me know where you are at if you are working on it.

Austin Lund, you mentioned that you have an idea for a proper implementation. I was wondering what direction you were taking.

I will also share my thoughts on the implementation of windowless richedit controls. The main goal being to use as much existing richedit code to implement text services while minimizing the impact on using richedit as a control.

These are the steps I think we need to take:
1. Create a ITextHost implementation for the richedit control.

1.5? This ITextHost implementation could be manually tested against native richedit's text services to try to implement a richedit control.

2. Modify the richedit code to use the ITextHost implementation from step 1, removing it's dependance on having it's own window. This could be done incrementally, and could be tested for regressions using the existing richedit test suite.

3. Implement the ITextServices interface by using the existing richedit code, and swapping the ITextHost implementation created in step 1 with the ITextHost implementation given by the parent window (provided in the call to CreateTextServices).

Comments on this approach are more than welcome.

[Austin Lund (austin-lund)]

My thoughts on how to do it were more of a hack than a proper implementation. I would not recommend it as a sustainable solution.

The proper way to do it I think is as outlined. However, this is not very low hanging fruit and will require a lot of work. There are a lot of interdependencies and I thought an incremental approach would not work, but I'm happy if I'm wrong.

Note that I tried to get tests included. The biggest issue here is not the tests, it is that the ITextServices and ITextHost assume the use of the thiscall calling convention, even in C (!!). Check the patches sent by me to wine-patches earlier this year on how I thought it might be done. However, the goalposts kept moving on me and then I ran out of holiday time :(.

I was able to make a trivial ITextHost implementation. Again, written with hack like purposes in mind.

If someone could get unittests in (even if it only contains a test of one call) that cover the thiscall stuff then this would be good and a full test suite could be written and things can move forward fairly rapidly. This first step probably requires quite a bit of thinking but not much code.

[Dylan Thacker-Smith (dylan-smith)]

*** Bug 8596 has been marked as a duplicate of this bug. ***

[Dylan Thacker-Smith (dylan-smith)]

(In reply to comment #19)
> If someone could get unittests in (even if it only contains a test of one call)
> that cover the thiscall stuff then this would be good and a full test suite
> could be written and things can move forward fairly rapidly. This first step
> probably requires quite a bit of thinking but not much code.
>

It wasn't easy, as you mentioned, but I got an the initial tests in for windowless richedit controls, so all the thicall stuff has been handled for the tests. Now all you need to do is use the traditional c macros for calling the c++ methods.

Thanks for all the work you and Maarten Lankhorst did in starting the tests, and Alexandre Julliard also helped in letting me know what still needed to be done, and he even cleaned up my final patches on commit.

Now I can start working on the defining an ITextHost for the richedit control, which will require macros these thiscall methods from the richedit code. This time wine/port.h can be used since it won't be in the tests.

[Dan Kegel (dank)]

Wow, it's great to see progress being made here!

[Dylan Thacker-Smith (dylan-smith)]

I am assigning myself to this bug because I have started implementing windowless richedit controls according to my proposed steps I already mentioned.

I have an initial implementation of ITextHost, and now I need to replace references to editor->hWnd with calls to ITextHost_Tx*. I replaced a couple GetDC calls and made sure it compiled and run without problems, so the calling calling convention wrappers seem to be working. It won't be until I can completely get rid of the ME_TextEditor.hWnd variable that I will be able to move on to implementing ITextServices.

In the mean time, if someone wants to help me, adding TextServices tests would be very helpful.

[Arindam (arindam)]

This is an existing bug and implementations going on. Furthur details: http://bugs.winehq.org/show_bug.cgi?id=5162

[Austin English (austinenglish)]

*** Bug 11941 has been marked as a duplicate of this bug. ***

[Dan Kegel (dank)]

*** Bug 10896 has been marked as a duplicate of this bug. ***

[Austin Lund (austin-lund)]

There seems to be good progress being made here.

The only fixmes I get now from richedit are about TxDraw and TxGetNaturalSize.

From my playing around months ago, not implementing TxGetNaturalSize but having a simple TxDraw implementation (I just made it draw the raw strings out) gives an almost workable interface, through things don't quite line up.

Also, there seems to be good progress on the not connecting issue.

I guess what I'm suggesting is that a semi-working TxDraw implementation would be good. Is it possible to work in the editor painting functions to make a semi functional implementation of this function?

[Dylan Thacker-Smith (dylan-smith)]

Created an attachment (id=19248)
Quick and dirty drawing patch

(In reply to comment #26)
> There seems to be good progress being made here.
>
> The only fixmes I get now from richedit are about TxDraw and TxGetNaturalSize.
>
> From my playing around months ago, not implementing TxGetNaturalSize but having
> a simple TxDraw implementation (I just made it draw the raw strings out) gives
> an almost workable interface, through things don't quite line up.
>
> Also, there seems to be good progress on the not connecting issue.
>
> I guess what I'm suggesting is that a semi-working TxDraw implementation would
> be good. Is it possible to work in the editor painting functions to make a
> semi functional implementation of this function?
>

I got the code to the point where the existing richedit code can be used. So now TxDraw can be done using ME_PaintContent, and the width and the height of the editor can be calculated during wrapping. Nevertheless, the TxDraw and TxGetNaturalSize methods aren't very straight forward, so lately I haven't had the time to invest in getting them working right for something like google talk.

Austin Lund, if you want to try to get something working using the existing painting functions, then that would be great. I am attaching all the code that I have that isn't submitted, which is a quick and dirty basic implementation of TxDraw and TxGetNaturalSize, certainly nothing good enough to submit to wine-patches, so feel free to not use it at all. At least it shows that the existing richedit code can be used. It gets text drawn in google talk, but some text is being wrapped that shouldn't be.

[Austin Lund (austin-lund)]

I was playing around with the patch. I couldn't seem to nicely add to current git as there have been some changes which make the patch not apply.

Is it possible to rebase it on top of the current git?

[Dylan Thacker-Smith (dylan-smith)]

Created an attachment (id=19667)
Rebased quick and dirty drawing patch

Rebased the patch against the origin as requested

[Austin Lund (austin-lund)]

Created an attachment (id=21533)
Quick and drity txDraw rebased to commit 1643679476

OK. All tests (very crude ones) are now in Alexandre's branch.

I rebased the patch again and it _seems_ to work in a semi usable way. Some of the wrapping isn't quite right, and I get the message:

fixme:richedit:fnTextSrv_TxDraw 0x2f97ba8: Unsupported non-NULL lViewId -1

quite a bit. But on the whole it would be usable if bug 3254 was fixed.

[Dylan Thacker-Smith (dylan-smith)]

*** Bug 23198 has been marked as a duplicate of this bug. ***

[Austin Lund (austin-lund)]

What's the latest on this? I was thinking of having a look at this again. Is there any more code out there?

[Dylan Thacker-Smith (dylan-smith)]

(In reply to comment #32)
> What's the latest on this? I was thinking of having a look at this again. Is
> there any more code out there?

I probably shouldn't be assigned to this bug right now since I haven't been working on it since the last patch attached to this bug.

The EM_FORMATRANGE patch that has been deferred until after the code freeze should help with handling a different target DC, but I don't think Google Talk just uses NULL for the target DC passed to TxDraw.

[rusivi2 (rusivi2-deactivatedaccount)]

Does this occur in newest WINE?

[rusivi2 (rusivi2-deactivatedaccount)]

Thank you for posting this bug.

Does this occur in newest WINE?

[Ilya Konyakhin (ilyakon)]

Google Talk outputs these two riched fixmes:
fixme:richedit:fnTextSrv_TxGetNaturalSize 0x155010: STUB
fixme:richedit:fnTextSrv_TxDraw 0x155010: STUB

wine-1.3.6

[Arethusa26 (arethusa26)]

*** Bug 25096 has been marked as a duplicate of this bug. ***

[Arnaud Bellec (arnaud-bellec)]

Hi,

Is someone still working on this bug ?
If not, I was thinking about adapting Austin's patch and starting from here.

[Fabian Ebner (fox6x6x6)]

Still present in 1.5.28

[Focht (focht)]

Hello folks,

still present, refining summary to target the missing infrastructure and collect all dupes here.

Maybe someone can pick up Austin's work?

$ wine --version
wine-1.7.18-92-gb01fc1a

Regards

[Focht (focht)]

*** Bug 31366 has been marked as a duplicate of this bug. ***

[Focht (focht)]

Hello folks,

ICQ 6.x also needs this (account and password input text invisible).

Download: http://ftp.icq.com/pub/ICQ65/install_icq65.exe

$ sha1sum install_icq65.exe
dd04cc61ef2398feafa6d32fd0fe18bc648a082b install_icq65.exe

$ du -sh install_icq65.exe
17M install_icq65.exe

$ wine --version
wine-1.7.18-93-g6d613c3

Regards

[Jactry Zeng (jactry)]

(In reply to Anastasius Focht from comment #39)
> Hello folks,
>
> still present, refining summary to target the missing infrastructure and
> collect all dupes here.
>
> Maybe someone can pick up Austin's work?
>
> $ wine --version
> wine-1.7.18-92-gb01fc1a
>
> Regards

Hi Anastasius,

Bug 34590 may also a duplicate of this bug? I am not sure.

[Focht (focht)]

*** Bug 34590 has been marked as a duplicate of this bug. ***

[Jactry Zeng (jactry)]

*** Bug 38079 has been marked as a duplicate of this bug. ***

[Jactry Zeng (jactry)]

*** Bug 38038 has been marked as a duplicate of this bug. ***

[Jactry Zeng (jactry)]

*** Bug 39383 has been marked as a duplicate of this bug. ***

[Jactry Zeng (jactry)]

*** Bug 38081 has been marked as a duplicate of this bug. ***

[Jactry Zeng (jactry)]

*** Bug 44366 has been marked as a duplicate of this bug. ***

[Xerox-xerox2000x (xerox-xerox2000x)]

Created attachment 63901
rebased the patch from Dylan from comment 29 against current git

Hi,

I`ve tried to rebase the patch from comment 29 to current git.
I hope I didn`t miss anything (quite lot of chunks failed to apply against current git)

[Xerox-xerox2000x (xerox-xerox2000x)]

*** Bug 46838 has been marked as a duplicate of this bug. ***

[Caryyu-tg (caryyu-tg)]

Any new progress for this bug? WeChat is really important for daily working, thanks...

[Jactry Zeng (jactry)]

Thanks to Huw's work, TxGetNaturalSize and TxDraw now are implemented in Wine 6.5.
It might be worth retesting these applications and file separate bugs for their following issue.

[Huw-davies (huw-davies)]

Marking resolved.

[Alexandre Julliard (julliard)]

Closing bugs fixed in 6.6.