Improve automatic reporting of incoming messages in Miranda NG

[codeofdusk]

Link to issue number:

Fixes #640, #1471.

Summary of the issue:

In Miranda NG, NVDA often fails to automatically report incoming messages, particularly when there are less than ten messages in a conversation.

Description of how this pull request fixes the issue:

An NVDAObjects.behaviors.liveTextHistoryMixin class, which adds an announcement history to liveText objects, has been added. A displayModelLiveTextWithoutTextInfo class has also been added, which uses the display model to receive text updates but doesn't override an object's textInfo. Instead of relying on valueChange events from the scrollbar in message windows, the Miranda NG app module now uses both of these new classes to implement automatic readout of incoming messages.

Testing performed:

Tested automatic reporting in the #flood channel on Freenode after manually starting monitoring of the liveText object (with the Python console) and verified that it is functional starting from the very first message. Pressed control+nvda+1 through 0 while the conversation log had focus and verified that messages were being read.

Known issues with pull request:

• This implementation of MirandaMessageWindow._get_messageLog does not correctly find the control, so startMonitoring and stopMonitoring are not called when a conversation gains or loses focus. Interestingly, while the parent property of the read-only edit field properly refers to the conversation window, the control does not appear as one of its descendants.
• The history gestures (control+NVDA+1 through 0) only execute the script when the read-only edit field has focus, but they should call the script when focused on any control in the window. I think we need to set the canPropagate property on the script to get this behavior, but even with that property set to True this is not functioning as expected.

Change log entry:

== Bug Fixes ==

• In Miranda NG, incoming messages are now reported more consistently. (Improve automatic reporting of incoming messages in Miranda NG #9869)

== Changes for Developers ==

• Added a new NVDAObjects.behaviors.liveTextHistoryMixin class, which provides an announcement history class for liveText controls. This may be particularly useful for chat applications. (Improve automatic reporting of incoming messages in Miranda NG #9869)
• Added an NVDAObjects.window.displayModelLiveTextWithoutTextInfo class which uses the display model to report dynamic text changes without overriding an object's textInfo. (Improve automatic reporting of incoming messages in Miranda NG #9869)

[codeofdusk]

@feerrenrut @LeonarddeR Could you please have a look at this (particularly my implementation of _getMessageLog)?

[LeonarddeR]

I'm afraid that this will introduce the regression that you will no longer be able to read the history if your focus is not in the actual message log. Is that correct?

[LeonarddeR]

SHouldn't this inherrit from LiveText
I also think that you can leave out the word Mixin from the class name, as behaviors contains all mixins.

[codeofdusk]

I would, but wouldn't that cause issues (liveText would be in the MRO twice, once as the parent of the mixin and once as a parent of the object itself)?

[LeonarddeR]

I guess the dynamic class logic in NVDAObjets will deal with this, but it needs to be tried out.

[LeonarddeR]

This really relies on this being a subclass of LiveText.

Also, to follow Python 3 style, I think you can just do

Suggested change

	res = super(LiveTextHistoryMixin, self)._calculateNewText(newLines, oldLines)
	res = super()._calculateNewText(newLines, oldLines)

That won't work until Python 3 code is merged into master, but that will be in a short while, and I'm pretty sure @feerrenrut won't look into this beforehand.

[codeofdusk]

I'm afraid that this will introduce the regression that you will no longer be able to read the history if your focus is not in the actual message log. Is that correct?

@LeonarddeR Yes, this is correct. How can I fix this?

[LeonarddeR]

@codeofdusk commented on 5 Jul 2019, 07:09 CEST:

@LeonarddeR Yes, this is correct. How can I fix this?

Hmm, I need to think carefully about this. You could create a tree interceptor instead, but then you might as well just use the appModule.

You could also consider an appmodule mixin in appModuleHandler.

[LeonarddeR]

There is also the canPropagate property on scripts, but it still has to be set on one of the focus ancestors.

[feerrenrut]

@codeofdusk What are your plans with this PR? Note that it is still in draft state. What is outstanding? Do you want feedback on the approach?

[codeofdusk]

This PR in its current state introduces some regressions to Miranda functionality. As I don't heavily use Miranda, someone else might want to take this.