View Issue Details

IDProjectCategoryView StatusLast Update
0018562MMW 5Main Panelpublic2023-10-18 16:56
Reporterjiri Assigned To 
PriorityhighSeverityminorReproducibilityalways
Status resolvedResolutionno change required 
Product Version5.0.2 
Target Version5.1Fixed in Version5.0.3 
Summary0018562: Tabs don't share the same layout
DescriptionCurrently when layout of the main window is changed, the change is applied only to the active tab, but all other tabs remain unchanged. This results on all kinds of weirdness:

1. YouTube playback unexpectedly stops:
  a. Have 2 tabs open without the Preview window
  b. Start Youtube playback => Preview window is shown with the video content.
  c. Switch to another tab => Preview window disappears and playback stops!

2. Strange temporary changes:
 a. Have 2 tabs open without the Preview window.
 b. Enabled the Preview window on tab 1.
 c. Switch to tab 2 => Preview isn't shown.
 d. Open Layout Configuration => Preview _is_ shown.
 e. Cancel Layout Configuration => Preview is _not_ shown.

There's probably more similar issues. After discussion with the devs, it seems that it isn't clear why we are at the current state and having all the tabs the same would probably be even easier to handle internally. So, unless there's some reason against, we should simplify this.
TagsNo tags attached.
Fixed in build2522

Relationships

related to 0018600 closeddrakinite [Performance] Improve tab switching animation & reduce forced reflow 

Activities

rusty

2021-11-18 22:50

administrator   ~0065994

Last edited: 2021-11-19 15:15

I doubt that many users take advantage of the apparent capability of having multiple layouts so I don't think this would be a major loss.

Note: users may want the state of the right/left panels preserved by tab e.g.:
a) tabs with audio content - users will want the right panel open
b) tabs with video content - users will want the right panel closed since movies are usually played one at a time / whole window
c) tabs with 'Playing' node - users may want the left and right panel closed since the panel duplicates the view
Just raising this issue in case it causes the same problems as multiple layouts

michal

2021-11-19 08:08

developer   ~0065998

I don't understand the proposal, when user has right panel opened in one tab and closed in second, it means he/she uses multiple layouts, i.e. that thing, we would like to remove to solve related problems...

rusty

2021-11-19 15:16

administrator   ~0066001

Last edited: 2021-11-19 15:21

I'd understood that 'Layout' consists of what's configured at Tools > Options > Layout and that panel state are independent. But on testing, I see that switching between tabs with different layouts can result in video playback stopping (by design).

The only other approaches I can think of are:
a) to give a warning: "Video playback will stop as there's no video window in this view".
b) force-enable the panel containing the video column if it's not enabled.

But both approaches are clunky. On the other hand, not supporting case c) is a significant loss.

EDIT: how about:
c) if the user enables a window without Preview, just temporarily play to the entire window

rusty

2021-11-19 15:39

administrator   ~0066002

Per discussion, we'll have to leave out multi-layout support for 5.0.2 since it's too difficult to fix all of the associated issues, and we can revisit this in a later release.

petr

2021-11-19 16:18

developer   ~0066003

Disabled multi-layout support and postponed to 5.0.3

rusty

2021-11-24 05:13

administrator   ~0066069

I'm not sure if this is implemented correctly--the bugs described can still occur because although the state of the right panel is now consistent across tabs, the state of the left panel is not consistent across tabs! i.e. if the Preview window is in the left column, the issues will occur.

petr

2021-11-24 10:31

developer   ~0066073

Last edited: 2021-11-24 12:57

I cannot reproduce. Preview in the left column, hidden by default. Start YT playback and switching between tabs works fine and playback do not stop.

EDIT: i can reproduce when i hide whole left dock and then switch to another tab ... the problem of this is more severe and it's risky to change it now (we need to redesign main tabs to move left dock out of the tab).

rusty

2021-11-24 15:26

administrator   ~0066078

