As of gtk 3.24.7 (Arch), Thunar's "Create Document" submenu no long displays any content. Hovering over the thin line that is shown, generates the error message:
*** BUG ***
In pixman_region32_init_rect: Invalid rectangle passed
Set a breakpoint on '_pixman_log_error' to debug
Reverting back to previous version of GTK3 (3.24.5) results in a working sub-menu again.
The "Create Document" submenu in xfdesktop is unaffected.
Meh, yet another gtk3 problem :/ .. thanks for reporting !
Noticed another odd idiosyncrasy. When right-clicking on a file, the popup menu is compressed with arrows at the top an bottom. If I scroll through all of the options, then the complete menu will show (without the arrows) from there on in until thunar is restarted.
Looks like it might be related to the issue above.
I am on debian testing, which currently ships gtk 3.24.5 ... soo I will just wait a bit till 3.24.7 is available here ... dont want to build gtk3 from source.
Though AndreLDM as well uses arch ... I'll ask if he feels like taking a look into it.
*** Bug 15221 has been marked as a duplicate of this bug. ***
Yes, I can reproduce, tried to investigate it last week, but no luck. I suspect this is caused because the menu is populated asynchronously (ThunarJob), but it could be a gtk regression. Perhaps git bisect'ing gtk could yield some answers.
*** Bug 15224 has been marked as a duplicate of this bug. ***
Created attachment 8362
Commit log of git-bisect
The GTK+ commit 57300b49602b856b53f5d30ab3174591c0fb2845 is the culprit for this issue.
I have also attached the log of git-bisect here and hope this was helpful.
Reverting only this commit for 3.24.7 resolves this issue, so it is definitively this commit which breaks the menu.
*** Bug 15226 has been marked as a duplicate of this bug. ***
*** Bug 15246 has been marked as a duplicate of this bug. ***
Thanks Thomas for the bisect, unfortunately that commit doesn't show anything that I can related to this bug.
I already spent some time investigating this, but nothing conclusive yet, just that the problem may stem from here:
Menu items are added after the show signal and only after a ThunarJob is finished. That causes the menu to have scrollbars, I just don't know why the menu items aren't shown. If they are hardcoded to be added right after the "show" signal, they will appear.
Xfdesktop is not affected because menu items for file templates are created before the menu is shown (i.e. synchronously). This seems to be a race condition we are dealing with.
I'm working on a reproducer sample so I can report this to gtk devs.
*** Bug 15255 has been marked as a duplicate of this bug. ***
If you want a reproducer, I guess you can use one of gnome apps, for example take 'evince' and use open dialog.
Steps would be:
1. Launch evince
2. Click 'open' button
3. Select 'All files'
4. Move open dialog window, so 'All files' is just below top of screen
5. Click 'All files' and then scroll down (using mouse scroll) and click back on window to unselect menu ('All files' still should be selected after this)
6. Move open dialog window back to the center of screen, so it has lots of space and shouldn't need to do scrolled menus
7. Click 'All files' and observe that it creates scrolled menu
Overall I would say there is something wrong with how gtk3 calculates if menus need scroll arrows.
*** Bug 15283 has been marked as a duplicate of this bug. ***
Created attachment 8408
The attached patch changes the template loading to be synchronous.
I didn't notice any side-effect, with hundreds of files in ~/Templates the context menu appears without any delay.
That fixed it for me.
Thanks. This fixes the missing templates folder.
The scrolling right-click menu issue still exists though. Does the same asynchronous menu population routines exist for the context menu?
(In reply to ToZ from comment #18)
> The scrolling right-click menu issue still exists though.
I think that's a GTK regression, need to check if there's a bug for this.
> Does the same
> asynchronous menu population routines exist for the context menu?
I don't know that part of code very well, but I'm almost sure everything else is sync.
Andre Miranda referenced this bugreport in commit 6f980dbd6fed2b471d9fb9c7e1dd11d95b502150
Load templates synchronously (Bug #15200)
Nemo is also affected (includes link to upstream):
Andre Miranda referenced this bugreport in commit 9004a8237c4192f54e32a38e29ee29f625d72e2a
Load templates synchronously (Bug #15200)
(In reply to Andre Miranda from comment #21)
> Nemo is also affected (includes link to upstream):
Just to be clear, I meant the unnecessary arrow scrolls.
Upstream bug: https://gitlab.gnome.org/GNOME/gtk/issues/1843
I'm closing this bug since the fix landed the development branches and will be available in the next release.
I tried to apply the patch in the version 1.8.4 but I have this error during compile time:
make: *** No rule to make target 'thunar-misc-jobs.c', needed by 'thunar-thunar-misc-jobs.o'. Stop.
How can I fix this?
Looks like you are mising a generated Makefile ? Possibly try to make clean and ./autogen.sh again before make.
Or if nothing helps, do a fresh clone. The following should do:
git clone https://git.xfce.org/xfce/thunar --branch thunar-1.8.4
curl https://git.xfce.org/xfce/thunar/patch/?id=9004a8237c4192f54e32a38e29ee29f625d72e2a | git am
Created attachment 8506
Comment on attachment 8506
This is the Slackbuild I am trying to use to compile Thunar.
I have already tried to add the ./autogen.sh but it does not work.
The script compiles without any issue if I remove the patch.
You need to apply this preceding change as well:
Andre Miranda referenced this bugreport in commit fe9eec8d923d318ab49044724334370bfbbb06d3
Job is now optional for thunar_io_scan_directory