Description: It's rather hard to detect being inside a grouping after entering one. Even harder if you aren't aware a grouping is present (3D objects). And press ESC doesn't help in that case Steps to Reproduce: 1. Open Draw 2. Insert a 3D object (say Cube) 3. Rotate the cube (double clicking it & drag) 4. Click on the empty page -> Object deselected, still in grouping mode Actual Results: Not aware of being inside a grouping Expected Results: The grouping should be a little more prominent * Add the Leave grouping button to the toolbar (minimum) * Some sort visual indication? Frame border/Info Bar/ frame around the page.. or anything else which makes it clear Reproducible: Always User Profile Reset: No Additional Info: Version: 6.3.0.0.alpha0+ Build ID: 61778fd20395794d2de3b52d60dcc65083aecd93 CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; Locale: nl-NL (nl_NL); UI-Language: en-US Calc: CL
I guess the only way to know it now is with the content menu, checking if it's says, Enter Group or Exit Group... UX Team, what's your opinion ?
What's the problem with knot knowing if you are in a group? Maybe the 3D cube is a bad example: two grouped shapes should display their relation when you enter. This is achieved with the Navigator that takes the hierarchy. => WFM A super-cool solution would be to gray out objects that are not in the current group. But I guess that's a lot of work for not much benefit.
Created attachment 151600 [details] Group and single shape for testing The attached document has a single shape 'star' and a group containing 'smiley' and 'diamond'. Double-click the smiley. Expected behavior: The star becomes pale, only shapes inside the group are shown normally. Same for 3D-Scenes, shapes outside the scene need to become pale, when you enter the scene. That had worked in Version: 6.0.7.3 (x64) Build ID: dc89aa7a9eabfd848af146d5086077aeed2ae4a5 CPU threads: 8; OS: Windows 10.0; UI render: default; Locale: de-DE (en_US); Calc: CL It is broken at least since Version: 6.1.4.2 (x64) Build-ID: 9d0f32d1f0b509096fd65e0d4bec26ddd1938fd3 CPU-Threads: 8; BS: Windows 10.0; UI-Render: Standard; Gebietsschema: de-DE (en_US); Calc: CL So this is not an 'enhancement' but a true bug. Heiko: If you do not know, that you are inside a group, you have no clue, why an object is not selectable. Try to select the star by clicking on it, after you have double-clicked the smiley. A 3D-scene has the additional problem, that users often not even know, that a 3D-scene always acts as group, even if it only contains one objects.
Regression introduced by: https://cgit.freedesktop.org/libreoffice/core/commit/?id=726d7e7b8b50dca9914329dbfd9491f7c8961f68 author Armin Le Grand <Armin.Le.Grand@cib.de> 2018-05-25 12:58:10 +0200 committer Armin Le Grand <Armin.Le.Grand@cib.de> 2018-05-25 12:59:48 +0200 commit 726d7e7b8b50dca9914329dbfd9491f7c8961f68 (patch) tree aba7b05720e84dc38dabe93f6a51825326c2a7be parent a28a839b9f9eeec1544c5ceeeabe7b1083ce1655 (diff) tdf#117629: Remove again after next step of SOSAW080 is done Bisected with: bibisect-linux64-6.2 Adding Cc: to Armin Le Grand
*** Bug 132507 has been marked as a duplicate of this bug. ***
*** Bug 136882 has been marked as a duplicate of this bug. ***
*** Bug 128172 has been marked as a duplicate of this bug. ***
*** Bug 117562 has been marked as a duplicate of this bug. ***
I doubt that this is related to the commit, I suggest more that this was somehow introduced with the work for new UI/Toolbar stuff, but I have to take a look to clarify
(In reply to Armin Le Grand from comment #9) > I doubt that this is related to the commit, I suggest more that this was > somehow introduced with the work for new UI/Toolbar stuff, but I have to > take a look to clarify Checked linux-6.2 bibisect repo, indeed the change happened in a range (as bibisected by Xisco, but that bibisect commit contains more than one source changes): https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=f8edef392245c292398a80f6a858ca19f32df9c3..726d7e7b8b50dca9914329dbfd9491f7c8961f68 Before this clicking the smiley in attachment 151600 [details] and selecting Enter Group from context menu made the non-grouped star object pale. More likely commit in range looks to be: author Armin Le Grand <Armin.Le.Grand@cib.de> 2018-04-16 22:34:50 +0200 committer Armin Le Grand <Armin.Le.Grand@cib.de> 2018-05-25 12:31:32 +0200 commit 4b4942224b550235da228655677b5c068a053254 (patch SOSAW080: Derive SdrObjGroup from SdrObjList
(In reply to Armin Le Grand from comment #9) So indeed this is not the commit mentioned in the comment 4; however, the identified commit range consists only of three commits, and the relevant one is Commit 4b4942224b550235da228655677b5c068a053254 Author Armin Le Grand <Armin.Le.Grand@cib.de> Date Mon Apr 16 22:34:50 2018 +0200 SOSAW080: Derive SdrObjGroup from SdrObjList Unfortunately, it is huge, and that doesn't allow me to see the problem reading the code. The "pale" painting is implemented using these things: * ObjectContact::DoVisualizeEnteredGroup (virtual, returns true in ObjectContactOfPageView); * DisplayInfo::SetGhostedDrawMode / DisplayInfo::ClearGhostedDrawMode / DisplayInfo::IsGhostedDrawModeActive * ViewObjectContact::isPrimitiveGhosted (virtual) * ObjectContactOfPageView::DoProcessDisplay * ViewObjectContactOfE3dScene::createPrimitive2DSequence * ViewObjectContactOfSdrPage::getPrimitive2DSequenceHierarchy ... etc. Making SetGhostedDrawMode do nothing makes everything pale, so the code is still there, and is functional. However, the SetGhostedDrawMode/ClearGhostedDrawMode pairs look to now be somewhat misplaced - the ghosted draw does not happen between them, only when it's disabled. Luckily, Armin is the most knowledgeable one in the area, who worked on https://bz.apache.org/ooo/show_bug.cgi?id=29129, so hopefully can fix this.
*** Bug 154159 has been marked as a duplicate of this bug. ***
This is not just Draw/Impress. It used to also work in e.g. Writer (tested in version 6.0). Changing the summary for better discoverability, and relevant meta.
Armin Le Grand (allotropia) committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/2dde0bf99ed11feb32d361303bb15fbd6d33ec0e tdf#122735 get the correct ActiveViewContact It will be available in 24.2.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.
Found & fixed.
> > It will be available in 24.2.0. I am sorry to bother.... but isn't Libreoffice now at rel 7.6? What kind of numbering is this 24.2.0? Perhaps some internal number for developers I am not aware of? Thanks
(In reply to Andy from comment #16) > I am sorry to bother.... but isn't Libreoffice now at rel 7.6? > What kind of numbering is this 24.2.0? This is the new calendar-based numbering scheme (year.month) that we will start using with the major release after 7.6. 7.6 this august, 24.2 in February 2024.
Armin Le Grand (allotropia) committed a patch related to this issue. It has been pushed to "libreoffice-7-6": https://git.libreoffice.org/core/commit/4d4fa2f3f131631f97d49883a4983f90611429b2 tdf#122735 get the correct ActiveViewContact It will be available in 7.6.0.0.beta2. 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.
Fix verified for both Draw and Writer in: Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 77fca616e0bd79e0b405fd0b3543cf8e94e15df3 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Much appreciated, Armin! Great to have that feature back. I thought it worth mentioning in the release notes: https://wiki.documentfoundation.org/index.php?title=ReleaseNotes%2F7.6&type=revision&diff=677572&oldid=677216