GNOME Bugzilla – Bug 399579
selecting items in Inspector
Last modified: 2010-12-31 07:09:47 UTC
When an item in the Inspector is selected, it and it's parent window should be shown in the workspace. Right now, this only happens when an item is activated or double-clicked in the inspector. Even in this case, only when a toplevel (GtkWindow) item is activated, will anything switch in the workspace. This is a usability blocker for 3.2, I'd say.
I think right now that would be a drastic change and would also inhibit some aspects of usability. a.) I agree that the toplevel should be shown when a "show" request has been made on any of the child widgets b.) I dont agree that a "show" request should be done for a single click. If we make this "show" on a single click, then the user will have no choice but to see the workspace change every time he wants to browse some properties in another window, I just dont think this should be involuntary. I have the same opinion for bug 392225, basically the user should be allowed to browse the workspace without effecting the project-view, and the user should also be able to browse the project-view without effecting the workspace. Shortcuts are definitely needed to make it easy to synchronize both, but I dont think in any case that it should be implicit.
hi tristan, > b.) I dont agree that a "show" request should be done > for a single click. > > If we make this "show" on a single click, then the user > will have no choice but to see the workspace change every > time he wants to browse some properties in another window, > I just dont think this should be involuntary. > Is there a problem with seeing the workspace change every time? I don't think this is a usability problem at all. The user can simply select the old widget again if we wants to go back. If it really is problem for some people, it's much less of a problem than what we have right now - being confused about which window is being shown in the workspace. Here's a better explanation of why we have a problem: 1. Add 4 GtkWindow's to a new project. 2. Select (only select, no double-click) the second item in the Inspector. Now, which widget is being shown in the workspace? There is no indication of this. By looking at the Inspector or editor, the user presumes the second item is being shown, but this is not the case. So then the user gets irritated because she might start editing the wrong widget. I initially reported this bug because Jeff Westerinen thought there was a bug with cut-and-paste. It eventually turned out that this usability problem was misleading him about which window was being shown in the workspace. I have also been confused sometimes about which widget is being shown in the workspace, so I think it's safe to say that a lot of other users will have the same problem.
So why not indicate the name of the toplevel widget that is currently displayed in the workspace ?
Extra clutter, I'd say. If the name is shown in the editor and and selected in the inspector, then that should be enough.
The editor is editing a widget, the workspace is displaying a widget, the project view is displaying a project. There is no rule that the widget being edited is actually the "selected widget" - currently the glade3 frontend does this, but the editor code should not enforce this (the IDE should be allowed to instanciate as many editor objects as they see fit, to edit an arbitrary number of widgets from an arbitrary number of projects at any time).
True, I agree. From a libgladeui perspective there should be as little coupling between the components as possible. In fact, we should actually remove the code in glade-project-view.c that sets the widget in the workspace. We should rather monitor a "selection-changed" signal on GladeProjectView. Nevertheless, we still have an unsolved usability bug here. I am worried that adding labels or other indicators/actions will only serve as a superficial mask on what is, in my opinion, a root design problem. Now - The only true and proper way we can generate consensus on a solution is to do some user testing. So, I propose a test: I create a patch with your label solution, and another patch with my solution, then we get as many people as possible to test the changes. We would then have some sort of feedback upon which we would some proper consensus. cheers
ok, I will try the label solution here. I realised that if we get a docking system into glade we would probably need to label all the docking components anyway. A format for the label, where %s is the toplevel name: "Designer [%s]" Examples: "Designer [dialog1]", "Designer [window4]", etc.
Created attachment 90097 [details] screenshot
Currently selecting any item in the inspector shows the widget in the workspace, closing this one.