After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 571474 - Widget tree functionality partially blocks
Widget tree functionality partially blocks
Status: RESOLVED OBSOLETE
Product: glade
Classification: Applications
Component: user interface
3.5.x
Other All
: Normal blocker
: ---
Assigned To: Glade 3 Maintainers
Glade 3 Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-02-12 14:52 UTC by John
Modified: 2010-08-09 23:44 UTC
See Also:
GNOME target: ---
GNOME version: 2.23/2.24



Description John 2009-02-12 14:52:40 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).
Comment 1 John 2009-02-12 14:57:00 UTC
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).
Comment 2 John 2009-02-12 14:59:03 UTC
Another note: Clicking on a non-ComboBox widget in the composer, the branch
actually expands automatically (even if not expandable by cursor clicking).
Comment 3 John 2009-02-14 15:06:18 UTC
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...
Comment 4 John 2009-02-20 13:19:37 UTC
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
Comment 5 Steve Merrony 2009-07-11 14:55:48 UTC
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.
Comment 6 Tristan Van Berkom 2009-07-11 15:13:56 UTC
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 ?

Comment 7 Steve Merrony 2009-07-11 16:01:17 UTC
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.
Comment 8 John 2009-07-11 17:18:32 UTC
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.
Comment 9 Tristan Van Berkom 2009-07-11 22:23:51 UTC
... 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 ? ;-)
Comment 10 John 2009-07-11 22:55:43 UTC
> ... 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.
Comment 11 Steve Merrony 2009-07-12 10:48:54 UTC
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.
Comment 12 Tristan Van Berkom 2009-07-12 12:59:51 UTC
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.
Comment 13 Steve Merrony 2009-07-12 14:20:00 UTC
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
Comment 14 Johannes Schmid 2010-06-17 12:41:05 UTC
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+.
Comment 15 Tobias Mueller 2010-08-09 23:44:29 UTC
Closing as OBSOLETE as per last comment. Please reopen this issue still exists. Or set to VERIFIED if it is indeed fixed. Thanks