Talk:Completed Proposal Timer Record Improvements Phase-1

From Audacity Wiki
Jump to: navigation, search

Timer Record operating environment - a thoughtpiece - Peter 18Mar16

Current situation

With current 2.1.2 (and in all previous versions) Timer Record operates in a a mult-project environment - but with the proviso that once the Timer Record is initialtes and is either waiting or recording then active access to all other open projects is totally locked and barred.

This is done to ensure the integrity of the Timer Record process and particularly to ensure (in an easy way) that no other open project can interfere with the scheduled start of the Timer Record by being active at the time)

In a true mullt-project environment there should be no need to inhibit access to other projects while waiting, perhaps a long time, for a scheduled Timer record - you just would have to manage any potential clash when Audacity Timer Record was about to start.

Under development

Mark is busy working on improvements to Timer Record which have been long requested in a proposal in the Wiki. These include optional actions at the completion of a successful Timer Record such as closure/quitting of Audacity or shutting down the computer.

Such actions would have a clear impact on other open projects if Timer Record continues to operate in a multi-project environment. This gives us a number of options to consider.

1) Timer Record operates in a sole one&only open project

This is Mark's currently chosen approach and was chosen as a good and simple way of ensuring the safety and integrity of both the Timer Record and any other Audacity project that the user has.

It also gives us the potential benefit of experimenting with making Timer Record modeless which should enable us to grant easy access to the controls while Timer Record is in progess either waiting or actively recording. This is something long requested in the Wiki proposal for TR enhancements.

Mark regards this as an improvement (and not a minor regression) as we now tell users they cannot access more than one project during Timer Record, rather than just locking them out. And I, Peter, am in agreement with him on this.

Mark, Steve and Peter are all +1 on this approach currently

Gale is currently 0. It's still a "minor regression". It might not be necessary to require this even if we have modeless Timer Record. For example we might disable all actions in the other projects that we currently disable in the project being recorded into. One project only might make any future multi-event scheduling feature (the most popular Timer Record request) less flexible than it could be.

There are no nay-sayers

When Vaughan originally implemented Timer Record he clearly took the view as the "doer decides" developer" that it was best, safest and simplest to adopt the approach of simply locking all access to any other open Audacity projects while a Timer Record was in play either waiting or active. Thereby avoiding any brush with the wormcan of multi-projects.

I really think that Mark should be able to choose this Option 1 as the "best, safest and simplest to adopt" going forward with these new enhancements.

A good use case where Mark's use of Option-1 offers a significant improvement over Vaughan's implementation:

With Vaughan's as in 2.1.2 (and previous)

  1. User has project-1 open
  2. does several hours work on it without Saving
  3. User the opens new Project-2
  4. Sets up a Timer Record
  5. while waiting for Timer Record to start or while it is actively recording - realizes that they really should have saved project-1
  6. no-can-do until the Timer Record finishes (or the user interrupts it)

In Contrast with Option-1 as Mark has implemented - the user is forced to close project-1 and either save or abandon it before the Timer Record can be set up in project-2.

Gale 19Mar16: In option 4 which I prefer the user is forced to save the project. But they also get the flexibility to keep it open.

2) Exit & shutdown are not permitted if other projects are open

This means that Timer Record can continue to operate in a multi-project environment.

  • IF any other projects are open "dirty" or "clean"
  • THEN the user is prevented from selecting either of these completion options
  • ELSE these options are available and allowed

I.e. if other projects are open then the only "After Recording Completes" action allowed is the "Do Nothing".

We would, of course, continue to lock all other projects until completion of the Timer Record as now.

Adopting this approach probably means that we should not be "remembering" the After Recording Completes" action by writing it to audacity.cfg as if the user sets a legal exit/shutdown action when operating with no other projects and then later sets up a Timer Record with multiple other projects open then an illegal After Recording Completes" action may be remembered.

This should be relatively simple to implement, but may be difficult for us to grant access to the controls.

Peter would be +0.5 on this

3) Exit only exits the Timer Record project - but leaves any other project open

This means that Timer Record can continue to operate in a multi-project environment, but computer shutdown would be denied and not permitted IF any other projects are open at the time of setting up the Timer Record.

As in 2 above: we would, of course, continue to lock all other projects until completion of the Timer Record as now.

If other projects are open then the only "After Recording Completes" actions allowed are the "Do Nothing" or the "Exit Audacity" and with the Exit only the current Timer Record project is exited all others are left alone and open.

As in 2 Adopting this approach probably means that we should not be "remembering" the After Recording Completes" action by writing it to audacity.cfg as if the user sets a legal exit/shutdown action when operating with no other projects and then later sets up a TR with multiple other projects open then an illegal After Recording Completes" action may be remembered.

