Bugzilla

(In reply to Richard Marti (:Paenglab) from comment #58)
> There are a lot of "Tab" mentioned. Shouldn't this be changed to "Space" because this is the Spaces toolbar? So "Replace Current Space", "Open in New Space" etc.

The relation from Space to a Tab is one-to-many, rather than one-to-one. I.e. each Tab can "belong" to up to one Space, and each Space can have between 0 and infinity open Tabs.

@aleca it is too early to know exactly what the spaces toolbar will become, but it might help to expand on the conceptual relation between a Space and a Tab in the documentation.

Based on the existing comments in this bug, I can think of two distinct concepts, which would take us in a different direction.

### 1. Tabs are containers for Spaces

The key concepts would be:

+ The application has one or more Windows, each of which has one or more Tabs.
+ We only display the Tab header if there is more than one Tab.
+ Each Tab can show up to one Space.
+ Clicking a Space on the toolbar switches the Tab to show that Space.
+ You can also open a Space in a new Tab or a new Window.

This would be analogous to the Gnome file browser (sorry, I'm unsure for other platforms), where a Tab shows the content of a Folder (in analogue to showing a Space), and there are key locations (like "Documents", "Pcitures", etc) in the side bar (in analogue to the Spaces toolbar).

I think the advantage of this would be that you don't spawn tabs for every space switch, but you still have the flexibility of having more tabs if you need to do distinct things in each. The disadvantage would be each Tab would probably need some memory for each Space so we could support: switch to "calendar"; change the date; switch to "mail" to verify something; switch back to "calendar" and expect to see the same date. Although, this wouldn't be that different from how we do things now where we "fake" opening certain tabs that are actually already loaded in the DOM: basically each Tab would have its own `#tabpanelcontainer` that contains the current `#mailContent`, `#chatTabPanel`, `#calendarTabPanel`, etc.

### 2. Spaces own Tabs

The key concepts would be:

+ The application has one or more Windows, each of which has one or more Tabs.
+ We can show or hide the Tabs header.
+ Each Space owns zero or more Tabs.
+ Clicking a Space either opens the Space's existing Tab or spawns a new Tab .

This would be analogous to the Gnome application "Dash" / macOS application dock, where clicking an application icon (in analogue to a Space) either takes you to its existing Window (in analogue to switching Tab) or opens a new Window (in analogue to spawning a new Tab).

The advantage is that it is quite similar to how we do things now. The disadvantage is I think a user would *often* still need to use the Tab header, in analogue to needing the actual Window layout instead of the application dock. E.g., if you open more than one mail tab to do distinct things and quickly switch between them, you can in principle do this with the Spaces context menu, but clicking on the tab header can be easier.

In addition, unlike the application dock analogue, not every Tab belongs to a Space. For example, "about:rights" or a PDF attachment opened in Thunderbird. You would either need to see the Tab header or have some way to access these unowned Tabs from the Spaces toolbar. 

Moreover, if you hide the Tab header, and switch between Spaces through normal use, this will spawn Tabs in the background. Currently, a lot of tabs are also restored on re-opening Thunderbird. So if you ever switch to showing the Tab header again, there will be a list of all the accumulated Tabs.

Maybe someone can think of a clever way to address this.

(In reply to Richard Marti (:Paenglab) from comment #58)
> There are a lot of "Tab" mentioned. Shouldn't this be changed to "Space" because this is the Spaces toolbar? So "Replace Current Space", "Open in New Space" etc.

The relation from Space to a Tab is one-to-many, rather than one-to-one. I.e. each Tab can "belong" to up to one Space, and each Space can have between 0 and infinity open Tabs.

@aleca it is too early to know exactly what the spaces toolbar will become, but it might help to expand on the conceptual relation between a Space and a Tab in the documentation.

Based on the existing comments in this bug, I can think of two distinct concepts, which would take us in a different direction.

### 1. Tabs are containers for Spaces

The key concepts would be:

+ The application has one or more Windows, each of which has one or more Tabs.
+ We only display the Tab header if there is more than one Tab.
+ Each Tab can show up to one Space.
+ Clicking a Space on the toolbar switches the Tab to show that Space.
+ You can also open a Space in a new Tab or a new Window.

This would be analogous to the Gnome file browser (sorry, I'm unsure for other platforms), where a Tab shows the content of a Folder (in analogue to showing a Space), and there are key locations (like "Documents", "Pcitures", etc) in the side bar (in analogue to the Spaces toolbar).

I think the advantage of this would be that you don't spawn tabs for every space switch, but you still have the flexibility of having more tabs if you need to do distinct things in each. The disadvantage would be each Tab would probably need some memory for each Space so we could support: switch to "calendar"; change the date; switch to "mail" to verify something; switch back to "calendar" and expect to see the same date. Although, this wouldn't be that different from how we do things now where we "fake" opening certain tabs that are actually already loaded in the DOM: basically each Tab would have its own `#tabpanelcontainer` that contains the current `#mailContent`, `#chatTabPanel`, `#calendarTabPanel`, etc.

### 2. Spaces own Tabs (one Tab header per window)

The key concepts would be:

+ The application has one or more Windows, each of which has one or more Tabs.
+ We can show or hide the Tabs header.
+ Each Space owns zero or more Tabs.
+ Clicking a Space either opens the Space's existing Tab or spawns a new Tab .

This would be analogous to the Gnome application "Dash" / macOS application dock, where clicking an application icon (in analogue to a Space) either takes you to its existing Window (in analogue to switching Tab) or opens a new Window (in analogue to spawning a new Tab).

The advantage is that it is quite similar to how we do things now. The disadvantage is I think a user would *often* still need to use the Tab header, in analogue to needing the actual Window layout instead of the application dock. E.g., if you open more than one mail tab to do distinct things and quickly switch between them, you can in principle do this with the Spaces context menu, but clicking on the tab header can be easier.

In addition, unlike the application dock analogue, not every Tab belongs to a Space. For example, "about:rights" or a PDF attachment opened in Thunderbird. You would either need to see the Tab header or have some way to access these unowned Tabs from the Spaces toolbar. 

Moreover, if you hide the Tab header, and switch between Spaces through normal use, this will spawn Tabs in the background. Currently, a lot of tabs are also restored on re-opening Thunderbird. So if you ever switch to showing the Tab header again, there will be a list of all the accumulated Tabs.

Maybe someone can think of a clever way to address this.

**EDIT**: *Another approach was given to me by @aleca and this seems to have the best of both!*

### 3. Spaces own Tabs (one Tab header per space)

The key concepts would be:

+ The application has one or more Windows, each of which has a full set of Spaces.
+ Each Space has its own Tab header, with one or more Tabs.
+ We only display the Tab header for a Space that has more than one Tab.
+ Clicking a Space button switches to that Space.

This is really neat because it allows each space to handle its own set of tabs, so the Tab header won't mix tabs from different spaces. If you want to switch from a Mail tab to a Calendar tab, you only need to use one of the Calendar button in the spaces toolbar. This approach means you'll hardly need to see the tab header, whilst still being able to have multiple tabs if needed.

This is also quite similar to what we do now: you could almost implement this now by just hiding all the tabs that are not in the current Space. You would still have to make sure that each Tab belongs to a Space.

(In reply to Richard Marti (:Paenglab) from comment #58)
> There are a lot of "Tab" mentioned. Shouldn't this be changed to "Space" because this is the Spaces toolbar? So "Replace Current Space", "Open in New Space" etc.

The relation from Space to a Tab is one-to-many, rather than one-to-one. I.e. each Tab can "belong" to up to one Space, and each Space can have between 0 and infinity open Tabs.

@aleca it is too early to know exactly what the spaces toolbar will become, but it might help to expand on the conceptual relation between a Space and a Tab in the documentation.

Based on the existing comments in this bug, I can think of two distinct concepts, which would take us in a different direction.

### 1. Tabs are containers for Spaces

The key concepts would be:

+ The application has one or more Windows, each of which has one or more Tabs.
+ We only display the Tab header if there is more than one Tab.
+ Each Tab can show up to one Space.
+ Clicking a Space on the toolbar switches the Tab to show that Space.
+ You can also open a Space in a new Tab or a new Window.

This would be analogous to the Gnome file browser (sorry, I'm unsure for other platforms), where a Tab shows the content of a Folder (in analogue to showing a Space), and there are key locations (like "Documents", "Pcitures", etc) in the side bar (in analogue to the Spaces toolbar).

I think the advantage of this would be that you don't spawn tabs for every space switch, but you still have the flexibility of having more tabs if you need to do distinct things in each. The disadvantage would be each Tab would probably need some memory for each Space so we could support: switch to "calendar"; change the date; switch to "mail" to verify something; switch back to "calendar" and expect to see the same date. Although, this wouldn't be that different from how we do things now where we "fake" opening certain tabs that are actually already loaded in the DOM: basically each Tab would have its own `#tabpanelcontainer` that contains the current `#mailContent`, `#chatTabPanel`, `#calendarTabPanel`, etc.

### 2. Spaces own Tabs (one Tab header per Window)

The key concepts would be:

+ The application has one or more Windows, each of which has one or more Tabs.
+ We can show or hide the Tabs header.
+ Each Space owns zero or more Tabs.
+ Clicking a Space either opens the Space's existing Tab or spawns a new Tab .

This would be analogous to the Gnome application "Dash" / macOS application dock, where clicking an application icon (in analogue to a Space) either takes you to its existing Window (in analogue to switching Tab) or opens a new Window (in analogue to spawning a new Tab).

The advantage is that it is quite similar to how we do things now. The disadvantage is I think a user would *often* still need to use the Tab header, in analogue to needing the actual Window layout instead of the application dock. E.g., if you open more than one mail tab to do distinct things and quickly switch between them, you can in principle do this with the Spaces context menu, but clicking on the tab header can be easier.

In addition, unlike the application dock analogue, not every Tab belongs to a Space. For example, "about:rights" or a PDF attachment opened in Thunderbird. You would either need to see the Tab header or have some way to access these unowned Tabs from the Spaces toolbar. 

Moreover, if you hide the Tab header, and switch between Spaces through normal use, this will spawn Tabs in the background. Currently, a lot of tabs are also restored on re-opening Thunderbird. So if you ever switch to showing the Tab header again, there will be a list of all the accumulated Tabs.

Maybe someone can think of a clever way to address this.

## EDIT

*Another approach was given to me by @aleca and this seems to have the best of both!*

### 3. Spaces own Tabs (one Tab header per Space)

The key concepts would be:

+ The application has one or more Windows, each of which has a full set of Spaces.
+ Each Space has its own Tab header, with one or more Tabs.
+ We only display the Tab header for a Space that has more than one Tab.
+ Clicking a Space button switches to that Space.

This is really neat because it allows each space to handle its own set of tabs, so the Tab header won't mix tabs from different spaces. If you want to switch from a Mail tab to a Calendar tab, you only need to use one of the Calendar button in the spaces toolbar. This approach means you'll hardly need to see the tab header, whilst still being able to have multiple tabs if needed.

This is also quite similar to what we do now: you could almost implement this now by just hiding all the tabs that are not in the current Space. You would still have to make sure that each Tab belongs to a Space.