https://bugs.documentfoundation.org/show_bug.cgi?id=37134
--- Comment #127 from Roland Hughes <[email protected]> --- (In reply to golemus from comment #123) > Lack of this feature is and remains largest weakness of LibreOffice if you > ask me. +1 Of course they have to fix performance and memory usage first, especially with large documents having many images. It took 45 minutes to load this book https://www.theminimumyouneedtoknow.com/agile_book.html on my editor's laptop and was taking 5-6 minutes on my desktop with >32GB of RAM. > > > Most logical place (in my layout) is replacement of title bar with tabbed > docs bar. No. Speaking as someone who has been in IT >40 years writing software you cannot mess with the title bar. I don't know of any C/C++ UI library or application framework that will let you do it. Many systems and applications don't put a frame around the mainwindow at all. You physically give up real estate as OnlyOffice does. (see attached image) or you put a Main Menu "Window" menu like WordPerfect does. (see attached image) WordPerfect came up through the blue screen DOS days where it had no menus, just a massive cheat sheet of super secret hot keys. Under DOS you could not have multiple processes anyway . . . not really. No need to get into the TSR discussion here. > > If its hard to implement otherwise, maybe it could be some sort of plugin or > extension...? > What you are overlooking is that LO requires massive re-architecturing. If you look at the source for Examples 5 & 6 here: https://sourceforge.net/p/lscsscintilla/lscsscintilla/ci/default/tree/LsCs_examples/ it will help you understand. You can't just "add tabs" to a monolithic pile of legacy code. Too many developers over too many years. The reason I wanted you to look at those examples is they are small and show the architecture needed. First you have to find all of the "editing" code and put that into a single class/object/module. Anything that would be on the main menu has to communicate via a messaging method. Next you have to put all of the main menu code into a single class/object/module where it doesn't own the instances of the editing class/object/modules, just the tabs that contain them. It's a geek thing. Non-coders won't understand that. Finally, you have to create a Benevolent Overlord class/object/module. This entity holds all global/shared data, anything that needs to be common between the main window and editor instances. It also handles all communication between the instances and main window. It must also own the edit instances because it is responsible for cleaning them up. Now you can have one instance in each tab. I don't care what programming language you are working with, if you try to wedge tabs into a monolithic legacy application it will be a train wreck. For those taking issue with me calling this "legacy code" please not that this bug was opened in 2011 and is still "new." That's 15 years. Next year it will be old enough to drive in America. ***Conversely*** One can hack the WordPerfect approach into legacy code. WordPerfect was originally designed to have no menu at all. Well, you had to call it up. This approach needs an independent service process (not thread) running in background. Gets tricky because you need one per user. It hangs around in perpetuity (usually). Gets tricky because you need one per user. Only thing that changes with your legacy code is, at application startup, your application looks for this process and registers itself. Each instance of your application can communicate with this process to find out how many other instances there are and obtain their PID. WordPerfect allows 10 open documents. Why? Because you can switch between them via either <ctrl> or <alt> (I forget) and a single digit. Under the hood the service process gets sent a message to rotate the PID of the instance containing the document the user wants to look at to the top of the desktop. It's not tabs. Just a poor man's MDI. It takes no additional screen space as long as you have room for yet another menu bar entry. > > Or don't if they are in title bar. > Let me re-iterate. Even if you could find a class library or application framework it would be horrible. Title bars are controlled by the desktop themselves. They provide tweakable things like allowing a program to show/hide the system menu, change the title, and sometimes hide the title bar and application frame, but that's it. There is no common method across Gnome, KDE, XFCE, Windows, Mac, etc. desktops. Why? That's the realm of desktop themes and schemas. > > > > * They add another aspect of complexity to our UI - for users This is a false argument. Mor accurately stated, you don't like tabs. Kids today start out with iMbecile phones and a Web browser with tabs. None of them have even heard of DOS. > > > * They would complicate the implementation of our UI, likely requiring more > > work from developers and whoever does QA for various features - not just > > upfront, but in perpetuity, making sure that UI changes don't break in the > > interaction with tabs. Lot more work up front, but once properly architected, division of duties are clear and they don't collide. > > That is true but if you have learned to work with tab switching e.g. in web > browsers or Windows file explorer, lack of them makes your workflow slower. > This is especially true for new users who don't have the knowledge or skills > for efficient usage of multitasking and switching of windows. This is the reality we face. Kids starting out with iMbecile phones start out with Web browsers. > > > > > Using a browser can be thought of more as an immersive and semi-passive > > experience, at least in the sense of not typing and pressing buttons and > > manipulating controls and such - which is almost the opposite of authoring a > > document. OnlyOffice, Google Docs, Microsoft 365 (or whatever it is called) all have word processors running inside web browsers. They are trying to get everyone keeping everything in "the cloud" to make it easier for AI to mine and (insert nefarious country here) to hack. > > > > This would truly make a killer-feature and > > > hugely improve usability and productivity. > > +1 for tabs +.001 for the WordPerfect approach > > How so? In the 1980s we started out with DOS and one document at a time. Not enough hardware or OS for more. In the 1990s we got GUI-DOS falsely marketed as the Windows Operating System. It was a task switching GUI layered on top of DOS. That gave us the illusion of running multiple things at once. It also gave us tabbed word processors. See the Lotus Symphony attachment. Windows didn't become an OS until NT. WordPerfect clung to its legacy design and began losing market share. For those who weren't around, WordPerfect ruled the land. Microsoft, unable to make quality software, started bundling MS Office with Windows. That's the only reason MS Word became the corporate standard. It was buggy as Hell, but "free" to the corporate mind. Kids today start out with an iMbecile phone. They don't know how to type with anything other than their thumbs. Their browsers have tabs because there is no keyboard with an <alt><tab> combination to switch between applications. They swipe stuff. > > Don't understand either why MS is also behind era in implementing them to > Office. MS has never been able to do quality software. They only needed "enough" for corporate users to muddle through. Once bundled "for free" in the minds of management, it was forced on users. Salaried workers get paid whether they get anything done or not. -- You are receiving this mail because: You are the assignee for the bug.