OK. Leaving for 5.0.3 though the fix for 5.0.3 will be based on 0018562:0066001 (i.e. to re-enable some degree of different layout for different views--as discussed, I think it's sufficient to support a single layout but to allow for different states for the panels for each tab).

jiri

2021-11-25 11:12

administrator   ~0066119

I think that consistency would be preferred here and so I'd rather keep the same layout (including state of left & right panels) for all tabs. I.e. Tabs would change what's shown in the Main View, but anything else would remain the same.

rusty

2021-11-29 20:54

administrator   ~0066161

Last edited: 2021-11-29 21:22

As mentioned at 0018562:0065994, there are several cases in which it's desirable for content to display differently. Here's a more exhaustive list:
a) tabs with audio content - most users will want the tree / playing list / preview to display
b) tabs with video/visualizations playing to the whole window - this is an example of when playing content overrides the layout settings because an immersive experience is desired
c) tabs with 'Playing' node
i) List view: It may not desirable to have a duplicate playing list showing
ii) Artist Bio/Lyrics/Album Art: Users may prefer these views to be immersive. The problem atm, is that the immersive setting cannot be persisted within a tab. e.g.
1 Open a new tab > Playing:Artist
2 Set to Whole Window|Playing list enabled
--> No way to switch back to a different tab!
3 Click 'Normal Window' to switch back to regular view
--> Tabs re-appear and the user can now switch to a different tab
Summary: the simplest solution might be that when the user moves the cursor, in addition to the Player appearing, menus and tabs should also display so that users can switch from an immersive tab without altering its immersive state.

jiri

2021-11-30 12:23

administrator   ~0066173

Last edited: 2021-12-01 10:00

To satisfy the needs and trying to keep the things simple, here's the set of rules that might work:

1. Keep the layout always the same (including state of left&right panels).
2. Full window mode (videos/visualization/playing) would keep the menu and tabs visible, so that user could switch tabs.
3. Playing list not a special feature of Playing view anymore - i.e. its visibility only managed by visibility of the right sidebar. This prevents its visibility in the FullWindow/FullScreen mode, which is ok imho.
4. It'd probably make sense to allow specific layout configurations for fullscreen and fullwindow modes of Playing and Visualization. This way user could e.g. configure Visualization to show left panel with Lyrics. Note that the top of Options\Layout would have a dropdown like:
  Configure Layout for: _All views__ [v] {All views, Fullscreen Playing, Fullscreen Visualization}

Thoughts?

jiri

2021-12-01 10:01

administrator   ~0066195

I added point 4. above in order to cover specific needs of the fullwindow/fullscreen modes.

rusty

2022-04-20 15:53

administrator   ~0067615

Can't we just fix this by separating configuration and state of the panels? i.e.
- Tools > Options > Layout is used to Globally configure which panels are enabled in MM and which elements are enabled in each panel. It has no effect on the state of those panels (except that if the user disables e.g. the left panel, then there would be no way to enable the left panel in MM). This means that it could cause YT playback to stop, but that would be a rare occurrence since configuration is rare.
- MM views can contain toggle buttons that change the state of panels (displayed/hidden) on a per Tab basis.

This seems so much simpler/understandable from a user perspective.

-----------------------------------------------
If you prefer your proposed approach:
3. I'm not sure I understand this point. To re-iterate the requirements for the Playing node:
i) List view: Some users may want the right column displayed (either because they're re-ordering tracks OR because they want the Preview window which is currently only available in the side panels), and some won't.
ii) Artist Bio/Lyrics/Album Art:
- The immersive setting of a view should persist within a tab & the playing list should show (so that there's visibility into what is playing and what is coming up--the player auto-hides)
- In non-immersive views, some users will want the panel to display and some won't
4. Seems quite complex from a user perspective.

jiri

2022-04-28 15:14

administrator   ~0067847

I tested the original use-cases described in this issue and they are no longer reproducible. So it seems that we this issues could be set as Resolved, in order to not unnecessarily complicate things.

There's only one inconsistency: atm the left dock state persists per tab, while the right dock is per app. Still keeping this issue resolved though, as I'm not sure, whether it actually isn't beneficial in some cases (while inconsistent).

rusty

2022-04-28 17:48

administrator   ~0067853

Last edited: 2022-09-16 20:30

The problem is that the fix to the originally reported issues broke other usecases (as described at 0018562:0066161 and 0018562:0067615). Now switching between Playing and Library tabs requires users to regularly toggle the right-hand (but not the left hand) columns each time they do so.

Why can't we just eliminate the right-left inconsistency and have the right column behave the same as the left--except that both panels should have a separation between the configuration and state of the panels (as described at 0018562:0067615)?

Note: we should open a new issue for tracking in 5.0.4 once we come to a resolution, but I'm continuing the discussion here for now since most of the thread is already here.

jiri

2022-05-06 13:45

administrator   ~0068021

It seems to depend on user's expectations, for me a per-tab persistence of sidebars would be a step back (per IM, other devs agree with this point of view).

I'd say that this could be considered as resolved for now and possibly re-evaluated sometimes later, either based on more feedback or after some UI changes that might trigger the need for a different approach.