Issue 70978 - Specification:Highlighting of selected objects in Drawing Applications
Summary: Specification:Highlighting of selected objects in Drawing Applications
Alias: None
Product: Draw
Classification: Application
Component: ui (show other issues)
Version: OOo 2.0.4
Hardware: All All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Reported: 2006-10-29 14:08 UTC by joergwartenberg
Modified: 2013-02-07 22:42 UTC (History)
1 user (show)

See Also:
Latest Confirmation in: ---
Developer Difficulty: ---

Specification: Highlighting of selected objects in Drawing Applications (58.00 KB, application/vnd.sun.xml.writer)
2006-10-29 14:10 UTC, joergwartenberg
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description joergwartenberg 2006-10-29 14:08:44 UTC
I created this draft of a specification, which shows how the visual feedback for
selected objets in the Drawing Applications could be improved.
Comment 1 joergwartenberg 2006-10-29 14:10:19 UTC
Created attachment 40142 [details]
Specification: Highlighting of selected objects in Drawing Applications
Comment 2 wolframgarten 2006-10-30 07:41:52 UTC
Comment 3 Armin Le Grand 2006-11-09 16:00:05 UTC
Excerpt from mail from concerning this task (subject:
Re: [graphics-dev]   Visual feedback of selected objects in drawing applications)
Adding here because it explains problems with multi-selections which will play a
roll with this task.

Robin Laing wrote:
> I have found that the selection aspect of OOo Draw is not nice.  I 
> select one object and then select a second one and I end up with a box 
> instead of individual objects.  This is what is reported in 70978.  This 
> has been my biggest problem with using OOo Draw.  I just never could put 
> it into words as to what was the problem.
> After reading this thread, I see that this is a common issue.
> Now, I have used different programs that allow WYSIWYG tools for 
> selecting objects and most will display each individual object instead 
> of a block.  Some have a "border" that is part of the object which can 
> be resized or used for wrap around features.  Some of them use animated 
> selection lines.  And the one that I like best will put a dashed line at 
> the border and change the visual colour to the complementary colour.
> As each item is still selected and marked as selected, the total number 
> of selections can be moved and then one or other items can be dropped as 
> needed.
> Using joergwartenberg's example,
> If the yellow square is selected, the border would become dashed. 
> Drag/shape handles would appear and the colour would change to Dark blue 
> with about 50% transparency.  Select the blue triangle and it would 
> change the colour to an off yellow with a 50% transparency and a dashed 
> border.  Now you would have two objects with a complete set of handles 
> for each object.  A total of 12 handles.

Each object has 8 default handles, so it would be 16 here. This shows the visual
problem involved: Too many handles when You show them in a multi selection for
each object. This is one reason OOo does not do that.

> Now the fun part comes if you want to resize the selected objects.  This 
> isn't possible with the one program that I am basing this on.  Now one 
> could use any handle and the actions performed would affect all the 
> objects that are selected.

It is not possible because You cannot decide what the user wants. An example:
We have two objects selected, A and B. Now three scenarios emerge:
(1) The selection is shown in displaying the handles for each object, showing 16
(2) A common selection rectangle is used, showing 8 handles at the bounds of
both obects
(3) 1 and 2 are combined, 24 handles are shown.

With scenario (1) You will be only able to work with single objects, even if
multiple are selected. When trying to apply the same operation to the other
selected objects, unexpected things happen.
Example: A is top left, B is bottom right. Both selected. User graps bottom
right handle of B and starts scaling. The application has the following choices:
- Only scale B
- Apply the same scale to A, A would get scaled but also move to the upper left,
since the relative scaling point would be top left of B -> not expected
- Scale A and B relative to the most top left common handle -> same as scenario
(2), but what to do if the top left of B is picked (or any handle not on the
common bound)? Scale relative to common top left handle? Relative to bottom
right handle of B? Whatever You choose, it's not what the user expects.
There are more possibilities, but all somehow strange. That's why most
applications do not offer that.

Scenario (2) is what OOo users know, with all advantages and disadvantages

The main problem of scenario (3) is that at least two handles exist which
directly cover each other. Somehow it needs to be decided which one is on top.
Whichever is on top, some interactions are not reachable.

But OOo offers a good alternative: You may group Your objects. Interactions on a
group are straightforward. If You want to manipulate a single object of the
group, OOo allows to enter the group (F3or double-click) and interact with the
group content (and only the group content, objects outside are disabled, this is
also visualized). Leave group is CTRL+F3 (or doubleclick outside).

With this methods it is relative smart to work with selections. The trick is to
group selections wisely.

> I hope that this explanation is clearer than mud.  :)

Yes, it is :-) I hope i could make clearer where the problems are. Suggestions
are welcome!
Comment 4 Joe Smith 2009-02-24 16:16:43 UTC
Related issues (dups?):
Issue 98376
Issue 50209