Skip to content
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

Open
rweichler opened this issue Feb 18, 2015 · 7 comments
Open

Parameters for scripts #66

rweichler opened this issue Feb 18, 2015 · 7 comments

Comments

@rweichler
Copy link
Owner

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
Copy link
Owner Author

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
Copy link
Owner Author

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
Copy link
Owner Author

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

@rweichler
Copy link
Owner Author

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
Copy link
Owner Author

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
Copy link
Owner Author

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
Copy link
Owner Author

maybe change name to title instead

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant