Description: I would like to be able identify to which layer an object belong when all layers are visible, so show layer of the object with right button and maybe the option to set border or bg color. I tried to find without luck a workaround based in select all (just a layer visible) a set color [As the layers UX/UI of Draw is too poor, it seems that without noticing i was working on the wrong layer, no w i would like to be able to identify the mess and fix manually] Steps to Reproduce: 1. Create objects in different layers 2. integrate them 3. try to identify layers without setting visible/invisible Actual Results: the layer of an object can't be identified easily Expected Results: identify the layer of an specific object (color, right button) Reproducible: Always User Profile Reset: No Additional Info: Improve the UX, starting by making more intuituve
Select the object using the Navigator. That allows to select the object without entering the group. The layer of the object is shown as text on the left side of the status bar.
In 7.6, we got the "dim objects outside active group" feature back, which helps see which objects belong to one group, before looking at them one by one. Can you please try version 7.6 and test Regina's recommendation? Based on your Actual vs Expected results, my understanding is that you want an option to have an _overview_ of which object belongs to which layer. In 7.6, we got the Style highlighter / spotlight in Writer. This request sounds similar and could use differently-coloured "glows" around objects to have that information at a glance. A few related requests: * Bug 56498 - "Add Layer manager window / Enhance the Navigator". With such an enhancement to the navigator, we could have the same "x-ray / negative" highlight as we have in Writer (when hovering over an object or a category), to easily highlight a whole layer at once. * Bug 77827 - "Draw - Select All on active Layer missing" * Bug 122587 - "Moving Objects to a Different Layer" I think this is a fair enhancement request but that it is blocked by an improved Layer handling UI (like a dedicated sidebar deck or a Layer view in the Navigator). Alternatively, with the current UI, an x-ray / negative highlight on hovering the layer's tab? Copying Jim in too given his recent work on Navigators.
Dapgo, do you agree with having the layer management in the Navigator? It means to make this request a duplicate of bug 56498.
Heiko, I would relate both tickets but without merging them. Because the other ticket has a broader scope and to implement the feature though the bug/enhancement 56498 would imply previous and dependent works. Adding the a color feature to current "layer tabs" can be reused for any future function related to the layer management
[Automated Action] NeedInfo-To-Unconfirmed
I don't like the idea of colorization to identify the parent since colors depend a lot on the system theme. We uses underline, font and background color for the status, which is not clearly related anyway. An alternative might be to an show icon if printable is off, and if locked is on (no icon for the opposite), make the appearance of tab and font disabled in case of visible off, and use bold for the current layer. The active layer would remain "underlined" but not bold anymore.
We discussed the topic in the design meeting. Currently we use italicised font for to show the locked state, underline for non-printing, and blue font color for invisible layers. And a bold bar on the tab for the activ layer. Possible solutions: + a) use just bold for the active layer, disabled font for inactive, and indicate the other states per icon (draw.io uses kind of a Navigator and shows a tiny dot for the object's layer) + drawback is a jumping UI (unless the icons are always visible) and larger tabs + b) use a thin/colored bar to indicate the object's layer + hard to distinguish from the active layer + c) colorize the tab with the highlight color + could use the system highlight color (and invert the blue font of disabled) Option a) sounds to be the best choice from the usability POV (states are currently hard to identify) but means more effort.
(In reply to Heiko Tietze from comment #7) > draw.io uses kind of a Navigator and shows a tiny dot for the object's layer https://www.drawio.com/doc/layers
Created attachment 190794 [details] demo of possible enhancement to identify objects in a layer by mouse hover over layer tab (In reply to Stéphane Guillou (stragu) from comment #2) > Alternatively, with the current UI, an x-ray / negative highlight on > hovering the layer's tab? Maybe like what is shown in the attached demo?
(In reply to Jim Raykowski from comment #9) > Created attachment 190794 [details] > demo of possible enhancement to identify objects in a layer by mouse hover > over layer tab > > (In reply to Stéphane Guillou (stragu) from comment #2) > > Alternatively, with the current UI, an x-ray / negative highlight on > > hovering the layer's tab? > Maybe like what is shown in the attached demo? Looks great, thank you Jim! It think that's a great improvement, please do submit a patch. Dapgo, does Jim's feature + Regina's suggestion in comment 1 cover your original issue?
Link to patch that does what is shown in the demo: https://gerrit.libreoffice.org/c/core/+/159358
Great improvement yet it turns the request around and does not show the layer per object but objects per layer. We should implement it but I wonder if the feature should be optional.
(In reply to Heiko Tietze from comment #12) > Great improvement yet it turns the request around and does not show the > layer per object but objects per layer. Agreed, but I'd like to hear dapgo's opinion on Regina's suggestion, which is in my opinion sufficient. (One related improvement that I think is straight-forward is to show "Several layers" in the status bar instead of whatever single layer it picks when a group that includes objects from several layers is selected. Then the user would know that they need to enter the group to identify which layer each object is linked to.) > We should implement it but I wonder > if the feature should be optional. I have wondered about if the "negative flash" feature used in a few places, if it qualifies as a trigger or hindrance for people with some disabilities (epilepsia, vestibular issues..). Maybe a new "Negative effect to hint at objects" on/off setting in the Accessibility tab of the Options? But for this feature specifically, if it is always on, I guess what matters is the delay in triggering the highlighting, so it doesn't happen every single time the layer is switched. Heiko and Jim, what's a common delay for that?
Created attachment 190824 [details] demo of transparent overlay and mixed layer objects in group statat bar context area message (In reply to Stéphane Guillou (stragu) from comment #13) > Agreed, but I'd like to hear dapgo's opinion on Regina's suggestion, which > is in my opinion sufficient. I agree that Regina's suggestion is enough. > (One related improvement that I think is straight-forward is to show > "Several layers" in the status bar instead of whatever single layer it picks > when a group that includes objects from several layers is selected. Then the > user would know that they need to enter the group to identify which layer > each object is linked to.) Other English language possibilities might be "Mixed layers" or "Different layers". I think the layer shown for group objects in the status bar page status area is the layer that the group object was created in. Maybe too verbose is, "Page n of n (layer name) Group object selected (Contains objects in different layers)" which can be seen in the attached demo. > I have wondered about if the "negative flash" feature used in a few places, > if it qualifies as a trigger or hindrance for people with some disabilities > (epilepsia, vestibular issues..). Maybe a new "Negative effect to hint at > objects" on/off setting in the Accessibility tab of the Options? I prefer a transparent color overlay versus the invert, "Negative effect", overlay. For overlapped areas of objects invert inverts, which, for me, is sort of confusing. This isn't an issue using a transparent color overlay. Probably the main reason to use a negative overlay is that an overlay color doesn't have to be chose. > But for this feature specifically, if it is always on, I guess what matters > is the delay in triggering the highlighting, so it doesn't happen every > single time the layer is switched. Heiko and Jim, what's a common delay for > that? Writer Navigator uses a 1/2 second delay.
(In reply to Jim Raykowski from comment #14) > Created attachment 190824 [details] > demo of transparent overlay and mixed layer objects in group statat bar > context area message > [...] > Other English language possibilities might be "Mixed layers" or "Different > layers". I think the layer shown for group objects in the status bar page > status area is the layer that the group object was created in. Maybe too > verbose is, "Page n of n (layer name) Group object selected (Contains > objects in different layers)" which can be seen in the attached demo. Looks great, thank you! > I prefer a transparent color overlay versus the invert, "Negative effect", > overlay. For overlapped areas of objects invert inverts, which, for me, is > sort of confusing. This isn't an issue using a transparent color overlay. > Probably the main reason to use a negative overlay is that an overlay color > doesn't have to be chose. I think the transparent overlay works well. > Writer Navigator uses a 1/2 second delay. So the same delay sounds sensible. Thanks so much for your work on this, Jim! LGTM, I commented on gerrit. > I agree that Regina's suggestion is enough. So with Regina's tip, and your new features, I think this can be closed when merged.
Hi All, I mistakenly merged the patch for this under tdf#157244.
https://gerrit.libreoffice.org/c/core/+/159358
Verified in: Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 960e37af28807ed1b376e26c4504ab755a81dfd5 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Thanks Jim! Any reason you stuck with the inverted colours instead of the transparent overlay? (I guess the issue with picking a colour, and the rare occurrence of the object being indistinguishable from the overlay, are justification enough...)
(In reply to Stéphane Guillou (stragu) from comment #18) > Any reason you stuck with the inverted colours instead of the transparent > overlay? (I guess the issue with picking a colour, and the rare occurrence > of the object being indistinguishable from the overlay, are justification > enough...) Yes, the issue is what colour to use. I wonder if the theme settings could assign a color for this or perhaps a color for it could be added to the options application colors page.
In release notes: https://wiki.documentfoundation.org/index.php?title=ReleaseNotes%2F24.8&action=historysubmit&type=revision&diff=748531&oldid=748339
This just happened to me, without warning on a complex Draw diagram with many thousands of objects: On a slower WAN remote display, it was 48 seconds of everything being "frozen", then the highlighting was shown, then another 38 seconds for the screen to return to normal. On the same complex document with a fast LAN remote display, it froze for about 5 seconds. Even on a fast workstation (non-remote) it would freeze for 4 seconds. There is no feedback to the user what is happening when these freezes happen. I had to perform research to figure out what was happening (that it was my cursor resting on the tab activating this new feature). There is apparently no way to turn this off or control this new feature... Now when one has a slow remote display or a document with tens of thousands of objects, accidentally placing the cursor on a tab can "lock up" the "machine" for extremely long times as it tries to manipulate thousands of objects on the screen. Don't get me wrong- this layer object identify is a great feature that many will surely appreciate. But I strongly recommend a way to mitigate the possible negative effects for some use-cases. Here is my suggestion: 1) Add a tooltip on tab hover that tells the user when the feature is triggered. This is useful not only for delays, but even to let the user know why lots of objects are suddenly black. Perhaps saying "Objects on this layer highlighted". 2) A setting and/or Expert Configuration that accepts a number of objects before the feature is suppressed. For example, "2000" would prevent activation if there are more than 2000 objects either on that layer. "0" would then disable the feature completely. Default it to something reasonable, or something large, like "99999" (which could deactivate auto disable). 3) A tooltip on tab hover that appears if the feature is automatically being suppressed. Perhaps saying something like "Object highlighting disabled" or similar. Thanks
Here is a link to a patch that makes the overlay not happen when there are more than 100 objects in a layer: https://gerrit.libreoffice.org/c/core/+/176809 Waiting on further input to see how user configurable this should be.
How about a timer that checks how long the operation takes and stops it at 100ms or so. Proposed the same solution on bug 163571 comment 2.
(In reply to Heiko Tietze from comment #23) > How about a timer that checks how long the operation takes and stops it at > 100ms or so. I am afraid that might not solve all cases. In the case of the display being remote, most of the delay will be network and object passing between the Xclient and Xserver. Basing it on the number of objects will be more reliable. > Proposed the same solution on bug 163571 comment 2. I will check that out too, to see how it affects our various environments.
PS2 adds DisableLayerObjectsOverlay expert setting (org.openoffice.Draw > Misc > DisableLayerObjectsOverlay) to allow the overlay to not be done when the value set for DisableLayerObjectsOverlay is less than the number of objects in the layer of the tab which the mouse is hovered over in the layer bar. I had the same idea of using a timer as Heiko. I did a bit of digging into that approach before concluding that it would take more knowledge than I have. Personally, I'm for a simple true false setting to either enable or disable the feature.
(In reply to Jim Raykowski from comment #25) > PS2 adds DisableLayerObjectsOverlay expert setting (org.openoffice.Draw > > Misc > DisableLayerObjectsOverlay) to allow the overlay to not be done when > the value set for DisableLayerObjectsOverlay is less than the number of > objects in the layer of the tab which the mouse is hovered over in the layer > bar. Sounds like a winner to me. > I had the same idea of using a timer as Heiko. I did a bit of digging into > that approach before concluding that it would take more knowledge than I > have. I like that it might be more "automatic", but the issue I have with that approach is I don't think it can account for all the possibly delays. LO running on a fast server might be able to zoom through it immediately but a slow display is forced to still wait through all the network and display lag. I am not sure it is synchronous. > Personally, I'm for a simple true false setting to either enable or disable > the feature. I will take whatever we can get to production versions to offer a solution as quickly as possible. Then maybe it can be further improved later. The nice thing about using a number of objects limit is that even though the new feature can cause problems for some people with huge documents, it would still be useful for less-complex documents for those same people. So it would be a shame if it were only a binary choice (completely on or completely off). Thanks
Created attachment 197716 [details] demonstration of DisableLayerObjectsOverlay setting (In reply to crxssi from comment #26) > The nice thing about using a number of objects limit is that even though the > new feature can cause problems for some people with huge documents, it would > still be useful for less-complex documents for those same people. So it > would be a shame if it were only a binary choice (completely on or > completely off). Your argument makes good sense to me. Do you see any changes to improve what is shown in the attached demo? Perhaps to the setting name or setting description text or tooltip text.
(In reply to Jim Raykowski from comment #27) > Created attachment 197716 [details] > demonstration of DisableLayerObjectsOverlay setting > > (In reply to crxssi from comment #26) > > The nice thing about using a number of objects limit is that even though the > > new feature can cause problems for some people with huge documents, it would > > still be useful for less-complex documents for those same people. So it > > would be a shame if it were only a binary choice (completely on or > > completely off). > Your argument makes good sense to me. Do you see any changes to improve what > is shown in the attached demo? Perhaps to the setting name or setting > description text or tooltip text. Actually, what you did is really quite good. I like it a lot! Whatever you call the variable or word the description, it is likely people not know what it means :) I probably would call it "highlighting" rather than "overlay effect", only because it might be better understood ("highlighting" is to point something out, but I haven't seen/heard of "overlay effect" before). So the remaining question would be- what to set the default for that variable that would be most appropriate and helpful for the most people? I know that my test with a remote connection had problems with even 400 objects. Would 100 be a reasonable default?
(In reply to crxssi from comment #28) > Actually, what you did is really quite good. I like it a lot! Whatever you > call the variable or word the description, it is likely people not know what > it means :) I probably would call it "highlighting" rather than "overlay > effect", only because it might be better understood ("highlighting" is to > point something out, but I haven't seen/heard of "overlay effect" before). "overlay" is the term used in the code. How about: Variable name - "DisableLayerHighlighting" Variable description - "Defines the maximum number of objects in a layer (0 - 65535) before hovering the mouse pointer over a layer tab of the layer bar does not cause the layer objects in the view to be highlighted." Tooltip - "Layer highlighting is disabled for this layer. The number of layer objects exceeds the number set for DisableLayerHighlighting (value)." > So the remaining question would be- what to set the default for that > variable that would be most appropriate and helpful for the most people? I > know that my test with a remote connection had problems with even 400 > objects. Would 100 be a reasonable default? I tested up to 6480 objects without any noticeable layer highlighting delay. Had lots of messages from the operation system asking if I wanted to wait or force close when selecting and copying objects. The computer I tested with is not speedy. The maximum effective value for "DisableLayerHighlighting" is 65535. Maybe a large number like this would make sense to use as the default?
(In reply to Jim Raykowski from comment #29) > "DisableLayerHighlighting" > > Variable description - [...] That sounds a lot more descriptive, at least to me. > I tested up to 6480 objects without any noticeable layer highlighting delay. I haven't tested it on a local machine yet, only remote (where LO and the Xserver are separated by a network... at work, everything is remote display; at home I am using Mint 21 so it is just LO 24.2.7.2). So I am not sure there will be much delay in those cases. Your data helps to confirm that maybe the fix doesn't need to be aggressive... > Had lots of messages from the operation system asking if I wanted to wait or > force close when selecting and copying objects. The computer I tested with > is not speedy. The maximum effective value for "DisableLayerHighlighting" is > 65535. Maybe a large number like this would make sense to use as the default? Probably. My use case (which does involve a few hundred users) is unusual. Unlike my case, 99+% of typical users will be using LO while running and displaying on a local machine. So you are right, it would be best to make the number large. Of course, typical Draw documents are probably not going to have thousands of objects, anyway. But, not all objects are equal- some can be hundreds of times more complex to render than others. Still, a large number for the variable default seems reasonable to me. At least the user can change it to suit their needs, if it becomes necessary.... which is the beauty of this type of fix.
Jim Raykowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/662c6a6d70bab6b1a6ae8048457907be97f447ca related tdf#157255: add DisableLayerHighlighting expert setting It will be available in 25.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.