Description: One of the most important values in outliner view, whether in Microsoft Word, WPS Office, or PCOutline in the 1980s, is the ability to move text blocks around independently of the headers. LibreOffice 7.1.0 allows you to move headers, and when you move headers, all children and grandchildren of the header move with the headers. This is useful, but it does not provide the most valuable functionality of outliner view. Steps to Reproduce: 1. Open LibreOffice Writer and create an empty new page. 2. Type some random text for headings 1, 2, and 3. Underneath each heading, type two paragraphs of random text. 3. Test that you can move various headings around using the buttons on the navigator. 4. Highlight or otherwise select one of the text blocks that is not a header. 5. Attempt to move this text block from one heading into another heading. Actual Results: LibreOffice automatically selects the heading under which the child text paragraph resides and moves the heading, along with all of its children up or down. Expected Results: Only the selected paragraph should move, and when it moves, it should become part of a different hierarchy. In other words, I should be able to move text paragraphs from under heading 3 to under heading 1 or 2, and I should also be able to move paragraph 2 under heading 3 from position two to position one under heading 3. Reproducible: Always User Profile Reset: No Additional Info: This behavior has never been part of LibreOffice, so it is not due to problems with my profile or OpenGL. This behavior is vital and absolutely necessary to me as a professional user of word processing programs since the 1980s. I have always used software that has this particular functionality. I cannot use any software that does not.
Sounds like an enhancement request and not a bug. I also think, that this is a new feature and independent from Writer-Outline-View. It is not really clear to me, how you move the selected paragraph through the document. Currently I would cut the text, select a paragraph in the navigator and paste it there. For me this is as convenient and quick as moving the paragraph through the document. cc: Design-Team für further input and decision
I'm going to give you a nonfictional use case that happened multiple times at Fujitsu Software, 1998 through 2000 — two full years. I'm sitting in a developer brainstorming session, writing about ideas that I don't understand using jargon that I don't understand, taking notes in shorthand at break neck speed. Two hours later, I take my 50 pages of notes to my cubicle and I type them into Word — all in text format. To me it's all gibberish at this point. I'm using the MS Word outliner. Once my notes are all typed, I go back to the beginning and create half a dozen blank Heading 5 lines at the top. Then I start to read my lines that I've typed from shorthand. When I notice that several lines of notes are connected, I grab the button at the front of the line, and I drag it up under one of the headings. I write a word or phrase in the Heading 5, and I collapse it. Eventually, all my notes are collapsed inside of Heading 5 titles. I go to the top of the document, and I create empty Heading 4 lines. I'm beginning to understand the document information from the meeting. I read through all of my Heading 5 titles, and when two of them seem related, I drag them up to the empty Heading 4s. When everything is fully organized in this fashion, I'll uncollapse the first section of the document, and using the buttons at the front of the line, I rearranged all the ideas by dragging and dropping them. Sometimes I even take them elsewhere in the document to drop them. At the end of the week or two, I have an Agile document that is useful for both the code architect and each of the members of the team, and they can produce a coherent product from my organized and rewritten notes. Any outliner that doesn't to do this is useless to me. This functionality gives me superpowers, whether I'm writing an Agile document for a team of Java coders, or novel, or a poem, or an article from magazine. I could give you hundreds of nonfictional use cases from my experience alone.
I don't see how (outline!) folding on paragraph level should work neither how to add paragraphs to the Navigator. But If you add an outline on top of your text block (aka paragraph/s) you may use the Navigator with the Promote/Demote Chapter buttons. Adding drag 'n drop per mouse would make this much more convenient. Would that be sufficient for you, Cougar?
(In reply to Heiko Tietze from comment #3) > I don't see how (outline!) folding on paragraph level should work neither > how to add paragraphs to the Navigator. > > But If you add an outline on top of your text block (aka paragraph/s) you > may use the Navigator with the Promote/Demote Chapter buttons. Adding drag > 'n drop per mouse would make this much more convenient. Would that be > sufficient for you, Cougar? No. Not at all. I've been describing my needs as clearly as I can since OpenOffice was started and after the LibreOffice fork. I would like to use open source software, and I would like to be able to recommend it, but I'm frankly tired of trying to describe what I need. I think the use case from Fujitsu Software says it best. (Comment #2) I use the same functionality described there in everything I do. From the beginning, people have tried to tell me that the Navigator is as good as it gets, but it doesn't even begin to satisfy my needs as a long time professional writer.
The Point: These outliner elements are temporary scaffolding using in construction. At the end of construction, most of the scaffolding is taken away. At Fujitsu (the use case in comment #2), I first typed up my notes, mostly as single text lines, no structure. The headers were scaffolding for building the house. When the house was built, I took the scaffolding away. To work this way, the lines of text have to be entirely independent of the headers. The outliner functionality is mostly just scaffolding that exists for the process of construction. Once the construction is done, it is removed. The scaffolding is mostly a construction tool only. A working outliner for me is NOT a presentation tool. It's a construction tool, (though elements are sometimes used in presentation). For fiction, almost all of this scaffolding will be later deleted. The outliner provides temporary containers to enable me to move text into appropriate boxes and then move those boxers into larger boxes. And then I move the larger boxes into crates. After I have completely organized all of the crates, large boxes, small boxes, and smaller containers, then I delete the most of the containers of any size. Only a few of the headers became part of the final document. Here's a link to all four books that I created at Fujitsu. https://drive.google.com/drive/folders/1SLCTR9c_9WxK1Vz70PKVwm5sKx84YvFx?usp=sharing I also included an article in Emmy Awards Magazine that I wrote using this method of work. I use this method for everything. I can't work without professional tools. The outliner is a construction tool, not a presentation tool.
Firstly, I would like to express my gratitude to Mr Raykowski and others who have added outlining features. It's one of the most useful improvements to LibreOffice Writer ever. Secondly, I support this feature enhancement request so that the full power of outlining can be exploited. I sometimes use outlining in the way that Mr Brenneman describes, with the headers as temporary scaffolding. More often, I keep the headers in the final presentation version. But in both cases I want to be able to move body (non-header) paragraphs around quickly and easily as the structure of the argument evolves. It would definitely be a Quality-of-Life improvement if I could just click on something like an anchor point (where the open/collapse button appears for headers) and grab the whole paragraph in order to drag it elsewhere. Dieter's option of selecting, cutting, and pasting text is how I work now (when Ctrl+Alt+Up/Down is not feasible), but it requires more clicks and it's often fiddly. As discussed in bug 38093, this behaviour should only be available in Outline View to avoid confusing users who are not used to outlining.
I support this request. But it could be very useful for others if Cougar created a screencast from Word using this functionality, which would both describe how it looks, and at the same time demonstrate its advantages (using some short text, as if you actually were creating it per comment 2).
(In reply to Mike Kaganski from comment #7) > I support this request. > > But it could be very useful for others if Cougar created a screencast from > Word using this functionality, which would both describe how it looks, and > at the same time demonstrate its advantages (using some short text, as if > you actually were creating it per comment 2). Okay. I don't have screencast software, but I'll demonstrate with a document containing a series of jpgs of screenshots pasted on it. This is going to take me some time, but it will demonstrate it.
Created attachment 163926 [details] unintended attachment Three hours ago, Mike Kaganski asked me to show a screencast of what I'm talking about, and I don't have the software to make a screencast. So I took the first six pages from one of my i-Flow books from 2000, which is in a PDF format, and then pasted those words into MS Word without any format. In the two hours since then, I have created screenshots of how I organized some of those sentences into two pages using Word's outliner. I tried to upload them to Bugzilla, but it wouldn't accept a document with pictures on it, and it wouldn't accept all of the screenshots that i took. So you'll find them on the following web page. That took a little more time to figure out, but they're there now. https://www.joyfulwisdom.org/steps.html THESE ARE NOT A FINAL DRAFT! As writing goes, this is pretty ugly. But what this document does show is how I can use the outliner in Word to begin to re-create the organization of those first six pages of the i-Flow Developers Guide — a book I haven't personally read in 20 years. On each page of the final step-by-step document attached, it shows how I use drag-and-drop on text elements to sort them into headings. I'm trying to think of an OOP way of describing this process, but alas, I don't know OOP well enough. Suffice it to say that what you learned to do in high school when writing an essay is a little bit like procedural coding, and what I've done here is implemented a different paradigm of writing — one which creates a hierarchy of the smallest possible objects and organizes those concrete objects into children of abstract classes or objects which are also children of other abstract classes or objects. Once again, excuse me if this is a poor choice of analogy, but I'm thinking that it may be a little bit like an abstract factory design pattern modified for writing. I'm sorry if that doesn't make sense to OOP programmers out there, but I'm studying OOP right now, and it's the best I can do. I've been using this writing process for 25 years before having any idea what a design pattern is. I'm just trying to use programming concepts that I'm learning about to describe what I'm asking for.
@Heiko, Jim, all: Note also that we are talking about outline *mode*, which might be slightly different conceptually from simply collapsing/expanding that had been implemented yet. The outline *mode*, which includes collapsing/expanding *as part of it*, is a separate mode with a separate workflow, which is illustrated here. Of course, if you focus on just collapse/expand functionality, then this dragging elements around might look "unnecessary" - but then the essence of the different workflow, which is all that Outline mode is about, is destroyed. So please think about Outline *mode* and its distinct workflow again, which is about being able to rearrange elements - which are paragraphs and chapters - freely, like cards on a table. So partly what is asked here is like assigning an outline level to *every* paragraph in the document. And yes, this indeed needs a separate mode, without pages (see tdf#135307), because the focus here is not on layout, but on structure, and trying to layout the structure in this process, with its partially visible data, is misleading.
Note also that having a separate mode for the feature increases its flexibility and UI possibilities greatly, since then you are not limited to "we can't implement this idea, because it will break other workflows of people using normal view".
Not a fan of a special outline mode as this hinders the use case of hiding text in edit mode. But I have to admit that I still don't get it. In particular "Note the large icons for heading 5..." - I don't see a difference. My understanding of outline hiding is that you collapse a chapter. And in order to make this happen with a paragraph you have to add a heading above- quite inconvenient I guess. It also doesn't work to make the paragraph a heading (resp. set an outline level) since collapsing affects the following paragraphs. But maybe we can make this happen and hide the current outline itself if "nothing" follows. Summary is "Move text blocks" which sounds like cut/paste or promote/demote via Navigator. Seems to be a different question - and my comment 3 is still valid for this (allow drag and drop in the Navigator). Of course, it requires the paragraphs to be formatted as outlines.
PS: Of course it would be nice to be able to drag 'n drop collapsed text blocks withing the document, for instance by grabbing the collapse icon and moving it to the new position.
(In reply to Heiko Tietze from comment #12) > Not a fan of a special outline mode as this hinders the use case of hiding > text in edit mode But what is "the use case of hiding text in edit mode"? First, what is "edit mode" in this context? Normal view (with pages) mode? or something? because the outline mode is also "edit mode", with different emphasis and different workflow. And then, what is the need of hiding text in that "edit mode" other than outline mode? By definition, the "Normal View" is designed to show you the document as close to the resulting printed state as possible. Its emphasis is WYSIWYG. It has own "hiding text" means, that are related to actually hiding contents from the end printout (like "hidden" character attribute, or "hidden text"/"hidden paragraph" fields, or "hidden" property of sections). Collapsing text in "Normal" view is exactly "hindering the intended workflow", while in specialized Outline view it is in its place.
Like I said, this is not working to completion. If I hadn't been doing screenshots and struggling with how to get the screenshots visible to you, this would be 90 minutes of work with completely disorganized beginning and a final product that has begun to take all those random bits and put them into order. This is a pattern of work. That's how I constructed the entire book in the first place--by sitting in developer meetings, walking out with 50 pages in shorthand that I didn't even understand. If I had worked to completion, I would have then taken appropriate chunks, reformatted them into paragraphs, made the headers look better for publication, etc. Some of that would have been in FrameMaker. This was simply a demonstration of how I took completely unorganized material and used the features of outline mode to start hammering out a more organized product. It was not an attempt to create a final product, but just a snapshot of my process. It takes only a little tiny bit of imagination to see how I started with pages of incomprehensible phrases and worked it into something that was the pride of the department in the end. All of the developers signed the front page of the books. This is a snapshop of the process so that you can imagine the entire process from shorthand to publication ready. You can see the final form for this book if you go to the link in comment 5. It doesn't look at all like this, but you can see where I ultimately took the process.
You can see their signatures on the sample books. I was required to change my name to my nickname at my next job, where there were four other people named Don in the management team. From that point on, I had to unify my resume with my reference letters.
(In reply to Mike Kaganski from comment #14) > (In reply to Heiko Tietze from comment #12) > > Not a fan of a special outline mode as this hinders the use case of hiding > > text in edit mode > > But what is "the use case of hiding text in edit mode"? First, what is "edit > mode" in this context? Normal view (with pages) mode? or something? because > the outline mode is also "edit mode", with different emphasis and different > workflow. > > And then, what is the need of hiding text in that "edit mode" other than > outline mode? By definition, the "Normal View" is designed to show you the > document as close to the resulting printed state as possible. Its emphasis > is WYSIWYG. It has own "hiding text" means, that are related to actually > hiding contents from the end printout (like "hidden" character attribute, or > "hidden text"/"hidden paragraph" fields, or "hidden" property of sections). > Collapsing text in "Normal" view is exactly "hindering the intended > workflow", while in specialized Outline view it is in its place. Thanks, Mike. You're translating what I'm trying to say into a more technical presentation. I haven't been able to do that. From the beginning of my conversation with this community, way back before 2011 fork, back in 2001 with OpenOffice, I described the specialized Outline view and the workflow it enabled as my "Superpower," because everywhere I went, it provided me with a new way of thinking, a new paradigm of how to write well. I only recently read in "The Object-Oriented Thought Process" book by Matt A. Weisfeld how different paradigms of thinking lead to different results, and until recently, I didn't have enough technical understanding to say that in a way that might appeal to developers. Now I know that this is as radical a change of thinking paradigm as moving from procedural programming to OOP is a radical change in the thinking paradigm. In my earlier comment 2, I described how my notes from a meeting became part of the Agile process of the department. In most programming houses, the technical writer is not an active member of the Agile team, but using this process enabled me to be an active contributor to the Agile process. In many coding houses, technical writing is aligned with post-production and advertising, rather than part of the production process. Using this one superpower, which requires a powerful outline mode, can change everything, from top to bottom, left to right, front to back. This so changed my role in the production process that if you go to chapter 4 in the Developers Guide, you'll find a tutorial that tells developers how to write an adapter for the i-Flow engine using JavaScript. I wrote that entire script, though I had no expertise in programming in JavaScript before getting that job. The outliner mode and the way it changes your thinking process as a writer is so powerful that I continue to think of it as a superpower.
Created attachment 164363 [details] outline tools demo Here is an enhancement patch that enables more outlining tools to be used from the canvas (text shell). Paragraph move up and move down were already available. Please see attached video demo. https://gerrit.libreoffice.org/c/core/+/100831
Via Move Up/Down (ctrl+alt+up/down) I can move paragraphs around. But the bullet and numbering toolbar is not always open, making the feature not easy to understand. Expectation was to hide/collapse chapters, to drag them around, and to have a dedicated "outline mode" rather than outlines in the normal mode. Not sure how to progress, meaning whether to add patches with reference to this ticket or create new tickets (and resolve this as WF/WFM). But UX input has been given, removing the keyword to bring this forward.