It occurred to me that the yes/no 1-or-0 return code for that function
might be too simplistic. I was thinking about your morning TrainInfo
usage, and how you'd set that up:
+1/9 (0:30) Date and Time
+2/9 (5:00) Train Information
so that you might have 30 seconds of Date & Time every 5 minutes. If
SaverSwitcher activated TrainInfo at 07:59:59, it'd stay active until
about 08:04:59 -- later than you ideally wanted.
Questions:
1) How valuable would it be (if at all!) to allow the pre-usage check
function to return the number of seconds it would like to be displayed?
For instance, at 07:59:59, it might ask to only be visible for 1 second.
SaverSwitcher would round that up to 5 seconds (minimum duration time
imposed to prevent timers from firing too frequently). Since
SaverSwitcher refuses to allow durations less than 5 seconds, the new
API could be extended something like 0 == do not use; 1 == use for the
normal duration; value N such that N > 1 == if in a normal rotation, do
not show for more than N seconds.
Plugins that issue reminders like a "N days to wife's birthday", "M
days to Christmas" could use this API to make notices appear for more
time as the date approached, or simply to request more time if more
notices needed to be displayed.
2) Would it make more sense to use hash objects to pass information and
return codes, as illustrated below? Using hashes and named input/output
data would make the API more easily extended, and would make the code
more readable (if less compact).
Code:
--------------------
sub myPreUsageCheck {
# SaverSwitcher passes data in a hash array
my $input = shift;
my $manual = $input->{manual};
my $client = $input->{client}; # if you needed the client object
my %returnData;
# assume should not be used
$returnData{allow} = 0;
if ( defined($manual) && ($manual == 1) ) {
# allow usage, no time limit
$returnData{allow} = 1;
$returnData{duration} = undef;
} else {
# time-based decision
my ($sec,$min,$hour,$mday,$mon,$year,$wday) = localtime(time());
if ( ($wday > 0) && ($wday < 6) ) {
# weekday
if ( ($hour == 7) && ($min >= 30) ) {
# between 07:30:00 and 07:59:59, so allow usage
$returnData{allow} = 1;
# duration: request active until 08:00
# SaverSwitcher would round anything less than 5 seconds up to 5 seconds,
# and would use the user's duration preference if this value is longer than
the user's preference
$returnData{duration} = 3600 - ((60 * $min) + $sec);
}
}
}
return \%returnData;
}
--------------------
That's more flexible than the "beta9" code (which has some variable
name mismatches in the Public.pm comments -- sorry), but is it worth
the trouble compared to what you'd write for the current "beta9" API,
which I imagine is something like the following?
Code:
--------------------
sub myPreUsageCheck {
my ($client, $manual) = @_;
if ( $manual == 1 ) {
# allow usage
return 1;
}
my ($sec,$min,$hour,$mday,$mon,$year,$wday) = localtime(time());
if ( ($wday > 0) && ($wday < 6) ) {
# weekday
if ( ($hour == 7) && ($min >= 30) ) {
# between 07:30:00 and 07:59:59, so allow usage
return 1;
}
}
# neither manual nor the normal morning weekday time
return 0;
}
--------------------
--
peterw
http://www.tux.org/~peterw/
free plugins: http://www.tux.org/~peterw/#slim
BlankSaver BottleRocket FuzzyTime SaverSwitcher SleepFade StatusFirst
VolumeLock
------------------------------------------------------------------------
peterw's Profile: http://forums.slimdevices.com/member.php?userid=2107
View this thread: http://forums.slimdevices.com/showthread.php?t=33598
_______________________________________________
plugins mailing list
plugins@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/plugins
