Bug 144946 - Base: Tabbed Application UI
Summary: Base: Tabbed Application UI
Status: RESOLVED DUPLICATE of bug 33173
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-10-05 15:03 UTC by David
Modified: 2021-10-07 12:24 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David 2021-10-05 15:03:35 UTC
A tabbed Base application would be very beneficial.  Tables, queries, reports, and forms should all open as separate tabs instead of as windows.  It is annoying and causes newbies to lose data when they think the data has been saved on the child window, only to find out that the main window needs to be opened in order to save the data.  MS Office and even Kexi have a much more user friendly approach.
Comment 1 V Stuart Foote 2021-10-05 16:48:22 UTC
smells like bug 33173 but for Base
Comment 2 Heiko Tietze 2021-10-06 07:42:58 UTC
Sounds like a "start from scratch" task.
Comment 3 Gerhard Weydt 2021-10-06 13:40:03 UTC
The problem described only arises when using an embedded database (HSQLDB, Firebird). The database is unpacked when the document is opened, the data reside in the local storage, where all changes are stored immediately. But they are only saved permanently when the document is closed or saved, by zipping the database. (It's not a question of "opening the main window", this must be open, because otherwise no forms ... can be open.) So there's no need to do anything in addition. The only possible problem is a crash before the document is saved/closed, then the changes are lost.
But tabs instead of separate windows would change nothing at this situation.
By the way: forms and reports are sort of separate Writer documents, I think it would be a difficult task, requiring crucial changes in the user interface, to present them in tabs.
Comment 4 Heiko Tietze 2021-10-06 13:46:14 UTC
Following Gerhard's recommendation and resolve this request as WF.
Comment 5 David 2021-10-06 15:58:37 UTC
(In reply to Gerhard Weydt from comment #3)
> The problem described only arises when using an embedded database (HSQLDB,
> Firebird). The database is unpacked when the document is opened, the data
> reside in the local storage, where all changes are stored immediately. But
> they are only saved permanently when the document is closed or saved, by
> zipping the database. (It's not a question of "opening the main window",
> this must be open, because otherwise no forms ... can be open.) So there's
> no need to do anything in addition. The only possible problem is a crash
> before the document is saved/closed, then the changes are lost.
> But tabs instead of separate windows would change nothing at this situation.
> By the way: forms and reports are sort of separate Writer documents, I think
> it would be a difficult task, requiring crucial changes in the user
> interface, to present them in tabs.

Typical elitist programmer response. So the word "opened" was used instead of "show" or "bring to the forefront". A typical user probably won't even think of making that distinction.  Think of what the user might be suggesting instead of defining the words only by programmer-speak and then arguing based on that definition.  If unsure, ask.  So what that an example of use might only happen in an embedded database.  Most users used to MS Office are probably going to use that option instead of taking the trouble of setting up a server.  The point is that so many windows must be dealt with. So what if it's difficult to program.  The market doesn't care. Tabs are generally thought to present a much more usable interface. The clutter created by the multi-window approach is an archaic design and bugs 33173 & 37134 have been open for over a decade, so why just totally shut this idea down?
Comment 6 Heiko Tietze 2021-10-06 17:38:52 UTC
(In reply to David from comment #5)
> The clutter created by the multi-window approach is an archaic design
> and bugs 33173 & 37134 have been open for over a decade, so why just 
> totally shut this idea down?

Very unlikely that we find volunteers who revamp the application from ground. But neither Gerhard (Base user) nor me (UX guy) is a developer and becoming surprised is always nice. Removing UX for now as input has been given.
Comment 7 Gerhard Weydt 2021-10-06 18:57:55 UTC
(In reply to David from comment #5)
It's not elitist to wish to have a problem described clearly. For even if you had said "show" or "bring to the forefront", that would be misleading, because that action does nothing to save the data. If you do not want to wait till the document is closed, you must -save- it. And that is a word every user is used to and will use! And I am not a programmer for LibreOffice, but only a user.
But you totally miss the main point: The difficulty with the embedded database is that the database itself is only saved when the document is closed, or if you explicitly save the document. One might argue about that, but saving the entire database after each change is probably a performance issue.
Using tabs will change nothing regarding this situation.
Comment 8 David 2021-10-06 22:00:18 UTC
The main point I was trying to make was the clutter caused by the archaic multi-windowing that make the program harder to use. 

I'll re-phrase my comment to try avoid the extraneous noise that causes solution oriented people to think that it's just about the one particular example instead of being able to see the bigger picture.

"A tabbed Base application would be very beneficial.  Tables, queries, reports, and forms should all open as separate tabs instead of as windows.  MS Office and even Kexi have a much more user friendly approach."
Comment 9 Gerhard Weydt 2021-10-06 22:23:02 UTC
Not everything that Microsoft introduces is really an advancement, think of the tiles in Windows 8 or the ribbons. What is newer isn't automatically better.
Whether tabs are better than separate windows is stuff for a lengthy discussion. I think that separate windows have the advantage of parallel viewing, which is sometimes useful. But I won't delve deeper into the subject now.
Comment 10 David 2021-10-06 22:42:15 UTC
(In reply to Gerhard Weydt from comment #9)
> Not everything that Microsoft introduces is really an advancement, think of
> the tiles in Windows 8 or the ribbons. What is newer isn't automatically
> better.

I fully agree with that.  I hate ribbons. But I like options. 

> I think that separate windows have the advantage of parallel
> viewing, which is sometimes useful.

Then the tabs should be able to pulled out to make another window. There could also be an option to open in another window instead of another tab in the same window.
Comment 11 V Stuart Foote 2021-10-06 23:53:43 UTC
(In reply to David from comment #10)
> (In reply to Gerhard Weydt from comment #9)
> > Not everything that Microsoft introduces is really an advancement, think of
> > the tiles in Windows 8 or the ribbons. What is newer isn't automatically
> > better.
> 
> I fully agree with that.  I hate ribbons. But I like options. 
> 
> > I think that separate windows have the advantage of parallel
> > viewing, which is sometimes useful.
> 
> Then the tabs should be able to pulled out to make another window. There
> could also be an option to open in another window instead of another tab in
> the same window.


Which makes this a duplicate of bug 33173, along with the dev effort needed for MDI to manage multiple document "tabs" in a single app frame as for bug 33174

The hooks are there (look at the legacy Main Menu -> Windows menu), but the GUI framework requires new cross platform development.

Would need extensive UX design work to scope a new document framework--and a dev/devs with self-interest to implement, or a tender to fund the effort.

Frankly, I don't see that forthcoming from the community nor TDF authoring a funding tender to implement.
Comment 12 V Stuart Foote 2021-10-06 23:54:18 UTC

*** This bug has been marked as a duplicate of bug 33173 ***
Comment 13 David 2021-10-07 07:25:38 UTC
(In reply to V Stuart Foote from comment #11)
> Which makes this a duplicate of bug 33173, along with the dev effort needed
> for MDI to manage multiple document "tabs" in a single app frame as for bug
> 33174

So are you saying that if division/section tabs ever got implemented within Writer that it would then be trivial for them to be implemented in Base?
Comment 14 V Stuart Foote 2021-10-07 12:24:43 UTC
(In reply to David from comment #13)
> (In reply to V Stuart Foote from comment #11)
> > Which makes this a duplicate of bug 33173, along with the dev effort needed
> > for MDI to manage multiple document "tabs" in a single app frame as for bug
> > 33174
> 
> So are you saying that if division/section tabs ever got implemented within
> Writer that it would then be trivial for them to be implemented in Base?

No, nothing trivial about it, but it is a prerequisite as the internal framework for a tabbed UI simply does not exist. Design and development more likely to be driven for Writer than for Base. But LibreOffice is monolithic--modules like Writer or Base are not really independent.  A tabbed MDI, or tabbed per section/panel/frame/page/slide rendering of an ODF document would use the same components.