When openning a big folder accessibility is spammed

[alexarnaud]

Expected behaviour

Caja shouldn't emit the event property-change when launching the folder for the first time, see this explanation from the Orca on the mailing list: https://mail.gnome.org/archives/orca-list/2018-March/msg00240.html

Actual behaviour

Caja emits one event property-change for each file in the folder, more file you've, more laggy Orca will be. On a folder with 1000 files, we've a lag of 10s.

Steps to reproduce the behaviour

1. Open Accerciser (accessibility explorer)
2. On the monitor events, check "object:property-change:accessible-name"
3. Open Caja
4. Enter on a big folder (with lot of files)

MATE general version

1.20.0

Package version

1.20.0-2

Linux Distribution

Debian

[alexarnaud]

@raveit65 @monsta @lukefromdc @sc0w Do you know if we're using a customer icon view on Caja or if we're using GtkFlowBox? It seems Nautilus has been migrated to this but what's about Caja?

I've grep a bit in the source code but I'm unable to find the culprits events from the source code. Could you help me a bit?

Best regards,
Alex.

[lukefromdc]

The GtkFlowBox is not used anywhere in Caja, a source directory search for that string returns no results. The canvas showing the icons is a custom widget-and that is one of the reasons GNOME dropped nautilus-desktop: they found it too hard to port to Wayland and wanted to drop it. Since GNOME devs don't use desktop icons, they don't want to do the work to support anyone else using them and just dropped the desktop from Nautilus. If they wanted to migrate away from the icon canvas that they called so complex, they could either do this, or special-case the desktop (already in a separate binary) to be the only window using it.

[alexarnaud]

Hello @lukefromdc

I'm trying to help figuring out this issue, is the source code for displaying files in icon view is fm-icon-view.c ? What should be the function that display the files on the screen when entering inside a folder ? I assume somewhere a function call "fm_icon_view_add_file"
I only see that with grep:

src/file-manager/fm-icon-view.c:603:fm_icon_view_add_file (FMDirectoryView *view, CajaFile *file, CajaDirectory *directory)
src/file-manager/fm-icon-view.c:3165: fm_directory_view_class->add_file = fm_icon_view_add_file;

Best regards,
Alex.

[lukefromdc]

Not sure at the moment: look at that file, eel-canvas.c , eel-canvas-rect-ellipse.c (maybe), caja-icon-canvas-item.c and related files.

[pvagner]

My guess would be that it might be an issue inherited from GTK plus as nautilus and GTK File Chooser seem to be also affected by this.

[monsta]

Well, we can try looking into older Nautilus code to see if this is fixed (before moving to that flow box, whatever it is).

[monsta]

@alexarnaud: I guess this affects not only 1.20 but earlier releases too?

[alexarnaud]

Le 19/04/2018 à 20:54, monsta a écrit :

@alexarnaud <https://github.com/alexarnaud>: I guess this affects not only 1.20 but earlier releases too?

On Caja 1.8 GTK2, I don't reproduce the issue. The difference seems to be the different behavior. On Caja 1.8, if I've 10000 files on the folder, Caja will wait until to load the 10000 files to present them on the screen whereas latest Caja will load file one by one and displays them on the screen progressively. Best regards, Alex.

[alexarnaud]

Le 19/04/2018 à 20:53, monsta a écrit :

Well, we can try looking into older Nautilus code to see if this is fixed (before moving to that flow box, whatever it is).

I can reproduce the issue on Nautilus 3.26.2. Best regards, Alex.

[monsta]

So it indeed might be something in GTK+3 widget(s) on which custom icon view widget is based...

[alexarnaud]

@monsta @lukefromdc If we add a bounty on such bug, would you be interesting to fix it even if it's in GTK itself? If yes, how many bounty do you think it is reasonable for such bug?

Best regards,
Alex.

[joanmarie]

It turns out there's also an excessive number of children-changed events, so the problem is bigger than the name-change.

[lukefromdc]

I don't know enough about this right now to work on it, and unless Bountysource reinstates physical checks going forward I expect to be unable to collect future bounties (no Paypal account) even if they special-case the surprise I got on the last bounty.

[joanmarie]

@lukefromdc mind taking a look at pull request #979. That solves the name-change spam. (Deciding how best to tackle the children-changed spam still remains.)

Edit: And/or @monsta.

[alexarnaud]

Le 20/04/2018 à 21:49, joanmarie a écrit :

@lukefromdc <https://github.com/lukefromdc> mind taking a look at pull request #979 <#979>. That solves the name-change spam. (Deciding how best to tackle the children-changed spam still remains.)

Are you sure children-change is not relevant? As the view is loaded progressively the view is always recreated. Or what about this case? Should we ignore children-change events on first load? Best regards, Alex.

[monsta]

I don't know enough about this right now to work on it

Same for me. I don't know if bounty is going to attract some other developers who might fix this. But I guess it won't hurt.

[joanmarie]

And for the children-changed spam: pull request #981

[joanmarie]

@alexarnaud regarding this:

Are you sure children-change is not relevant?

Where did I say that? In fact, that is the reason why I suggested here that it needs to be tackled and on the Orca list that this was a problem. Event floods are teh suck and there's only so much I can do in Orca to hack around this sort of problem. I just think one should do independent changes independently, hence the separate pull requests.

[joanmarie]

Found another children-changed event flood coming from the icon container. Hopefully that's all of them.... Pull request #984 open for your consideration. Thanks!