Currently, the objects in the Navigator are listed with the furthest back item at the top and the furthest forward item at the bottom. If you consider the list as a stacking order, a more intuitive listing might show the furthest back item at the bottom and the furthest forward item at the top. The listing I suggest might make it easier for new users to grasp the idea of a stacking order (or back to front listing). Hopefully, more experienced users could quickly understand and adjust to the new listing order.
Confirmed Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 1b463f697405e64a03378fb38a32172c4d3c25e6 CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded IIUC we don't lay down "draw:nav-order" or "draw:z-index" and the order now is as extracted from the ODF on filter import, and as written back still absent nav-order/z-index. Meaning, what is positioned at the bottom of the SB Nav tree is what is described first in the ODF, what is on top of the SB Nav tree is the last described in the ODF. More work is needed as in the see also bug 90244, but would agree that for the default case, absent nav-order or z-index, there would be utility to being able to toggle invert the tree to reflect the stacking/drawing order as loaded from ODF. Don't think we want to change the ODF export save (i.e. with absent z-index), just to provide an ability to invert the treelist @Regina, Jim?
(In reply to V Stuart Foote from comment #1) > IIUC we don't lay down "draw:nav-order" or "draw:z-index" and the order now > is as extracted from the ODF on filter import, and as written back still > absent nav-order/z-index. I'm not sure I understand what you're saying. I mean, in Draw, the order in navigator _does_ correspond to the Z-order, and if you rearrange items, the top one in the Navigator is drawn on top on the page. So, are you saying we're ignoring the Z-order in the input? > Meaning, what is positioned at the bottom of the SB Nav tree is what is > described first in the ODF, what is on top of the SB Nav tree is the last > described in the ODF. Regardless of what the ODF says about their Z index? That's terrible. Perhaps it should be a separate bug though? > the default case, absent nav-order or z-index, That's not the default case, except to the extent there's a bug. Navigator order = Z-index order. A toggle between front-to-back and back-to-front listing order in Navigator sounds like an ok idea, although I can't say I mind that very much, I can personally just scroll.
Confirmed that objects are listed from bottom to top in Navigator in: Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 1b06f35de68a555b85bceb5fc29d1a5f426f4bb7 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: fr-FR (fr_FR.UTF-8); UI: en-US Calc: threaded Setting to new as everyone seems to agree we should be able to see them listed in a more "logical" order, but copying UX team in to see what the best solution could be. I note that the discussion in bug 90244 has to be taken into account, as Stuart mentioned. I wasn't aware the order also corresponds to the tab navigation. And it needs to be tested with several layers too. Not marking as a duplicate because we should have one issue per report, like here.
"Shape 1 (Shape)".."Shape 4 (Shape)" does not resort on changing the z-order but "A".."D" does. Don't see it as a big thing to sort in one more or less random order; as Eyal commented some users might want to sort it ascending some descending. On the other hand not a big deal to add an option and and we could add this to the context menu (z-Order, time or creation, alphabetical order and all up/down come in mind). Think it should be stored, ideally with the document based on a default (user prefers alphabetical sorting but one document should take the arrangement into account).
Created attachment 186868 [details] Demo of option to display objects in Navigator list in back to front or front to back z order This enhancement request prompted revisit to a patch done for bug 145359 which produces incorrect z order. While correcting that bug a possible solution for the enhancement request here developed. Attached is a demo of a two button radio button group added to the Show Shapes drop down menu having buttons 'Front to back' and 'Back to front' used to display shape/group entries in the Navigator objects list in front-to-back or back-to-front z-order.
This "Show Shapes" filter is a good place for the new sorting feature. However, both are not essential and I would prefer having it in a context menu rather than occupying precious space. Kind of unrelated to the patch, I guess. Great work!
Jim Raykowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/a8493ee3d7dac611286a75516f24dd6e451f9718 tdf#154604 SdNavigator: Support listing in front-to-back z order It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Thank you Jim and Don! Verified it works as expected, including with groups, in: Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 002ae41bb6088002ba3ed0188ac822fb823a23f9 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded
In release notes: https://wiki.documentfoundation.org/index.php?title=ReleaseNotes%2F7.6&type=revision&diff=668826&oldid=668804
(In reply to Stéphane Guillou (stragu) from comment #8) > Thank you Jim and Don! > Verified it works as expected, including with groups, in: > > Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community > Build ID: 002ae41bb6088002ba3ed0188ac822fb823a23f9 > CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 > Locale: en-AU (en_AU.UTF-8); UI: en-US > Calc: threaded Nice improvement.