Re: [orca-list] Orca Hangs When Trying to Read Large Text File in Pluma



Gedit definitely does this too. I've occasionally opened larger files than normal--maybe on the order of 20-30 MB--and it chokes. I can't imagine a problem like this would exist outside of an accessibility context. I mean, if Gedit froze whenever someone accidentally opened a large file and wasn't using Orca, that seems like the kind of bug that'd get fixed, though I can't verify since I need Orca. And my machine is definitely up to the task (32 GB of RAM) so I find it hard to believe that a text editor would fail to load a file that is less than 1% of my total memory.


That said, this does sound like a producer rather than a consumer issue (I.e. something upstream shouldn't be generating a11y events just because Gedit or anything else opens a large file.)


On 3/14/20 1:33 PM, Jude DaShiell wrote:
Was plume even designed to edit large files?  If not, other options
exist.  Genie gets good ratings and emacs can get a job like that done
even xemacs could do that.

On Sat, 14 Mar 2020, Arkadiusz Kozio? wrote:

Date: Sat, 14 Mar 2020 13:56:32
From: Arkadiusz Kozio? <zywek-mailing nvps pl>
To: orca-list gnome org
Subject: Re: [orca-list] Orca Hangs When Trying to Read Large Text File in
     Pluma

So you can't do anything with this at-spi2 events?

W dniu 14.03.2020 o?18:35, Joanmarie Diggs pisze:
Not 100% sure. Gtk (I assume) is being super spammy, not just with
text-insertion events (1 event for every 8192 characters inserted), but also
with caret-moved events because Gtk (I assume) is emitting a caret-moved
event after each insertion.

But it looks like it might be an AT-SPI2 one as well. Because at some point
in the flood, we go from getting valid events to getting events from "dead"
accessibles. For instance:

13:20:39.753794 - EVENT MANAGER: object:text-changed:insert for [DEAD] in
[DEAD] (10764288, 8192,
8wekyb3d8bbwe/AppCS/Assets/ModularMusic/Classic_00/music_Neutral_01_LOOP_E.wma:
OK

13:20:39.753950 - EVENT MANAGER: object:text-caret-moved for [DEAD] in
[DEAD] (10772480, 0, 0)

13:20:39.754068 - EVENT MANAGER: object:property-change:accessible-value for
[DEAD] in [DEAD] (0, 0, 0)

That suggest that Pluma may have gone completely non-responsive (as far as
AT-SPI2 is concerned) and/or that AT-SPI2 is completely unhappy. Not sure
which, but that's not an Orca bug. All I can do in Orca is try to discard
these events as quickly as possible.




On 3/14/20 13:12, Alex ARNAUD via orca-list wrote:
Le 14/03/2020 ? 18:06, Joanmarie Diggs a ?crit?:
Confirmed. Orca is getting flooded by insanely large text insertion
events. I'll see if I catch that condition and eliminate it. Thanks for
the report!
Is it a GTK issue or a more general one?

Best regards.

_______________________________________________
orca-list mailing list
orca-list gnome org
https://mail.gnome.org/mailman/listinfo/orca-list
Orca wiki: https://wiki.gnome.org/Projects/Orca
Orca documentation: https://help.gnome.org/users/orca/stable/
GNOME Universal Access guide:
https://help.gnome.org/users/gnome-help/stable/a11y.html

_______________________________________________
orca-list mailing list
orca-list gnome org
https://mail.gnome.org/mailman/listinfo/orca-list
Orca wiki: https://wiki.gnome.org/Projects/Orca
Orca documentation: https://help.gnome.org/users/orca/stable/
GNOME Universal Access guide:
https://help.gnome.org/users/gnome-help/stable/a11y.html
_______________________________________________
orca-list mailing list
orca-list gnome org
https://mail.gnome.org/mailman/listinfo/orca-list
Orca wiki: https://wiki.gnome.org/Projects/Orca
Orca documentation: https://help.gnome.org/users/orca/stable/
GNOME Universal Access guide:
https://help.gnome.org/users/gnome-help/stable/a11y.html



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]