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 need a more advanced data structure #12

Open
lxkain opened this issue Dec 12, 2017 · 4 comments
Open

Parameters need a more advanced data structure #12

lxkain opened this issue Dec 12, 2017 · 4 comments

Comments

@lxkain
Copy link
Collaborator

lxkain commented Dec 12, 2017

current scheme to check if the newly entered render parameters is a mess; definitely need something else

parameters as of right now are made up of a dictionary[str, value] where the value can be a string or numeric based on the type of parameter. We probably want to do something like a dictionary[str, tuple(value, check_function)], where the check function would be run on the inputted parameter to ensure it's valid, if valid, then it can be set.

@lxkain
Copy link
Collaborator Author

lxkain commented Dec 12, 2017

unlike Processor.pararmeters, render parameters can be combinations of inputs, options of some pre-selections (colors), sliders, and so on.

Each different parameter will have its own way for checking for valid user input.

I propose that we have a Renderer.parameters format as such:

parameter = namedtuple('Parameter', ['name', 'values', 'check_function']

the parameter.values should accommodate lists, scalars, etc, and the value that goes into the check_function should be a function that checks the values for a valid input.

@lxkain
Copy link
Collaborator Author

lxkain commented Dec 12, 2017

We discussed today, I think parameters in general will be easier as a custom object

class Parameter(ABCMetaclass):

name: str = 'metaclass'
dtype = typing.Union[Tuple, int, float, str]

    def __init__(self, track: tracking.Track):
        self.track = track
        self.value = self.default_values()

    @abstractmethod
    def default_values(self):
        """queries the track for a default value"""


    @abstractmethod
    def valid_input(self, input):
    """method to check that the inputs are appropriate"""

We will need render and processor interact with this parameter object for getting/setting.

@lxkain
Copy link
Collaborator Author

lxkain commented Dec 12, 2017

What min and max could provide is the possibility of a slider. We may even want to know whether the slider should be linear or log.

Although, some min and max values can only be known once the track is known.

@lxkain
Copy link
Collaborator Author

lxkain commented Dec 12, 2017

so in that case, the dtype of the parameter would be range.

range would map to slider
set would map to drop down menu
a tuple of float, int, str would map to series of text inputs (based on the number of values expected).

so let's walk through a couple of render parameter examples here.

the main one we use is the y-boundary setting, which would be a tuple of numeric values, so that parameter would have two text inputs; first would be the min, second would be a max

a parameter that would qualify for range is frame size; which the track would provide what the absolute minimum and maximum frame size is, and a slider would be generated accordingly.

the color parameter might be a bit tricky, it would be a tuple of int's ...but i may want to give the option for not just rgb....but i can keep it simple to start with.

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