Robert Brenstein wrote:
Sounds good to me, Paul, but you need to accommodate closing stack
window as opposed to closing stack. We have now:
close with destroyStack off = close stack window
close with destroyStack on = close stack window, remove stack from
memory
We still need to be able to do the former. Hide stack comes to mind
as a solution, of course, but making a stack as invisible is now
subtly different than closing it without removal from memory.
If I understand Paul's suggestion correctly, I believe that's covered
under his request for a "load" command.
His thinking is not unlike something we all go through learning Rev:
in any other app closing a window ultimately purges the data presented
in it from memory.
I am not sure that it is covered. Unless you mean than when I open a
stack, then I have to close it, then load to have it in memory again?
That would be too much ado. I am referring to a case when I open (not
load) a stack and then close it but want to keep it in memory since I
plan to reuse it (possibly re-show to user).
I think that ambiguity arises, at least partially, from having stack and
window being more or less synonyms, although they are not really quite
the same.
Quite, esp. given that we also have a destroyWindow property. :)
I think all Paul's suggesting is that two things happen:
1. Both stay-resident-on-close and purge-from-memory-on-close behaviors
remain available as they are now, but the default would be
purge-from-memory-on-close.
2. Introduce explicit commands for managing whether stacks are in memory
or not, as opposed to the current situation which is wrought with
inconsistencies (destroyStack only applies to stacks that are opened,
but not those we merely read properties from without opening, and
deleteStack sometimes purges stacks and at other times actually deletes
the physical stack).
Whether the default behavior is changed, I think we all agree that some
form of explicit control over what's in memory and what's not would be
desirable.
And stepping back to look at the big picture, I doubt any of this will
have much effect for quite some time anyway if at all, since there are
many, many bigger fish to fry in the meantime. So while it may be
enjoyable conversation, I don't think we need to get too worried about
any impending change on this anytime soon. :)
--
Richard Gaskin
Managing Editor, revJournal
_______________________________________________________
Rev tips, tutorials and more: http://www.revJournal.com
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
