https://bugs.documentfoundation.org/show_bug.cgi?id=37134
--- Comment #101 from Roland Hughes <[email protected]> --- (In reply to David from comment #100) > (In reply to Sahil Gautam from comment #98) > > How I imagine solving it: > > > > Suppose that the UI side is taken care of, then isn't opening a document in > > a new tab same as clicking on some document from the startcenter (or opening > > a new document), and just showing a box(tab) with it's name type and maybe > > save state. And Closing a tab would be same as clicking on the cross button > > on the top right corner. > > > > And talking about the UI, Notebookbar's "tags" like file, home etc,is the > > closest analog to tabs I see in LIbreoffice's UI, and studying and modifying > > that so as to dynamically create those "tags", but for files, with a cross > > button on the right side, shouldn't be that complicated (maybe). "Would be > > just the perfect bug for me to work on, incremental and challenging" :). > > Since the "Window" menu maintains a list of all the open documents, could > that same code be modified to create a dynamic tabbar? I haven't looked at the code, but it is extremely unlikely. I don't know what cross platform C++ library LO is using, but let us say either Qt or CopperSpice soley for the the sake of conversation. I do this in my RedDiamond editor package on SourceForge which uses CopperSpice (Qt fork). I don't allow multiple instances to be running but I do allow multiple windows. Each window has a group of tabs. (I will upload screen shot so you don't have to read code.) The RDSingleton object creates however many main windows were open last time and the window creation process loads all previously open files and buffers. The "Window" menu item is tracking instances of MainWindow which is derived from QMainWindow. The tabs each contain an instance of EdtEditWidget. To implement even simple first-level tab support like I have in RedDiamond one would need to rip out the "central widget" for the Writer main window and stuff it into a DocumentEditWidget then they would have to put a QTabBar as the only thing in MainWindow below the menu. Instead of directly communicating with whatever that single document object was, the main window class would basically need to be gutted to always connect signals and slots between each DocumentEditWidget. Whenever something was triggered it would need to connect with/operate on the DocumentEditObject in the current visible tab. Actually, now that I think of it you probably want to look at Example2 of my Scintilla fork to CopperSpice. https://sourceforge.net/projects/csscintilla/ Multiple tabs and an incredibly stripped down edit widget. The mainwindow.cpp file is under 500 lines and you really only care about the first 100. If you are on a Debian based Linux distro you can install the .debs for CopperSpice and CsScintilla from the Files section, then unzip the source file and run the script to build the examples so you can see it run. I'm not trying to talk down to you, it sounded like you wanted to learn. Doesn't matter what GUI toolkit they are using, conceptually this is how you have to do it. Kind of shocked when I looked to see they have their own VCL thin wrapper around native stuff. Zinc tried that years ago. I wrote a few books on it. Zinc basically gone. https://en.wikipedia.org/wiki/Zinc_Application_Framework -- You are receiving this mail because: You are the assignee for the bug.
