rweichler / cylinder

123 stars 47 forks source link

Parameters for scripts #66

Open rweichler opened 9 years ago

rweichler commented 9 years ago

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)

return
PARAM("Reverse Direction", false), --reverse
function(page, offset, screen_width, screen_height, reverse)
    --blahblah blah
end

...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

rweichler commented 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.

rweichler commented 9 years ago

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

rweichler commented 9 years ago

So yeah it'd basically be just boolean, integer, and float.

rweichler commented 9 years ago

Booleans

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.

rweichler commented 9 years ago

Picker

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.

rweichler commented 9 years ago

prettier implementation


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.

Actually no. Line it up with "name". If the param with "name" doesn't exist, do the default.

I'm an idiot.

rweichler commented 9 years ago

maybe change name to title instead