Author Topic: Saving Layout State after Screensaver?  (Read 6363 times)

liquid8d

  • Global Moderator
  • Sr. Member
  • *****
  • Posts: 442
    • View Profile
Saving Layout State after Screensaver?
« on: March 05, 2015, 09:59:10 PM »
So, I'm just now realizing this, but it may be an important thing to keep in mind when creating layouts.. but since the screensaver is a layout, and your layout is re-loaded when returning to it, it can have some adverse effects:

Code: [Select]
local text = fe.add_text("Move me", 0, 0, 300, 30);
fe.add_transition_callback("transition_callback" );

function transition_callback(ttype, var, ttime)
{
    if (ttype == Transition.ToNewSelection)
    {
        text.y = 100;
    }
}

With code like this, that means if the transition had already occurred before the screensaver, the object will get put back to the original position when returning from the screensaver.

First, is screensaver the only thing that might cause your layout to be reloaded, or are there other scenarios (apart from loading a different layout)?

Second, what's the best way to "save state" here? Wherever my objects are when the screensaver occurs, that's where i want them to be when it comes back.

Should we be storing values of object properties when we alter them, in order to restore when re-loading the layout?

I'm having one of "those" coding days, so maybe I'm just completely doing something stupid.
« Last Edit: March 05, 2015, 10:47:25 PM by liquid8d »

liquid8d

  • Global Moderator
  • Sr. Member
  • *****
  • Posts: 442
    • View Profile
Re: Saving Layout State after Screensaver?
« Reply #1 on: March 05, 2015, 10:40:03 PM »
just to add, when playing around I was thinking of ways this could be done...

At first I thought maybe I could create a 'state' table in the root table:
Code: [Select]
state <- {
  //store variables here
}

But it seems that even the root table is wiped when reloading a layout.

Then I realized that maybe you could add it to the UserConfig class, but it seems like anything added in there ends up as a string?

Code: [Select]
class UserConfig {
   state = { x = 0, y = 0 }
}

local cfg = fe.get_config();
print( typeof(cfg.state) + "\n");

Any suggestions on how to store modified values other than the user modifiable options?

raygun

  • Administrator
  • Sr. Member
  • *****
  • Posts: 393
    • View Profile
Re: Saving Layout State after Screensaver?
« Reply #2 on: March 06, 2015, 11:08:10 PM »
The screensaver should be the only thing that resets a layout, and yes whenever a new layout or the screensaver is shown the squirrel vm gets completely reset.

So with the current version, the only way I can think of for saving state when the a layout switches to the screen saver is to write it to a file and the load it back from the file when the screen saver returns.

Definitely not ideal if all you are looking for is saving position etc. while the screen saver is running...

Any ideas for what would work best for what you want to do?  It would be pretty straight forward I think to have a string blob or something that persists across layouts if that would help...

liquid8d

  • Global Moderator
  • Sr. Member
  • *****
  • Posts: 442
    • View Profile
Re: Saving Layout State after Screensaver?
« Reply #3 on: March 07, 2015, 06:57:35 AM »
This is similar to what I brought up before with ExtendedObjects, giving access to a table somewhere that could be used to store variables and such... I'd say one of two ways would be ideal:

UserConfig
I assume you serialize that class and we restore it with get config. Is there a particular reason that we can't store other variables (like tables) in there? If we could extend that to include variables beyond user-modifiable string values, that would work just fine.

Save/Get state methods
fe.save_state(table);
fe.get_state();

Same thing basically, but if it can't be made available in the UserConfig, perhaps a separate option to save our settings.

I would like to see both options if possible - providing a way to store both layout specific and global states. UserConfig could store your layout state to restore when it's reloaded, and save_state/get_state could be a global state. I think global states would be important for modules and plugins across multiple layouts.


raygun

  • Administrator
  • Sr. Member
  • *****
  • Posts: 393
    • View Profile
Re: Saving Layout State after Screensaver?
« Reply #4 on: March 12, 2015, 07:57:35 AM »
it's a good idea. I'll try some things out in squirrel to see if there is an easy way to enable this... I'm not sure messing with the userconfig is the best way, it sounds like simply having a table (perhaps the root table even?) that survive through layout changes would help.