GNOME Bugzilla – Bug 571474
Widget tree functionality partially blocks
Last modified: 2010-08-09 23:44:29 UTC
Please describe the problem: After some use of glade, the widget tree triangles stop working, so it is impossible to collapse/expand branches. The 'triangle' still accuses presence of the cursor (changes color), but the branch won't change state. Same goes for the sub-branches. Steps to reproduce: 1. Use glade for a while 2. Try collapsing/expanding branches in the widget tree 3. Actual results: Triangle accuses presence of mouse, but no change of state Expected results: Act normally Does this happen every time? After some time, yes Other information: I'm not sure if related, but the triangles seem to have the same behaviour as intended for the widget in the composer - they need two click to get the selection bar to select the corresponding line. Also strange: if the cursor moves a couple of pixels while over a triangle, after each click, the selection never goes to that line (moving without actually leaving the active area).
Note that is potentially important. Normally it means scrolling a bit more, but in case there's a Combobox, access to the branch is necessary, as the box can't be selected on the composer (see previous bug).
Another note: Clicking on a non-ComboBox widget in the composer, the branch actually expands automatically (even if not expandable by cursor clicking).
Now it happens in the property editor too - in the signals page, I can't expand the branches, for example, to specify callbacks for the widget events. I can't find any work around for this, so, for me, this is a blocker...
This bug just became more important. I have experienced several times that, even after restarting Glade, and reloading the project, no collapsing/expanding was possible, and as such, access to vital parameters was inaccessible. As such, this problem is starting to hinder development seriously
Am seeing this here too. On current version of Ubuntu, both the packaged (3.6.3) and compiled-from-source 3.6.7 exhibit the behaviour. Happens frequently and randomly after glade has been open a little while - then prevents access to parts of the widget tree. Workaround is to restart glade.
Wow I really dont understand this bug very well. This has something to do with manually collapsed members in the inspector maybe ? in combination with the search entry ? Would it just solve everything if we just hid the expanders ? or does this happen even when you dont manually go expanding/collapsing rows in the inspector ?
I don't use the search entry - so I doubt that's involved. Please don't hide the expanders - even with a small-to-medium sized project it's really handy being able to collapse things and jump around. I might try building with debug to see if I can spot anything odd.
The triangles which should provide the collapse/expand functionality seem to freeze after a while. No more expanding is possible. If you'd hide the triangles, you have to have to leave the entire widget tree, which is hardly practical, particularly as this also includes the 'object' and 'action' trees (which also freeze). It just 'happens' after a while. It doesn't seem to relate to activating anything in the widget tree (i.e., it doesn't happen after collapsing/expanding - at least not in my experience). It might be related to something I reported before: irregularly (much less frequently than the collapse/expanding) glade just blows up (not even on the same desktop when it happens). I've just compiled a 64 bit version of the latest stable Glade, using the latest stable GTK+/glib, but haven't used it much yet.
... But it doesnt happen at all if you never touch the expanders at all ? I dont know Im groping in the dark, I have code in place right now to make sure the inspector is always expanded, i.e. whenever the project changes externally and the inspector needs to update, that way it "tries" to play nicely with the filter. I suspect the problem is rooted around there (the alternative is to have a messed up inspector when the project updates with a filter active). I guess I wont hide those expanders for now... we'll just hope someone fixes it right ? ;-)
> ... But it doesnt happen at all if you never touch the expanders at all ? I have the impression that the blocking occurs always. Sometimes I want to expand a line, and it fails, even if I have never touched any expander before. At least in my case, even blocked for clicking, the items still autoexpand (on external operations). But it's still a nuisance.
Tristan, I did a debug build, but there's quite a lot of code to go through! Can you point me directly at the code that handles the expanders? Maybe another pair of eyes might help? I have a vague suspicion something odd is happening with the signal handling - but I might be off-track there.
Sure thing, the widget tree is: glade3/gladeui/glade-inspector.c Maybe somewhere we are accessing the model directly instead of the filter where it shouldnt be the case ? really not sure.
Well - I got the bug happening under the debugger, but I'm afraid I couldn't really track it down. The button_press_cb DOES get called when the tree is non-responsive - but I don't really know where to go from there. You're welcome to remote into my workstation if it would help to see what's happening? Mail me directly if you want to. Steve
The widget tree in master was mostly reimplemented - you might want to check if this bug still exists. BTW, we have something similar in anjuta sometimes and we believe it is some kind of bug in gtk+.
Closing as OBSOLETE as per last comment. Please reopen this issue still exists. Or set to VERIFIED if it is indeed fixed. Thanks