Open rweichler opened 9 years ago
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.
And 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, default
already implies type
. So you don't have to put in "boolean" for type
and "switch" for input
, but it's there if you want to be more verbose. Obviously if you put "integer" for type
or "slider" for input
it will error.
And, of course, no min
or max
.
PARAM{
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 default = "Outside"
to make it more verbose. Wouldn't cause any performance loss. But definitely would need to pass numbers to the main function, because string comparisons would be really expensive. Especially if you stack multiple effects that do this.
local 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.
I'd need to refactor there'd have to be a secondary check between when you select the effect in settings and go to SpringBoard and move the page, to make sure the script wasn't replaced yet. Or else things could get ugly. No need. Immediately after selecting the effect the script is loaded in SpringBoard. This implementation is totally fine
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.
I'm an idiot.
maybe change name
to title
instead
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