GNOME Bugzilla – Bug 672046
Issues with widget state propagation
Last modified: 2012-12-18 20:56:03 UTC
Created attachment 209705 [details] example I noticed that the text-shadow in the breadcrumbs aren't done right. Here are the problems along with the suggestions: Problems: - The black text is a little fuzzy, probably because of the black text-shadow underneath. - The hover over the previously visited links appears broken. - The white text in the pressed state has raised feel and it is hard to read. Suggestions: Well, I wanted to actually fix the problems and present them to you, but I couldn't. Instead here's what I would've done: - Get rid of the black text-shadow or make it white-ish, I should look engraved.(normal state) - Obviously, fix the hover state. Although, it doesn't always look that way. :/ - Make the pressed button feel more pressed.
Created attachment 209706 [details] example2 Here's another example which looks totally different from the previous one.
Created attachment 209710 [details] mockup And this is a quick mockup showing what I mean. :)
-> gtk+ This is a bug in the way GTK+ propagates style changes to child widgets, I think Benjamin is working on it.
*** Bug 672113 has been marked as a duplicate of this bug. ***
*** Bug 674299 has been marked as a duplicate of this bug. ***
This is still an issue in master after the new GtkCssValue work.
There is a similar issue with nautilus described there: https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/973491 steps to trigger: - restart nautilus (make sure to be in icon view) - right click on an empty spot of the background to get the current dir context menu - close it - right click on a folder, select copy - right click on the background the "paste" item is displayed as unactive but is active (i.e it can be selected and works) Video: https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/973491/+attachment/3009183/+files/nautilus_bug.ogv (Commenting here since Cosimo thinks it's that same gtk bug)
*** Bug 678823 has been marked as a duplicate of this bug. ***
I've pushed a branch wip/cssdep that should fix this issue. It needs some performance tuning still, but the bug should be gone already.
Looks good here so far. Only difference (other than state propagation working correctly now) is that the 'CSS accordion' in gtk3-demo has lost its nice animated transitions.
Whoops, that was me turning of animations for debugging purposes and leaving that in the patchset. I've pushed an updated and rebased patchset.
I tried the branch and it seems to solve the bug in some simple cases I tested where it was previously always triggered. The commits in the branch also looks good to me, code-wise.
Accordion works again in the new branch, thanks. As Cosimo said, looks good. Two questions: - What are the remaining optimizations here ? I guess replacing grep EVERYTHING *.c gtkcssarrayvalue.c: *dependencies = GTK_CSS_DEPENDS_ON_EVERYTHING; gtkcssbgsizevalue.c: *dependencies = GTK_CSS_DEPENDS_ON_EVERYTHING; gtkcssimagevalue.c: *dependencies = GTK_CSS_DEPENDS_ON_EVERYTHING; gtkcssshadowsvalue.c: *dependencies = GTK_CSS_DEPENDS_ON_EVERYTHING; gtkcssshadowvalue.c: *dependencies = GTK_CSS_DEPENDS_ON_EVERYTHING; gtkcsstypedvalue.c: *dependencies = GTK_CSS_DEPENDS_ON_EVERYTHING; gtksymboliccolor.c: *dependencies = GTK_CSS_DEPENDS_ON_EVERYTHING; with something that actually computes dependencies ? I can't really help out with this, as I only have a very superficial understanding of the code. Having some overview writeup of how our css implementation works would be nice, btw... As an example, I would guess that for gtkcssarrayvalue, the dependencies would be computed by just building the union of all the array members' dependencies. Right ? - What would a testcase for performance issues look like ? Do you have one we could include ?
Created attachment 222406 [details] [review] the remaining 'simple' cases
Oh, pushed by accident. Revert if it doesn't look right...
Finished the branch and pushed to master.
Matthias had asked me for the numbers of my default benchmark of running glade with a huge project, so here's the completely unscientific numbers: 61.7s GTK 3.4.4 14.1s GTK 3.5.3 15.3s GTK git master
*** Bug 673621 has been marked as a duplicate of this bug. ***
(In reply to comment #16) > Finished the branch and pushed to master. This particular bug is closed by the following commit [1]. commit 8ff08e7c5e7da785a37c56018b1ae4b57cb77e64 Author: Benjamin Otte <otte@redhat.com> Date: Fri Aug 24 18:17:52 2012 +0200 stylecontext: Update computed values when dependencies change This fixes the longstanding bug where GTK would not update styles when parent styles would change. https://bugzilla.gnome.org/show_bug.cgi?id=672046 [1] http://git.gnome.org/browse/gtk+/commit/?id=8ff08e7c5e7da785a37c56018b1ae4b57cb77e64
Is there any way, to get this backported to branch gtk-3-4? Could the branch (Where is it?) just be merged to branch gtk-3-4?
In Debian this issue for libgtk-3-0 3.4.2-3 is tracked as #687578 [1]. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=687578
(In reply to comment #20) > Is there any way, to get this backported to branch gtk-3-4? > I wouldn't do that, even if it worked (which I don't think it does). You'd end up with a GTK that is neither 3.4 nor 3.6 and I definitely won't look at any of your bugs with that.
*** Bug 685804 has been marked as a duplicate of this bug. ***
*** Bug 686396 has been marked as a duplicate of this bug. ***
I'm not sure I understand comment 22. Will the fix for this be applied to GTK 3.4.x? Or, has it already been merged? I am currently seeing this usability bug using Debian Wheezy with libgtk-3-0 (3.4.2-4)
No, the fix will not be applied to GTK 3.4.