On 08/21/2016 07:50 PM, Daniel Schürmann wrote:
> I think we have a big misunderstanding because of the naming of the
> panes. From left to right, we have:
> * ButtonBar
> * LibrarySidbarExpandend (holding the tree views)
> * left pane (1)
> * right pane (2)
> * additional panes (n)
>

Yes, we do have some misunderstandings. I have been using "pane" in the 
generic sense to refer to any of these areas of the GUI.

It seems the major question we have not come to a consensus about is how 
to control which feature is shown in LibrarySidebarExpanded. To 
reiterate my proposal using this language:

* Focus of the track table panes only changes by clicking the selection 
icon. There is always a track table pane focused.
* When focused, a feature's LibrarySidebarExpanded is shown.
* Clicking feature icons always opens the feature in the focused pane.


>>> 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.
>
> There is no issue that a user switches existential the focus any more.
> The user has now a dedicated click that is required to switch the focus.
>
>  From my experience it helps a lot to let the Auto DJ track table appear
> always right. In your model it happens easy that a user searches for a
> track in the left pane. Now he wants to use AutoDJ controls, lets say
> "Fade now", he clicks on AutoDJ controls the Auto DJ button without
> caring about the focus. Result: The library track tabke is replaced with
> a second AutoDJ pane. This is worse in two ways. He lost the state of
> the current search process in the library, and he gets a second unwanted
> AutoDJ pane.

No, the user wouldn't click the AutoDJ feature icon. The user would 
click the focus icon. Therefore there would not be accidental opening of 
a feature's track table where it is not desired.

>
>> 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.
>
> This will work in your model and in mine the same way.

What I am confused about regarding your model is the situation of not 
having either track table focused. How does the user open the 
LibrarySidebarExpanded for a feature that has a track table pane open? 
If I understand your model correctly, this would create the confusing 
situation of having to click the feature icon but not making it clear 
where that would open a track table, unless an association had been 
previously set.

>> 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.
>
> I assume that the case is far more common that the user wants to open
> the track table where it was before the moving it around. For me moving
> panes around is only a one time issue at the very start of a new use case.

I see your confusion now. This isn't about swapping panes. What I'm 
concerned about is having the feature icons serve the dual purpose of 
opening the feature's track table and also opening its 
LibrarySidebarExpanded when the track table is already open.

>
>> * 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.
>
> I want to keep my library left and AutoDJ right association even when I
> use the controller. Taking the mouse to switch the pane focus makes the
> whole controller navigation useless. If I do open every feature in the
> left pane, the whole dual pane feature is useless.

The mouse would not be needed.
>
>> * 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
>
> That might work, but is not self explaining.

No, it isn't self-explaining. But we are building a fairly complex 
system and those aren't many controls to map. I don't think it will be 
able to be completely self-explaining.

>
>>> 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
>
> I have probably not understood this correct.
> For now it looks to me more than a bad example than a desired behaviour.
> What is the additional information you gain from an always changing
> LibrarySidbarExpandend?

You have not understood. To reiterate using the terminology you outlined 
above:

* Click focus button on a track table.
* Click Playlist feature icon
* Select a playlist from LibrarySidebarExpanded
* Click focus button on other track table. LibrarySidebarExpanded 
switches to the feature that is currently open on that track table.
* Click Playlist feature icon. This opens the Playlist tree in 
LibrarySidebarExpanded and the playlist splash page in the focused track 
table.
* Select other playlist from LibrarySidebarExpanded.

I like the idea of decoupling clicking on tracks from focusing the track 
table panes because it allows for LibrarySidebarExpanded to follow the 
focus without having LibrarySidebarExpanded flickering when clicking 
back and forth between track tables.

------------------------------------------------------------------------------
_______________________________________________
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

Reply via email to