-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Parameters for scripts #66
Comments
For numbers it'd be kinda ambiguous. There's tons of different options for that. Like digits, and min/maxes. Might be ugly. PARAM("Number of rotations", 1, {type = "integer", input="slider", min=1, max=20})
PARAM("Number of rotations", 1, {type="integer", input="keypad", min=1, max=20})
PARAM("Speed", 1, {type="float", input="slider", min=0, max=20}) But the problem is it's sooooooo confusing. I'm trying to make this as intuitive as possible and this definitely isn't. But I'm not sure what else you could do. idfk. |
Maybe just pass in a table as the only argument? return
PARAM{
name = "Number of Rotations",
default = 1,
type = "integer",
input = "slider",
min = 1,
max = 20
},
function(page, offset, page_width, page_height, rotations)
-- blah blah blah
end I'm feeling this much more actually |
So yeah it'd basically be just boolean, integer, and float. |
BooleansAnd yeah. Even for booleans where it's just 2 you'd have to put it in a table. Much more verbose and consistent. PARAM{
name = "Reverse direction",
default = false,
type = "boolean", -- optional
input = "switch", -- also optional, as a switch is the only thing that makes sense
} For a boolean, And, of course, no |
PickerPARAM{
name = "Type",
type = "picker",
input = "picker",
options = {"Outside", "Inside"},
default = 1
} UIPickerView. Whatever one you pick it'd pass the index of the table as the parameter. So if you choose "Outside" then it'd pass 1, and if you choose "Inside" it'd pass 2. You could also do |
prettier implementationlocal is_outside = PARAM{ ... }
return function(page, offset, screen_width, screen_height)
-- blah blah blah
end I like this one a lot better. Very verbose. Makes a lot of sense. The only problem is how to figure out how many param functions there are and which ones go to what. I guess run the script once on the selection menu, and figure out the order of the PARAM functions, then when the script is actually opened on SpringBoard, just fill in the values and ignore the args.
However, regardless of the implementation be it this one or the original proposal, you'd need to store the effect parameter you chose in the .plist. And there'd have to be a way to distinguish which params are even an option. If an effect removes a param in an update, it could be ugly. Then again, I THINK (double check this) formulas don't do this check now that I think about it. Might be fine. Actually no. Line it up with "name". If the param with "name" doesn't exist, do the default.I'm an idiot. |
maybe change |
For example in this thread they wanted EmotionUI to go in reverse
So I was thinking you could do something like this (EDIT: _prettier implementation_ a few comments below)
...or some shit. Custom parameters would be added as an extra argument to the function, and the default value would imply what type it is. In this case "Reverse Direction" would just be a switch.
I'd have to overhaul the whole selecting effects shebang in order to achieve this, elaborated more in #67
The text was updated successfully, but these errors were encountered: