Re: [Audacity-devel] Reassigned spectrograms

[Steve t. F. <ste...@gm...>]

On 18 August 2015 at 16:50, James Crook <cr...@in...> wrote:
> On 18/08/2015 15:45, Steve the Fiddle wrote:
>
>
>> If there is a draft proposal, including a draft for the GUI, before a
>> new feature is introduced, then many of these issues could be ironed
>> out before committing to code and the documentation crew could be
>> working on draft documentation while the feature is being developed.
>
> Yes, but we also have to be responsive to 'please try this branch'.
> Otherwise there is a very strong incentive to just merge the branch into
> master and be done.

"Try this branch" is something that I like to do, time permitting, but
becomes difficult when there are so many changes happening in the main
repository.

>
>>
>> A problem that you may not be aware of is that we can't document these
>> features until you have finished experimenting with different GUI
>> layouts. Could you give some indication of when that might be? We
>> should try to avoid making last minute changes immediately before
>> release if we can possibly help it.
>>
>> Steve
>
>
>
>
>
>
> Steve, we currently have
>
> ----
> Waveform
> Spectrogram
> View Settings
> ----
>
> How about instead:
>
> ---
> Waveform
> Spectrogram
> ---
> Waveform Preferences
> Spectrogram Preferences
> ---

I think this hits on the main problem.
Are these globally acting preferences, or per-track options?

Do we need to have every setting available as a per-track option?
How do per-track options interact with globally set default preferences?

Making every possible setting a per-track option seems like overkill
to me, and I think will discourage experimentation because many user
will take one look and immediately give up.

Steve

>
> How about if apply button was gone and instead apply was applied after every
> preference change (when in this dialog)?  It is a little less efficient on
> menu space, but it does (a) make clearer that we are working with
> preferences for particular views and (b) makes it easier to experiment
> directly with changes.
>
> If you don't like this, or do but don't think it does enough, please give a
> counter proposal.  We want reassignment one way or another. There are
> clearly more settings for Spectrogram than we want to show directly in the
> top menu, so a counter-proposal does need to solve that.
>
> --James.
>