(2.1.0, API) Revising the Show/Hide mechanism

MichMich

If a module currently hides an other module (let’s say, for example by using the facial recognition module) and an other modules hides and shows the modules (for example my mqtt-alarm-welcome module), stuff get messed up. The second module shows modules that still needs to be hidden …

I’m thinking about changing this behavior, by letting modules take a hidden lock on a module. This means the module will not appear as long as that module does not say it should be shown. This could be done by using a lock identifier (which could simply be the module’s identifier).

To explain it a bit better, here is the scenario with a 3-module mirror (all code below is just as an example, not real code):

Module B asks module A to hide:

moduleA.hide(lockString: "module_b_identifier");

Module A is now hidden, and has an lock array with the following strings:

moduleA.locks = [
    "module_b_identifier"
]

Module C asks module A to hide:

moduleA.hide(lockString: "module_c_identifier");

Module A is now hidden, and has an lock array with the following string:

moduleA.locks == [
    "module_b_identifier",
    "module_c_identifier"
]
moduleA.hidden == true

Module B asks module A to show:

moduleA.show(lockString: "module_b_identifier");

The lockString will be removed from moduleA’s locks array, but since there still is an other lock string available, the module remains hidden:

moduleA.locks == [
    "module_c_identifier"
]
moduleA.hidden == true

Module C asks module A to show:

moduleA.show(lockString: "module_c_identifier");

The lockString will be removed from moduleA’s locks array, and since this will result in an empty lock array, the module will be visible:

moduleA.locks = []
moduleA.hidden = false

Does this make sense to you guys? Is there an other scenario I should take into account? Let me know your feedback so we can work towards a more stable show/hide mechanism.

KirAsh4

It’d be nice if there was also a way to override the array completely. What I mean is, if Module A hides a module, then Module B says to unhide, even if the locks don’t match, having an override, or ‘force’ flag, that would be handy. This applies for multiple modules as well, if Module A hides something, then Module B does the same, then allow either of them, or potentially even a completely different module, to overwrite the array and show the module again.

This wouldn’t be the default behavior, but having a ‘force’ flag would then allow the user to specify that.

MichMich

It is a piece of cake to make a force flag, and I probably will. But I can’t really think of a case in which the use of a force flag is justified.

KirAsh4

Neither can I, but the moment we say that, someone will come up with a reason to need that. :)

ianperrin

@MichMich

Does this fit the use case?

ModuleA is configured to be hidden at 9am and shown at 6pm by ModuleB using a schedule.

At 9am ModuleB (the scheduler) hides ModuleA.

At 11am ModuleC (Remote Control) is used to show ModuleA.

At 11:30am ModuleC (Remote Control) is used to hide ModuleA.

At 6pm, ModuleB (the scheduler) shows ModuleA

Am I correct in thinking that without the force flag, neither ModuleB or ModuleC could show ModuleA at 11am or 6pm respectively?

MichMich

Yeah, but I think that is the exact reason why this method should be implemented. One can argue what the desired result is. But by implementing the force option, both scenarios will be possible. Implementing a force function isn’t really a big deal.

Thanks for your input!

ianperrin

Agreed.

And perhaps best practice should be that any module wishing to show/hide other modules should include a config option to toggle the use of the force flag.

Let the user decide!

MichMich

Agee! I’ll make sure to add that to the documentation.

MichMich

Method is implemented. See documentation:
https://github.com/MichMich/MagicMirror/tree/develop/modules#thishidespeed-callback-options
https://github.com/MichMich/MagicMirror/tree/develop/modules#thisshowspeed-callback-options
https://github.com/MichMich/MagicMirror/tree/develop/modules#visibility-locking

Jopyth

@MichMich Did you have any concerns about making this an opt-out instead of an opt-in? I.e. make the default options {this.identifier} instead of {}. Or is there a specific reason against it? The overall concept seems reasonable, if we assume the meaning of the hide() method always was to “keep this module hidden until I want it to reappear”.

I do not think anyone does something like hiding module A from module B and then purposely showing module A again from module C. This is the only way I think of, which would make the default option using the modules identifier weird.