Hi, thanks for the idea. I have written some code to implement it.

The implementation will expand the ancestor nodes in the widget tree. However I did not include a `gtk_tree_view_scroll_to_cell ()' as it did not really behave appropriately (inconsistent and jumpy scrolling).

Created attachment 79689 [details]
bug fix

I also did some other tinkering with the source. I moved GtkInputDialog
to the "Obsolete" palette category as it is described as "too specialized and
will eventually be removed from GTK+". 

2007-01-07  Vincent Geddes <vincent.geddes@gmail.com>

        * src/glade-project-view.c: Expand all rows on a path to a
          widget when it is selected.

        * configure.in: Quote some macro arguments. Use AS_HELP_STRING
          to format the messages for AC_ARG_ENABLE macros.

        * pixmaps/16x16/Makefile.am, pixmaps/22x22/Makefile.am: Add image
          for GtkLinkButton.

        * src/glade-editor-property.c: Modified some dialogs for HIG
          conformance.

        * widgets/gtk+.xml.in: Moved GtkInputDialog to "Obsolete"
          palette category.

hm, I think I was a bit quick off the heel with this one. After a discussion with tristan, we think that expanding nodes every time a widget is selected may not be appropriate. 

However, I think this still has value, but only when a widget is added to the project for the first time.

Hmmm, could be a good idea... I'm not so sure it should be done 
by default though, it could get very annoying when you lose your
place in the project window every time you add a new widget
in the UI (when you are working on large projects, its important
that you can depend on your position in the project view).

I would really like to see this feature available possibly
via a context menu-item and/or an accelerator, i.e. "focus
the project view on this widget NOW" - that should both
expand treeview nodes to the one we want to display, AND
it should also ensure that the treeview node is visible
(i.e. set the scrolled window vadjustment appropriately).

Well, there are two things here: expanding the collapsed rows in the treeview, and actually scrolling to the widget. I think you could expand rows by default (gtk_tree_view_expand_to_path) when selecting a widget (while keeping the currently-selected item in the inspector visible) without actually scrolling to that item in the inspector (gtk_tree_view_scroll_to_cell); is there annoyance caused by simply expanding rows, but not changing the selected item?

FWIW, the fact that the Inspector doesn't expand to show the current layout window selection has made me go back to using glade-2...

I guess I should say "why" :)  I think it's mostly because I often select a widget in order to locate one its containers (vbox, frame or whatever), and I find it far easier to trace a widget's ancestry in the Inspector view than in its right-click menu.

I agree with you and Colin on this issue. I did initially reject the problem, but have now changed my mind. I feel that the Inspector is very clumsy right now. Inspecting deep hierarchies of widgets is very hard since there is no feedback between the layout and the inspector. For large projects with hundreds of widgets, this problem becomes particularly acute.

Furthermore, I have looked at the behaviour of other GUI builders as a helpful guide. I found that the Inspectors in Netbeans and Qt-Designer both expand and scroll to the current selection.

Calum, on a related matter, what's your take on that right-click menu you mentioned? It displays a long list of ancestor widgets, each with a submenu. I don't like the design. A context menu is an odd place to display a list of ancestor widgets. It is also not clear whether the immediate ancestor is represented by top or the bottom of the list.

My point is that if the Inspector was more helpful, then there would be no need for the list in the first place.

Yeah, it would be nice to be able to get rid of that; the HIG does say somewhere that context menus are meant for operations applicable to the selected object only.

The ordering has always confused me too.  I guess you could try to improve that by also highlighting the widget corresponding to the currently-focused context menu item, but ISTR that updating stuff in a main window while one of its menus is posted is a bit of a technical challenge...

On a related note, I see that some of the genuinely useful right-click items from glade-2 (e.g. for inserting deleting rows/columns in tables etc.) have gone altogether in glade-3 :/  Are they due to make a comeback?

Since theres been some interest on this bug, lets comment...

My feelings are still the same regarding this bug, yes great
feature, lets. Only not at the cost of arbitrarily updating
Inspector widgets at the whim of a widget selection in workspace.

A context menu action ? sure... a toolbar option/keyboard shortcut even ?
(i.e. a "Focus Inspector on currently selected widget" action)

I'm sure a compromise can be made so that we can include this
feature without implementing any "tight coupleing" of the 
Inspector & Workspace widgets. 

(In reply to comment #9)
> Yeah, it would be nice to be able to get rid of that; the HIG does say
> somewhere that context menus are meant for operations applicable to the
> selected object only.

If we have a way to "scroll-to-position & expand to item" from
the context menu - then the items for selecting parents in the 
context menu become essentially useless - except for the fact
that you could have selected the parents in less clicks, in this
case I think we all agree that this is not worth the feature
and we'd rather throw it out in favour of using the Inspector more.

> On a related note, I see that some of the genuinely useful right-click items
> from glade-2 (e.g. for inserting deleting rows/columns in tables etc.) have
> gone altogether in glade-3 :/  Are they due to make a comeback?

Yes we've went so far as to create an infrastructure to attach
code segments to menu items on a widget class basis, it only remains
to implement these "bells and whistle" features, they should be
in really early in 3.3 I guess (see bug 343786 and bug 345602).

I don't think it will be good to fix this bug by implementing a menu/accelerator action. Expanding and scrolling to the current selection in the inspector should happen automatically (i.e. upon selecting a widget in the main view/workspace), and I'll explain why.

> My feelings are still the same regarding this bug, yes great
> feature, lets. Only not at the cost of arbitrarily updating
> Inspector widgets at the whim of a widget selection in workspace.

This "cost" of automatically expanding and scrolling to the current selection in the Inspector really needs to be explained some more. The description does not provide much to analyse or work with.

If I understand, you don't want the scrollbar adjustments of the Inspector to be changed automatically. This change will of course happen when automatically expanding and scrolling to the Inspectors selection (after a change in the selection in the main view/layout). In more general terms, you don't want the users current "viewable area" or "place" in the Inspector to be changed automatically.

This perceived problem really needs to be proved and tested. IMHO, it is only an opinion and hypothesis at this stage, since no users have come forward to say that this is a real problem. Or in other words, this design problem has not been backed up by users reporting on their actual ui interaction activities.

The argument for this problem is partly flawed when one considers that the current widget in the workspace/layout is the _current focus_ of the users attention. By simple reasoning, this means that the current widget is most likely to be in the Inspector's current viewable area anyway (for toplevel widgets at least). This makes the perceived problem a non-entity, since the user is still able to see the focus of his activities in the inspector.

Also, as helpful evidence, it looks like some other GUI Builder applications do not consider this problem. Netbeans and Qt-Designer both automatically expand and scroll to the current selection (I tested them both).

> A context menu action ? sure... a toolbar option/keyboard shortcut even ?
> (i.e. a "Focus Inspector on currently selected widget" action)

It could get annoying very quickly If I have to ask glade every time I want it to work properly for me.

I certainly do not want to have to click on a context menu every time I want a usable and helpful Inspector. It puts a superficial band-aid on the problem, but does not actually solve the root problem — this being the need for the UI to _adapt_ to the current focus of the user's editing activities, clearly a good thing.

My take on this is that the most valued and helpful behaviour should be the default. From all the user complaints and input, it seems like the idea of expanding and scrolling to the current selection automatically (without menu actions) seems to valued very highly, more so than this hypothetical problem of having to keep the current view/place in the inspector.

> I'm sure a compromise can be made so that we can include this
> feature without implementing any "tight coupleing" of the 
> Inspector & Workspace widgets. 

The Inspector and Workspace/Layout components are already highly coupled, since changing the selection in one component leads to a selection change in the other. Anyway, I think that any semantic argument that these components need to be independent of each other has not been backed up by the so-far-reported experience of our users. Bug #399579 is yet more evidence to this point.

Maybe we just need to look at the Inspector from another point of view. So far all it does is allow users to inspect all objects in the project. If we extend the notion of the Inspector as a tool to help with the _current focus_ of editing activity, then the need for automatic expand and scroll to selection becomes immediately clear.

So how can we overcome this impasse?

For this kind of UI design problem, User Testing, I say. We implement automatic expand and scroll to selection, make a new release (after GNOME 2.18), and see what users have to say. If users do not like it then we refine the implementation or try out the menu/accelerator action implementation.

I think this is a reasonable plan of action. Users who have been affected by the problem get their remedy. Users who may be affected by the perceived "need to keep the view/place in Inspector" problem get an opportunity to come forward. We (the developers) get evidence of the effectiveness of various solutions to the problem.

Let's look at the GNOME Control Centre Shell debate for evidence of the value of this testing approach. The new shell was made the default for the GNOME 2.17 releases. Later, a large portion of users disliked it, and around lots of debate, the shell was then disabled by default. This shows the value of letting users test in-progress ui designs before any final decisions are made.

For me, it's more black-and-white than that... it's simply a feature regression that makes using glade-3 a less productive experience than its predecessor.  Experience tells us that it's unwise to change fundamental behaviour between releases (even major releases) unless we have user feedback to suggest that it's worthwhile.  Were there actually any complaints about the glade-2 behaviour?

A compromise, perhaps[1], would be to have double-clicking a widget reveal it in the Inspector... personally I could probably live with that, although it's not terribly discoverable.  I know some widgets already have double-click behaviour, but nothing (I hope) that isn't already achievable from the Properties window, so that wouldn't really be a big loss unless you were planning to add double-click functionality to more widgets in future.

[1] Of course, designing UIs by compromise usually sets alarm bells ringing :)

Calum,
   Thankyou for taking the time to express your ideas clearly
and for listening to mine - I think we can reach some common
ground, just bear with me... 

My opinion is first and foremost that glade must remain usable
for the most complex projects - if the glade tool can provide
a usefull working environment for a project with 1 - 15 toplevel
widgets, each with complex sub-hierarchies then it can surely
handle a glade file that contains a single dialog.

The one major regression I can see thus far in this respect
is that the "Inspector" (...as were now calling it) is not
dockable and even worse... it must share space with the property
editor (which is already in a major lack of screen realestate).

Here are some examples of what i'd call a complex project:
http://www.gnome.org/~tvb/glade-tt-screenies/glade3-tt-animation.jpg
http://www.gnome.org/~tvb/mytt.jpg

When working with thousands of widgets, you can lose yourself
really really fast, luckily in Glade 3.0 we had a toplevel
Inspector which could be expanded to fit the whole screen height
and allowed the user to keep a tab on what area(s) of the project
they are currently working on.

Anyway, I wanted to say all that just so you understand the
severity of the issue before we go and make hasty decisions...
I did further consult one of the the artists that normally 
use the tool for these complex glade files about this bug... 
he said he would be comfortable if we did implement this... 
he also said that if we did the oposite (i.e. always update 
the workspace on the whim of an Inspector selection) that it
would quickly become too confusing to work with.

I would be happy to try out this new functionality and add
"when the user double-clicks on any widget in the Inspector,
its toplevel gets shown in the workspace"... 

there is a remaining technical issue in libgladeui though; 
we still have to consider flexability in the code glade library, 
if we publish Inspector widgets and workspace widgets - the
IDE should be able to instantiate as many as they wish and attach 
them to whatever projects/widgets are available (i.e. the tight 
couplage between the inspector and the workspace should be a part
of the glade frontend and not forced upon the frontend IDE by the core).

As another thought, if we experiment with this behaviour
in 3.3.x we can always consider this as a possible option
in a hypothetical preferences dialog.

Ok I think there should be some movement here... I think we can
all agree that if we can get the inspector widget to behave better,
then we can eliminate the use-case for the submenus in the context
menu, which would be an all around good thing (as specially in
light of per-widget coded/scripted actions that will also go in the
context menu, such as "Edit menus..." or "Add alignment").

As a note on the inspector, it would be important not to scroll
to position at least in the case that the project selection was
initiated by the inspector itself (which would obviously cause
undesirable "jumpyness").

Also, if we go through a slight redesign as Vincent suggests in
bug 431170 (one project one window), then we can easily put different
toplevels in different notebook tabs in the same project's window;
also making things more comprehensive and navigatable as a whole
(no need to switch notebook tabs upon the whim of a widget selection
in my opinion, but I think this will all together improve things).

fixed in trunk and the gnome-2-18 branch.