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
I am sorry to reopen this, but I recently realised that the graying out of other objects when a group is opened for editing does NOT work for math editor formulas. The math formula objects in the page/slide stay black, regardless of them being part of the opened group or not. If you do presentations with a lot of algebra, the graying out is then very partial, while it should of course involve ALL objects not in the opened group.
(In reply to Andy from comment #20) Please file another bug for that. You describe something different, which was not OK before Armin's initial commit. It must be handled separately.
(In reply to Mike Kaganski from comment #21) > (In reply to Andy from comment #20) > > Please file another bug for that. You describe something different, which > was not OK before Armin's initial commit. It must be handled separately. I am sorry but I disagree with your comment. When opening a group of objects for editing, ALL other objects on the page/slide should be greyed out, regardless of them being text, shapes, math formulas or anything else. The purpose of the greying out is to make it clear that they are NOT part of the group you are editing in that moment: the fact that some of them are math formulas does not imply any change in interpreting this, so why do you want to consider this separately? Anyway, If this is really your request, and you stand by it, I will gladly file another bug with this same content. Just confirm this, thank you
(In reply to Andy from comment #22) > so why do you want > to consider this separately? Because the report here is about a regression in version 6.2. Before 6.2, the feature never worked as you describe, so what you are asking for is an enhancement request that should be handled separately. > Anyway, If this is really your request, and you stand by it, I will gladly > file another bug with this same content. Just confirm this, thank you I confirm Mike's request: please open a separate report, and add this bug to its "see also" field. Thank you!