New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix scrolling and renaming in large folders #759
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Works, fixes the problem same as in my earlier test of same code without the cosmetic grid change. Happy with it either way but this keeps the appearance the same and in my judgement looks a bit better
@sc0w |
relayouting The GtkScrolledWindow uses the widget prefered size as a guess as to whether scrollbars are needed or not in the automatic scrollbars case. If we don't report anything for them we typically get it wrong and cause two size allocate calls on the child each time, with different sizes. This (the two sizes speicifically) will cause unnecessary relayouts of the window. So, we just report the current size of the layed out icons as the prefered size. This is somewhat wrong as its depending on previous size_allocation calls rather than the "ideal" size of the widget, but since the ideal size is ignored anyway and just used for this it works well. taken from: https://git.gnome.org/browse/nautilus/commit/?id=fa6e447
Not queueing resizes may play oddly with the size request caches in GTK+, resulting in gtk_widget_get_preferred_width/height returning 0 even after the canvas was populated. https://bugzilla.gnome.org/show_bug.cgi?id=667831 Taken from: https://git.gnome.org/browse/nautilus/commit/?id=8c77821
Both versions (dev-view and dev-experimental) rebased after 4dbf114 |
The fix works for me The changes in the look are minimal, so, I agree with this PR |
The vote was more for the other branch (dev-experimental) with 'Expand grid width to canvas' |
@monsta @XRevan86 @flexiondotorg Well, it change the look and feel if you rezize caja window, but honestly how often you resize the window. Reopen for voting |
@sbalneav what do you think? |
I don't like the last comment in linuxmint/nemo#1257... |
see @lukefromdc comment at #755 (comment) |
@monsta |
https://github.com/monsta , the Nemo issue mentioned was one caused by the dynamic gred resize that we decided not to merge, and I was not able to reproduce it in builds of Caja that included that commit. Certainly we won't have that as Caja sits not, because we've kept the constant-width columns while still fixing the scroll bug on large folders and maximum right side gap. |
At any rate, dev-experimental is just one more commit that can be easily merged if people want to do so-and as I said I was unable to duplicate the label bug reported against Nemo. |
I missed these comments at #755 indeed, I wasn't subscribed to that report. I'll check the "experimental" commit. |
@monsta |
I don't think I pulled anything from Transifex lately... |
Hmm, the new behavior from "experimental" commit might be better than the current. It takes some time to get used to it, so if we merge it, it should be only for master branch. Should we create a new PR for that change? |
If you want..... |
fixes #755
First time it's a bit hard to reproduce the issue, see this posts.
#755 (comment)
#755 (comment)
https://www.dropbox.com/s/8ftp9gois751892/caja-issue.ogv?dl=0
Note, i added a cosmetic back port of a nemo commit in another branch (dev-experimental), which reduce the width of the gap between grid of items and vertical right scrollbar.
Taken from linuxmint/nemo#1257
But this dynamically grid change the look and feel of the icon-view and isn't really needed to fix the issue.
Please vote here if you like this behaviour or not.