This thread has gotten very deep and the subject field is almost disappearing for me in Thunderbird, so here's a new thread title.
I feel that we're making progress in this discussion :) On 08/21/2016 04:47 PM, Daniel Schürmann wrote: > > Am 21.08.2016 um 23:04 schrieb Be: >> Okay, I understand your proposal better. There are still differences in >> what I'm proposing. I propose that there always be a right pane focused; >> there would be no way to unset the focus. > > If we decide for such a schema, a very important requirement is not > fulfilled: "It should be possible to open a pane where it was, without > thinking". Without that feature, it is a pain to DJ with two panes, try > it out ;-). With my proposal, I think this would be less of an issue for a few reasons. It would always be explicitly clear which right pane a feature icon will open in and it would be difficult for a user to accidentally switch the focus. If the user wants AutoDJ on the right, they click the focus icon of the right track table and click the Auto DJ feature icon. No exceptions and no surprises. Also, removing the dual purpose of the feature icons (opening left and right panes in different situations) would make it more difficult for users to accidentally open a feature where they don't want to. > In addition the simple midi menu -> sub-menu navigation does > not work, it will always use the same pane. There are many different controllers out there with different controls for library navigation. While we should be mindful of how the interface could be mapped, I don't think we should constrain the design of the whole program to accommodate the most limited controllers. This seems to be what happened with the effects framework and the result is that people who have mapped controllers with ample controls for effects have been frustrated and confused. The most common library browsing controls on controllers are a push encoder and two load buttons with a shift button (which is not necessarily adjacent to the library controls). Some controllers have a few more buttons as well. I propose that these basic controls be mapped like so: * Turn browse encoder: scroll through selected GUI pane. If feature icon bar is selected, open each feature in the focused track table as each feature icon is scrolled through. If left pane is selected, open selected tree item in focused track table (don't do anything for buttons like Auto DJ and Analyze controls though). If track table is selected, scroll through it but do not take action as each track is selected. * Push browse encoder: similar to current Tab key behavior, but not quite the same. Cycle through selecting feature icons/left pane/right track tables to scroll through * Shift + push browse encoder: toggle focused track table like the new focus icons * Load buttons: load selected track to respective deck * Shift + load buttons: eject track from respective deck >> If I understand your proposal correctly, it would keep the current >> behavior of requiring the feature icon to be clicked again to open the >> left pane controls for a feature that already has a right track table >> open. IMO this is cumbersome and a little confusing. > > It is slightly different (note: there is a pending bug in the current > branch that prevent this): > Lets say you have already a playlist in the right pane. This is not the situation I was referring to. I was referring to a situation like having a Library track table and Auto DJ track table both open. When the left pane shows the library tree and the user wants to access the left pane controls for Auto DJ, how should they do this? IMO it requires a bit of a mental disconnect to remember to move the cursor from the Auto DJ track table back over to the Auto DJ feature icon. It would be most straightforward to click the new focus icon on the Auto DJ track table. > You can preselect the left pane and select the desired second play-list > from the playlist tree. Now you have two playlist side by side. > If you do not touch the preselect icon, the new playlist will replace > the playlist in the right pane. As I understand this would be the same > in your proposal. Not quite. If the left pane follows the right pane focus as I propose, to open two playlists side-by-side: * Click focus button on a track table. * Click Playlist feature icon * Select a playlist from left pane * Click focus button on the other track table. Left pane switches to the feature that is currently open on that track table. * Click Playlist feature icon. This opens the Playlist tree in the left pane and the playlist splash page in the focused track table. * Select other playlist from left pane >> There should be a >> way to show the corresponding left pane controls directly from the right >> pane without having to move the cursor away to the feature icons. I >> propose that focusing a right pane with the new icon would open its >> corresponding left pane. > > We cannot do this in the current concept, because this would prevent the > two playlists side by side use case as outlined above. It would not prevent this as outlined above. It would require a few more clicks, but I think the whole interface being intuitive would outweigh that minor drawback. >> With the right pane focus decoupled from >> clicking in the track tables, there would not be the issue of annoying >> flickering of the left pane when clicking in different track tables. > > I am fine with changing the LibrarySidebarExpanded only by the button > bar. This avoids the mentioned flickering and allows the sorting to > playlist use case as discussed earlier. With my proposal, the sorting many tracks to many playlists/crates use case would proceed like: * Click focus icon on a track table. * Click Library or other feature icon to locate some tracks. * Click focus icon for other track table. * Click Playlist feature icon. This opens the Playlist tree in the left pane and the playlist splash page in the focused track table. * Drag and drop tracks between Library (or another feature's) track table and Playlist tree. The current behavior of dragging and hovering the cursor over a feature icon to access its left pane drop targets would also still work. > > A track table focus dependent change of the LibrarySidebarExpanded will > IMHO not add any additional value to the use. The Breadcrumb and the > search bar should be sufficient to indicate the table state. > The purpose isn't to indicate the table state. I agree that the bread crumb and search bar provide enough for this. It's to provide easy access to the controls in the feature's left pane. ------------------------------------------------------------------------------ _______________________________________________ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel
