This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 174495 - More intuitive way to select containers
Summary: More intuitive way to select containers
Status: NEW
Alias: None
Product: guibuilder
Classification: Unclassified
Component: Code (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker (vote)
Assignee: issues@guibuilder
: 197672 (view as bug list)
Depends on:
Reported: 2009-10-13 22:14 UTC by _ gtzabari
Modified: 2012-12-03 18:55 UTC (History)
1 user (show)

See Also:
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description _ gtzabari 2009-10-13 22:14:53 UTC
If a container's children cover its area completely it becomes impossible to carry out basic operations like dragging it
across the form. Through experimentation I discovered that holding down ALT while clicking on the child component causes
the parent to get selected but this was very from intuitive. Even then, the operation was very clumsy.

We need a more intuitive way to select and interact with parent components. For example, if I select a parent component
in the Inspector tab then clicking on it in the form editor should it retain its selection (allowing me to drag it and
do other things). Right now when I try this the child component gets selected instead.
Comment 1 Jan Stola 2009-10-14 10:02:21 UTC
I agree that the current implementation is quite clumsy in this case. On the other hand, I am not sure how to improve 
it. Your suggestion would simplify the use-case that you describe but it would make other use-cases harder. For 
example, it would be difficult to select a component when its parent is selected. If you have an idea how to keep both 
these use-cases simple then I would be happy to implement it.
Comment 2 _ gtzabari 2009-10-19 15:19:04 UTC
I was thinking of something like this:

- Simple selection: user clicks on component with no overlap, Netbeans selects it
- Complex selection: user clicks on a component with an overlap
\-> If the currently selected component overlaps the area that was clicked, retain the selection and carry out any
subsequent operation such as dragging
\-> If the currently selected component does not overlap with the area that was clicked, select a peer (same-level)
component first, its ancestors next. In other words, given: A contains B and C, B is selected, user clicks on C.
Netbeans would select C before A because it's a same-level component with a common container.

Does that make more sense or should I keep looking for a clearer solution? With the above approach the user only ever
needs to use the "component inspector" when he wishes to explicitly alter his selection "level" (which should be rare).
This assumes that it is more often for a user to operate on a selected or same-level component than it is to operate on
an ancestor.
Comment 3 _ gtzabari 2009-10-29 14:38:32 UTC
(waiting for a reply)
Comment 4 _ gtzabari 2011-04-26 20:04:10 UTC
Here's another possible approach:

When editing components in the GUIBuilder, add an artificial whitespace/border between the container and its children. This whitespace exists purely to facilitate parent vs child selection.
Comment 5 Tomas Pavek 2012-12-03 18:34:24 UTC
*** Bug 197672 has been marked as a duplicate of this bug. ***
Comment 6 Tomas Pavek 2012-12-03 18:41:31 UTC
Here's a way I think this could be handled:
The GUI builder would detect when a container that is fully or almost covered by subcomponents is selected and offer an additional handle, e.g. paint a small square in the middle, which would allow to grab the container and move it without changing selection. The mouse cursor would change on the handle to the four-arrows move cursor.
Comment 7 _ gtzabari 2012-12-03 18:55:54 UTC
I like Thomas' approach as well. Keep in mind what will happen if you have multiple containers (3-4 levels). Will it be usable then? At the very least it should be usable for a single level and users can shift their view to edit elements inside a nested container.