Bug 128172 - When opening a grouped set of object for editing, the rest of the slide is no more grayed out
Summary: When opening a grouped set of object for editing, the rest of the slide is no...
Status: RESOLVED DUPLICATE of bug 122735
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
6.2 all versions
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Regressions-AW080
  Show dependency treegraph
 
Reported: 2019-10-16 08:59 UTC by Andy
Modified: 2021-11-23 15:54 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
A sample doc with a grouped object set and other objects (14.18 KB, application/vnd.oasis.opendocument.presentation)
2019-11-26 00:12 UTC, Andy
Details
LO3.3 display when group is not open (195.92 KB, image/jpeg)
2019-11-26 00:18 UTC, Andy
Details
here object not in the edited group are correctly grayed out (191.97 KB, image/jpeg)
2019-11-26 00:19 UTC, Andy
Details
Here in 6.3.3 objects outside the group never change their appearances (213.03 KB, image/jpeg)
2019-11-26 00:21 UTC, Andy
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andy 2019-10-16 08:59:58 UTC
Description:
In LO, if you a have a grouped object in a slide, you can double click on any part of it to temporarily release the grouping and edit single items in it. This is a very useful function and makes working with grouped objects easy and efficient.
In older versions of LO, when you double clicked on a grouped object, the situation was very clear since all objects not belonging to the group open for editing were grayed out, and by this you could:
- easily understand that you had opened a group object for editing;
- easily check what items belonged to the group and which did not.
Now (I am not sure since what version precisely) the graying out has gone, and every time you open a group object for editing there is actually nothing that tells you this on the screen, nor anything that helps you distinguishing items in the group from those not belonging to it. You must act on a "trial and error" method, and often you are puzzled because things seem to be unresponsive, but it's just because you forgot you have an open grouped object at that moment. Really an annoying regression.

Steps to Reproduce:
1. created an impress doc, put some objects on the slide, and group some of them
2. Now double click on any part of the grouped object, so that the group is open for the editing of single items in it
3. there is no graying out of the other object not in the group, even though they cannot be modified at the moment. You have to constantly remember that you have a grouped object open and what belong to it

Actual Results:
There is no way of distinguishing items in the grouped object when this is open for editing from all other objects in the slide, nor it is easy to see that the grouped object is actually open for internal editing

Expected Results:
As in previous releases, all items in the slide outside the grouped object should be grayed out when the grouped object is open for editing. This a really annoying regression


Reproducible: Always


User Profile Reset: No



Additional Info:
Comment 1 Andy 2019-10-31 12:35:16 UTC
Sorry, I received a notification about this "QA:needsComment" item, but I do not know what that means... should I do something?
Comment 2 Andy 2019-11-14 12:37:23 UTC
I came back to this and saw that nobody reacted to it, not even to my question.... however that glitch is relevant, and I am struggling with it everyday while editing all my lecture Impress presentations.... please help
Comment 3 Xisco Faulí 2019-11-25 15:26:42 UTC
Thank you for reporting the bug. Please attach a sample document, as this makes it easier for us to verify the bug. 
(Please note that the attachment will be public, remove any sensitive information before attaching it. 
See https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help on how to do so.)

I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided.
Comment 4 Andy 2019-11-26 00:12:03 UTC
Created attachment 156108 [details]
A sample doc with a grouped object set and other objects

Here you are. 
If you open this with Libreoffice 3.3 and double click on the gruped object set (the group with the "hello everybody" text included), the group will open for editing single objects in it AND the other two objects in the slide (bottom right) will be grayed out.
Now open the same file with LO6.3.3, and do exactly the same: the bottom right object will NOT gray out when the grouped object is opened for editing its components. It is then much less clear 1) that the group os open for editing and 2) which are the objects included in the group and which are not.
Comment 5 Andy 2019-11-26 00:18:22 UTC
Created attachment 156109 [details]
LO3.3 display when group is not open

To clarify even further, Here is a screenshot of LO3.3 with the above file opened. Here the group object in the higher left of slide is NOT opened, and the the other objects are shown in the same way. in the next screenshot, having double clicked on the group object, the other 2 object are grayed out and is crystal clear to see that there is a temporarily open group being edited and what belongs to it.
Finally in the third screenshot, it is LO6.3.3 now opened, and the objects outside the group do not change the way they are displayed whether the group is opened on not. Difficult to see what is happening here....
Comment 6 Andy 2019-11-26 00:19:31 UTC
Created attachment 156110 [details]
here object not in the edited group are correctly grayed out
Comment 7 Andy 2019-11-26 00:21:01 UTC
Created attachment 156111 [details]
Here in 6.3.3 objects outside the group never change their appearances
Comment 8 QA Administrators 2019-11-26 03:33:12 UTC Comment hidden (obsolete)
Comment 9 Xisco Faulí 2019-11-26 09:34:51 UTC
Regression introduced by:

https://cgit.freedesktop.org/libreoffice/core/commit/?id=52bbb04f1e39b2d778275c91f77b6c0714ecd0d0

author	Armin Le Grand <Armin.Le.Grand@cib.de>	2018-10-31 20:47:49 +0100
committer	Armin Le Grand <Armin.Le.Grand@cib.de>	2018-11-01 10:58:57 +0100
commit 52bbb04f1e39b2d778275c91f77b6c0714ecd0d0 (patch)
tree 6e51e676a95c8147fd5055ebeab78ec36d4dd6cf
parent 88cbc3ea2db8358bbedff01361f95f972f2b0231 (diff)
tdf#120728 support SvxShape for SdrShape if not inserted

Bisected with: bibisect-linux64-6.2

Adding Cc: to Armin Le Grand
Comment 10 Andy 2020-04-14 08:25:28 UTC
Hi, today I received a strange mail regarding this bug, and I really do not understand its meaning:
 Aron Budea changed bug 128172
What 	Removed 	Added
See Also 	  	https://bugs.documentfoundation.org/show_bug.cgi?id=120728 
Could anybody please clarify??
In the mean time, the problem is still there unchanged.
Thanks
Comment 11 Justin L 2021-11-23 11:39:53 UTC
I got a very different result when I used bibisect-linux-64-6.2.
 34b63425ed12b2c68557db3870f1f9c6ad90f1cf is the first bad commit
bibisect commit 34b63425ed12b2c68557db3870f1f9c6ad90f1cf

    source 726d7e7b8b50dca9914329dbfd9491f7c8961f68
    source a28a839b9f9eeec1544c5ceeeabe7b1083ce1655
    source 4b4942224b550235da228655677b5c068a053254

The most likely of the three possible commits is Armin's
    SOSAW080: Derive SdrObjGroup from SdrObjList

https://cgit.freedesktop.org/libreoffice/core/commit/?id=4b4942224b550235da228655677b5c068a053254
Comment 12 Justin L 2021-11-23 15:54:39 UTC

*** This bug has been marked as a duplicate of bug 122735 ***