This approach raises the question: if the user selects "Exit Audacity" as the on-completion action with other projects open, do we then warn them that the other open projects will remain open?

This should be relatively simple to implement, but may be difficult for us to grant access to the controls.

Peter would be +0.5 on this

Gale is -1. Worst of all worlds.

4) Timer Record to ensure that all "dirty projects are "saved"

This means that Timer Record can continue to operate in a multi-project environment, as now in 2.1.2 and previous. But remember that all other open projects are locked an inaccessible so no other Audacity work is possible in those projects until the Timer Record completes.

But if any "dirty" projects are open then the user is told they must save or exit those before they can use Timer Record. And access to Timer record is denied until the user has effected that.

This should be realtively simple to implement, but may be difficult for us to grant access to the controls.

Note that there is absolutely no benefit to keeping other Audacity projects open if the user selects the completion actions of "System Shutdown" or "System Restart" as such projects would alos be closed in the shutdown or restart.

Peter would be +0 on this - it just seems a tad inelegant, but it would certainly work

Gale is +1.

5) Timer Record doesn't concern itself with other projects

This means that Timer Record can continue to operate in a multi-project environment.

On successful completion Timer Record effects the user's chosen completion action.

If this is "Exit Audacity" this could be either exit just the Timer Record project - or exit Audacity entirely.

The other completion action that has potential impact on other projects is the computer shutdown.

This should be *very* simple to implement, but may be difficult for us to grant access to the controls. But it it is messy and will lead to users not achieving their objectives.

Peter would be -1 on this

6) We solve the Multi-project wormcan

See this Wiki discussion paper: The Multiproject Wormcan

This means that Timer Record can continue to operate in a multi-project environment with impunity.

But don't hold your breath, there is no sign that we are going to tackle this any time soon let alone solve it.

And let us not forget that our current "multi-project environmen" is not a true one. It only really allows us to have multiple projects open at any one time - the interactions between those projects are ill-defined (and can lead to unpredictable and dangerous situations as detailed in the wormcan discussion paper in the Wiki).

Choices and mutability

Let us remember that whatever we choose now we can always change later if and when we get users complaining that things have changed. If we select option 1 now it would berelatively easy to move to any of the other options (apart from no. 6, the wormcan, that is ... )

Steve's response 18Mar16

If we provide an option to shut down the computer on completion of a Timer Record, then the user needs to be reminded to save their work in ALL other applications. If they have other applications open with unsaved work and Audacity tries to shut down the computer (in an unattended Timer Recording), then either they will lose all unsaved work in all other applications that are open, or shutting down the computer may be blocked by one or more of the open applications.

In my opinion, it would be very messy and confusing to tell the user to save and shut down other applications but that they don't need to save or close other Audacity projects. This is the type of unnecessary complication that leads to users losing work. Much better imo to keep it clear and simple - if we provide an option to shut down the computer on completion of an unattended Timer Recording, tell the user to save ALL work in ALL projects and All other applications, and close ALL other projects and ALL other applications properly.

I'm +1 for providing an option to shut down the computer after an unattended Timer Record, _provided_ that we can do it safely and that the user is made aware of the risks involved. Both the Exit and the shutdowwn have an impact on any open "dirty" projects - but this can be seen as the same as the user at the end of a Timer Record manually choosing a "Force quit" of Audacity(ies) of a shutdown. In which case the exit or shutdown is inhibited by the fact that "dirty" projects remain open and must be dealt with.

Peter's response to Steve 18Mar16

Note that "Perform system shutdown after recording" has 7 votes on the Wiki Feature Requests page.

But I think it's down to the user that they have work in any other apps safely saved by the time their Timer Record completes if they have selected the computer shutdown option.

Remember you can't check for this at setup time for TR necessarily as the schduled start could be much later, with the user do work in apps like Word, Excel, Photoshop etc. in the meantime.

Steve 18Mar16: Sure, but we should remind / warn them - I remember how annoying it was when Windows decided to restart NOW while I was in the middle of something. Will there be a countdown after the recording has finished before shut down (just in case the user needs to cancel the shut down)?
Peter 18Mar16: The way Mark has it now, there is no such countdown. But this is another reason why it is important to have access to the controls in case the user wants to change their mind not only about endtime/duration but also the on-completion actions.
Gale 19Mar16: We should warn in Audacity and allow user to send shutdown abort after on-completion is reached. Timer Record has closed then.
Peter 19Mar16: Mark has already provided a one-minute Audacity wait before effecting the computer shutdown and the Audacity exit.