Issue 128027 - Sort objects by size
Summary: Sort objects by size
Alias: None
Product: Draw
Classification: Application
Component: editing (show other issues)
Version: 4.1.5
Hardware: PC Windows 10
: P5 (lowest) Normal (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Reported: 2019-02-02 05:09 UTC by Mikhail Lewis
Modified: 2019-08-27 19:51 UTC (History)
3 users (show)

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

Example created by Petko (26.86 KB, application/
2019-08-25 20:26 UTC, Peter
no flags Details
Boxes with shared corner sorted by size (4.46 KB, image/png)
2019-08-26 07:21 UTC, Mikhail Lewis
no flags Details
3 arrows: unable to sorted (7.14 KB, image/png)
2019-08-26 10:19 UTC, oooforum (fr)
no flags Details
Squares sorted left to right by size (5.12 KB, image/png)
2019-08-26 23:41 UTC, Mikhail Lewis
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description Mikhail Lewis 2019-02-02 05:09:07 UTC
It would be awesome if OO had the option, presumably within "Modify: Arrange:", to sort a group of objects by size. Sort bigger/smaller objects forward/backward.
Comment 1 Mikhail Lewis 2019-02-02 05:13:22 UTC
Cascade or cascading.
Comment 2 Peter 2019-02-02 14:28:36 UTC
What is size to you? Memory usage, Font height, Length of the text?
Comment 3 Mikhail Lewis 2019-02-13 04:26:58 UTC
Size is a relative relationship between smaller and bigger objects, effects, or affects.

How could I draw memory usage? I could list memory usage by units, using text, and I could draw an abstract representation based on my thoughts about that text...but Draw uses objects, not my thoughts (and thus could not reverse engineer my information or topic from my abstract representation of it).

While one may draw multiple objects with text in them in Draw (though object size is overridden when necessary by increases in font size), if I wanted a sortable spreadsheet of text I would probably use Spreadsheet and not Draw.

The size of objects is commonly measured in length, width, area, depth, volume, and, sometimes, weight.

Presumably memory usage could also be a measure to sort objects by (given an isolated variable such as square width, the larger squares may take up more memory), but I don't see an advantage in a Draw program (especial since width is more intuitive than the presumably increased memory it takes to create/store/record wider objects).
Comment 4 oooforum (fr) 2019-06-26 09:56:15 UTC
>The size of objects is commonly measured in length, width, area, depth, volume, >and, sometimes, weight.
So, I don't understand what is criterias to sort such objects.
If I draw 4 rectangles, 2 squares and 3 circles, how can we sort these?
Comment 5 Mikhail Lewis 2019-06-28 00:56:20 UTC
Imagine if we had three squares, one with a width of 1, one with a width of 2, one with a width of 3 we could use width. The square with a width of 3 is the "big" square. The square with a width of 1 is the "little" square, as it would be if we used area instead of width.
If we had a square and a circle, we could compare the width of the square and the radius or diameter of the circle, or we could compare the area of each. The one with the bigger area would be the "big" object and the one with the smaller area would be the "small" object.
Comment 6 Peter 2019-06-28 06:05:53 UTC
How do we deal with rectangles, cloud objects or other free-form objects. 
Should positions be preserved? Or should we have a layout funkionality. What is if objects overlap by the sort.
Comment 7 oooforum (fr) 2019-06-28 07:24:04 UTC
+1 with comment 6
For me, this ask is too complicated to implement.
Comment 8 Peter 2019-06-28 08:16:41 UTC
I think if we manage to move more into the layout direction it is possible to put it into core.
curre tly I would think of it mor as an extention.
Comment 9 Mikhail Lewis 2019-06-30 23:21:23 UTC
My initial urge was to have objects on top of each other sorted to the front/back, but it is conceivable that one could give the option of sorting objects left to right/right to left, top to bottom/bottom to top, and front to back/back to front.
Comment 10 Mikhail Lewis 2019-06-30 23:23:48 UTC
It should be easier to limit the ability to sort by size to only a single shape, rather than considering the what ifs of different shapes.
Comment 11 Peter 2019-07-01 05:50:39 UTC
Hmm, Maybe it would be better to think of a grafical sorting assistance system.

For example :
You mark objects, in the sidebar you get the objects listed. Then you can select the attribute you want to sort by (position, layer) and the arrange the order as you want it.

We could extend maybe later with a algorithm that can sort.

However i am not sure how difficult this is. There are some issues with unnamed objects and such.
Comment 12 oooforum (fr) 2019-08-21 08:46:02 UTC
(In reply to Mikhail Lewis from comment #9)
> My initial urge was to have objects on top of each other sorted to the
> front/back
Well, I don't understand what you means.
Could you provide a sample document and screenshot for what you expects?
Comment 13 Peter 2019-08-25 16:29:04 UTC
Imagine 3 squares of different length. One is 4 cm, another is 3 cm, and the third is 2 cm. If you want to layer them on top of each other you have to put the large square in the back, put the middle one on top, and the thrid one on top if the last.

The request is that if you do not have produced the squares in the right order. You have a sort button, that sorts the objects by their "length" front to back.
Asdescribed by me the difficulty is that not all objects follow the same meta. So it is hard to define.
Comment 14 oooforum (fr) 2019-08-25 17:29:43 UTC
(In reply to Peter from comment #13)
> Imagine...
I'm lack of imagination so...
>Could you provide a sample document and screenshot for what you expects?
Comment 15 Peter 2019-08-25 20:26:19 UTC
Created attachment 86727 [details]
Example created by Petko

I am also only guessing. But I created a demo file.
With a working example and a wrong wexample and a screenshot where what could be.

I am not saying we can do it like this. Maybe it would be better if we have some layer level mechanism, and you could move objects between those layers.

It is just to demo the concept Idea the OP had.
Comment 16 Peter 2019-08-25 20:34:39 UTC
Maybe related or duplicates
not sure thought
Comment 17 Mikhail Lewis 2019-08-26 07:21:53 UTC
Created attachment 86728 [details]
Boxes with shared corner sorted by size

It can be difficult to picture sorting by size, as larger objects tend to cover smaller objects, sometimes completely. A tool(s) to sort by size could be a good way to find such completely covered smaller objects.
Comment 18 oooforum (fr) 2019-08-26 10:19:51 UTC
Created attachment 86729 [details]
3 arrows: unable to sorted

(re)read comment 6
How can you sort these arrows?
Comment 19 Mikhail Lewis 2019-08-26 23:34:16 UTC
(In reply to oooforum (fr) from comment #18)
> Created attachment 86729 [details]
> 3 arrows: unable to sorted
> (re)read comment 6
> How can you sort these arrows?

One could choose a single arbitrary variable, such as heighth or width of each arrow, the angle of each arrow point, or a more complicated variable such as area. It's simple. How does one determine how to sort the poker cards in one's hand by lowest to highest or highest to lowest value, with the cards overlapping, side by side, or just touching corners?
Comment 20 Mikhail Lewis 2019-08-26 23:41:17 UTC
Created attachment 86730 [details]
Squares sorted left to right by size

One could sort objects by size without layering/overlapping.
Comment 21 Peter 2019-08-27 19:51:49 UTC
I suggest we split this Idea in multiple simpler ones.
1) Arrange multiple objects to each other(currently we can only arrange one Object in relation to everything or one other / a group of objects)
2) Extend the property list of an object by some calculated attributes.
3) find a simple rule engine to define attributes of an object)
4) a simple way to define sorting rules 
5) a sort menu that can execute sorts based on custom defined sorting rules.

I would then close this one with the note to which Incidents we have spitted.
We can draft out those other ones and if needed split them again, until we get issues we can code.

Any more ways to split this? Does this sound like a reasonable step?
(I do not want to make any hopes that we will do it soon thought. It is just something we will more likely revisit at an appropriate point.)