GNOME Bugzilla – Bug 123026
GtkNotebook gets confused when showing/hiding widgets on a never-mapped page
Last modified: 2011-02-04 16:16:53 UTC
the path tool options only appear when a) the tool-options dialog is the visible dialog of the docked dialogs b) i have newly switched to the path tool (ie. bringing up the path tool then selecting the tool-options from the dock gives no visible options) this is the procedure i followed: start up the gimp. with the palette selection dialog visible *, i select the path tool. i select the tool-options from the dock. nothing is visible. i select another tool (pencil usually), then select path again. the proper tool options for the path tool appear. * as part of a set of dialogs docked onto the toolbox, including tool-options.
This is not restricted to the path tool. It can be reproduced with other tools as well. IIRC there is bug report about this problem already.
Can't find a bug report on this one but I could reproduce it. Confirming and setting milestone to 2.0.
This is clearly a bug in GtkNotebook. We just show/hide widgets on a notebook tab that was never mapped before. The notebook probably gets lost in its disrespect for visible/mapped constraints. Reassigning to GTK+
I can't reproduce this. Can you provide a test case ?
*** Bug 126778 has been marked as a duplicate of this bug. ***
*** Bug 131249 has been marked as a duplicate of this bug. ***
Needs standalone compileable test case.
The GIMP 1.3.20 isn't good enough, I suppose? :) Dave.
this problem became apparent immediately that gimp supported dockable dialogs. most if not all 1.3.xx versions of gimp evidence it, all 2.0pre versions evidence it. minimal requirements for confirmation: two tabs, one that hasn't been mapped yet (ie is not the active tab + hasn't been the active tab). switching to the currently inactive tab can show nothing at all. alteration of the tab contents while it is visible causes remapping -> now it becomes visible. correct me on my terminology if necessary -- i partially adlibed it.
As Owen said: Needs standalone compileable test case. You have described one, now we just need to find someone to code it up...
To clarify, the key word here is "standalone" - having a one file test as compared to the GIMP means that the time for someone to start working on this is a couple of minutes rather than an hour or more if they have to compile the GIMP. Plus there are far less complicating factors, gdb runs much faster, etc.
Mass changing gtk+ bugs with target milestone of 2.4.2 to target 2.4.4, as Matthias said he was trying to do himself on IRC and was asking for help with. If you see this message, it means I was successful at fixing the borken-ness in bugzilla :) Sorry for the spam; just query on this message and delete all emails you get with this message, since there will probably be a lot.
Lets see if NEEDINFO can produce another testcase...
I believe this is the same issue as bug 302283, which has a testcase. I'll dup this one. *** This bug has been marked as a duplicate of 302283 ***
*** Bug 332325 has been marked as a duplicate of this bug. ***