Description: When you're viewing-and-editing, or proof-reading, a document - in its final laid out form - there are sometimes part of the text which are only potentially useful/interesting. A concrete example: A long(ish) segment of source code within a section of text; or a quote; or a large image; or even a footnote that kind of drags on. These are not subsections, or other subtrees in the structural hierarchy tree - just arbitrary objects or elements (but not merely stretches of text). I would like to be able to mark such elements (using their properties page if they have it, or in some other way) in a way which would make them collapsible: Make them have to modes of presentation. The tiny mode may either be auto-generated-only (e.g. first line of content, or icon version of line image), or it may even allow for a collapsed/short version and a complete/long version. A +/- or arrow indicator - similar or dissimilar to whatever exists in layout mode, doesn't quite matter - would allow switching between the forms; as well as, perhaps, a double-click. The indicator would not be visible always, but only when you hover over the item or some part of it (although perhaps a preference would control this). Steps to Reproduce: N/A Actual Results: N/A Expected Results: N/A Reproducible: Always User Profile Reset: No Additional Info: Despite the visual similarity, this is _not_ a request for outline mode (bug 38093) - and this feature would be basically irrelevant in outline mode. When printing, a preference would control the behavior of coallpsible items. There could be UI for collapsing/expanding all such items. This would be particularly useful for items which are large enough to exceed the page boundary, but which one would still like to see not-split-up on screen.
Is the new outline mode a viable solution for you? For example advertised here http://libreoffice-dev.blogspot.com/2020/08/a-new-writer-outline-folding-mode-in.html and requested in bug 38093.
(In reply to Heiko Tietze from comment #1) > Is the new outline mode a viable solution for you? No, for the following reasons: * That requires the user to change their LO settings to enable, then change them back. It is not something inherent in the document. * It makes a huge number of things collapsible which should not be. * It doesn't necessarily make what I want to make collapsible, collapsible. * It typically confuses the user by terminology and UI elements having to do with outline mode and levels, when all I want is for the user to be able to collapse and expand some specific element(s) of my choice. However, the implementation itself may be possibly be useful in also implementing the feature I suggest.
(In reply to Eyal Rozenberg from comment #2) > * That requires the user to change their LO settings to enable, then change > them back. It is not something inherent in the document. You have to enable the mode in Tools > Options, sure. We can discuss this. > * It makes a huge number of things collapsible which should not be. It enables the mode meaning you get the icon on hover and collapse a chapter on click. > * It doesn't necessarily make what I want to make collapsible, collapsible. What's collapsed is your choice. > * It typically confuses the user by terminology and UI elements having to do > with outline mode and levels, when all I want is for the user to be able to > collapse and expand some specific element(s) of my choice. Don't see "collapsible elements in normal view" as simpler. Please take a look again on the new feature, it's more or less exactly what you are looking for.
(In reply to Heiko Tietze from comment #3) Heiko, you're not getting what I'm saying. That other bug is a completely different feature. It is about the _user_ enabling the collapsing by structural elements. This about _authors_ introducing collapsible elements, in the default, non-outline-view, of documents. > What's collapsed is your choice. Exactly - that's not what this feature is about. Also, that's impossible, i.e. you can't say (and should be able to say): In document 1, frame 1 should be collapsible and frames 2,3 shouldn't, while in document 2, frame 2 should be collapsible but frames 1,3 shouldn't. > Don't see "collapsible elements in normal view" as simpler. Because you're thinking about the user choosing what elements are collapsible.
(In reply to Eyal Rozenberg from comment #4) > This about _authors_ introducing collapsible elements, in the default, > non-outline-view, of documents. So you speak about hidden text? https://help.libreoffice.org/7.1/en-US/text/swriter/guide/hidden_text.html
(In reply to Heiko Tietze from comment #5) > So you speak about hidden text? > https://help.libreoffice.org/7.1/en-US/text/swriter/guide/hidden_text.html No. A collapsed element would not be hidden. The collapsed state might look like, say: +------------------------------+ | [ > ] (What Cicero said) | +------------------------------+ and when you press the expansion widget, it might become: +------------------------------+ | [ v ] "Lorem ipsum dolor sit | | amet, consectetur adipiscing | | elit, sed do eiusmod tempor | | incididunt ut labore et | | dolore magna aliqua." | +------------------------------+ with the expansion widget always visible. So not like hidden text at all. (But I'm not saying this should necessarily be unavailable for inline use; I just assume it will be more important for block'ish elements).
I don't think that itwould be a good solution to have some collapsing elements in normal view and other collapsing elements in outline view. This will be absolute confusing. So I think, that we might discuss improvements of outline view, but I still don't see the need, why this must be part of normal view.
(In reply to Dieter from comment #7) > I don't think that itwould be a good solution to have some collapsing > elements in normal view and other collapsing elements in outline view. So, are you in favor of removing the ability to insert listboxes? Those are collapsing elements in normal view while other elements are collapsing in outline view. No, what I'm suggesting is a feature that's unrelated to outline view; it's not intended for the same purpose; and there is no partition of what's collapsible in outline view and outside of it. Just forget about outline view here - the users who will see a document with some collapsible elements will not be thinking about outline view, just like the users who see list-boxes. I found an example for you guys in a W3C tutorial: https://www.w3schools.com/howto/howto_js_collapsible.asp this is something you can do relatively simply in HTML documents. It would be useful to support it in Writer documents intended for on-screen use.
(In reply to Eyal Rozenberg from comment #8) > So, are you in favor of removing the ability to insert listboxes? Those are > collapsing elements in normal view while other elements are collapsing in > outline view. No, I don't know this ability. Is it possible to add a sample document?
(In reply to Dieter from comment #9) > (In reply to Eyal Rozenberg from comment #8) > > So, are you in favor of removing the ability to insert listboxes? Those are > > collapsing elements in normal view while other elements are collapsing in > > outline view. > > No, I don't know this ability. Is it possible to add a sample document? 1. Create a new Writer document. 2. On the menus, choose Form > List Box. 3. Draw a rectangle. 4. (this is complicated, don't do this) find an appropriate database to use for a data source. Even without doing (4.), you will see the down-arrow for the list box. It is in a collapsed state. When you click it (and if you have elements in the data source), it will expand downwards - just like any listbox, e.g. the bug status listbox on this web page.
(In reply to Eyal Rozenberg from comment #10) > 1. Create a new Writer document. > 2. On the menus, choose Form > List Box. > 3. Draw a rectangle. > 4. (this is complicated, don't do this) find an appropriate database to use > for a data source. > > Even without doing (4.), you will see the down-arrow for the list box. Sorry, I can't see it. But it seems to me, that you can't compare this with images, a footnote or something like that, because the option to collapse a list box might be part of the basic functionality of a list box (but not for images and other objects). So I think my comment 7 is still valid. But let's decide design-team.
> Sorry, I can't see it. It's strange that a user needs to tell a member of the design team about this feature, but ok... here's an explanation about forms in Writer: https://codepre.com/how-to-use-libreoffice-writer-to-create-fillable-pdf-forms.html and here are specific screenshots: * Expanded: https://static.codepre.com/uploads/1585918136.png * Collapsed: https://static.codepre.com/uploads/1585918140.png > But it seems to me, that you can't compare this with > images, a footnote or something like that, because the option to collapse a > list box might be part of the basic functionality of a list box (but not for > images and other objects). No, collapsibility isn't part of the basic functionality. See: https://en.wikipedia.org/wiki/List_box a list box may be collapsible, or non-collapsible and scrollable. That said, and adopting your distinction - this feature could be introduced via a singular kind of collapsible element, which could contain other elements, rather by the ability to make _anything_ collapsible.
(In reply to Eyal Rozenberg from comment #12) > > Sorry, I can't see it. > > It's strange that a user needs to tell a member of the design team about > this feature, but ok... here's an explanation about forms in Writer: I'm not a member of he design team, but just a user who tries to help, as everybody can do.
We discussed this topic in the design meeting and do not see need for a special solution on a paragraph level beyond the outline visibility feature.
(In reply to Heiko Tietze from comment #14) With respect, Heiko - it seems from your description of that meeting that what you discussed is a continued misunderstanding of this feature request. This is not about a specialization or extension of outline visibility toggles. But I don't believe I can do more than give the examples I have for illustrating what's requested.
Heiko, any further input from your side or should we close it as WONTFIX or ...? => NEEDINFO
(In reply to Dieter from comment #16) > Heiko, any further input from your side or should we close it as WONTFIX or > ...? Dieter, with respect - have you not read my explanation why this is not related to outline view?
(In reply to Eyal Rozenberg from comment #17) > Dieter, with respect - have you not read my explanation why this is not > related to outline view? There was no further comment for almost one year, so my question to Heiko was, if you comment 15 changes his opinion or not.
Let's keep it (or make a duplicate). There is bug 135373 and bug 135307 discussing the same idea (still outline mode). The desire of paragraph folding sounds to me like abusing Writer as IDE but there are strong arguments against my view. But adding another path to collapse paragraphs (Eyal dislikes the outline mode) is definitely way too much. We can hide paragraphs and this could be a workaround (by switching styles).
Heiko: This feature request is much more about comment 5 (although use of hidden text needs substantial work), than about your continued reference to outline folding. Outline folding feature is about means to help author to manage structure of developed document. It should not affect e.g. what end user will see, or print, in normal mode. This is about inserting things like those "Click to see spoiler" things on forums, where the temporarily hidden text is the intended dynamic part of the document. I disagree that this is a good thing to introduce into Writer, because Writer documents are not HTML, and are not intended to be highly dynamic. Comparison with combo box is incorrect, since combo boxes do *not* modify the layout (position of following text on pages), while this feature would require such re-layout for the collapsed/expanded states (by the way, this is one of the reasons I still consider current implementation of outline folding feature broken). IMO: if required, having a variable field, and a hidden text that depends on the variable, is enough approximation for text processor which Writer is.
(In reply to Mike Kaganski from comment #20) > IMO: if required, having a variable field, and a hidden text that depends on > the variable, is enough approximation for text processor which Writer is. Note that implementing bug 130198 would enable to use a drop-down to control the hidden text, making it ~perfect implementation for the feature proposed here.