On 03/30/2012 03:48 AM, J. Liles wrote:
> The point of those guidelines is to allow users to know*exactly* what
> behavior they can expect.
>
> The chief difficulty I had with implementing LASH support in programs
> was that there was no answer as to what 'Save', 'Open', 'New', etc.
> should do when running under LASH. Left, as is, the effect of these
> operations would vary depending on how individual applications store
> their state (whether fully in RAM, in a fixed location on disk, etc.).
> This scenario is an absolute nightmare for both implementers and
> users. If following a few simple rules to disable certain menu options
> is enough to remove this ambiguity entirely, then why is that so hard
> for you to accept? Do you*want* to make things ambiguous and
> impossible to predict? I know I don't. The rules are not there to be
> draconian and imposing--They are there to allow people to have
> confidence in what running under session management means regarding
> where their data is stored.
Makes me wonder about JackSession. Does it have the same problem here
compared to LASH?
\r
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Fri Mar 30 12:15:02 2012
This archive was generated by hypermail 2.1.8 : Fri Mar 30 2012 - 12:15:02 EEST