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

Input Splitters #2

Open
gtoledo3 opened this issue Apr 14, 2012 · 1 comment
Open

Input Splitters #2

gtoledo3 opened this issue Apr 14, 2012 · 1 comment

Comments

@gtoledo3
Copy link

I want to push a version of this that creates the input splitter functionality, but just categorizes them as private. Should I just create a fork for that, or are you interested in doing that to the main branch?

@smokris
Copy link
Member

smokris commented Apr 15, 2012

Background: QC's default Input Splitter shows up once in the Patcherator, and creates an Input Splitter of type Virtual. DataTools includes a disabled experimental implementation of typed input splitters (listing the Input Splitter in the Patcherator for every type of input the Input Splitter accepts). The current implementation creates a subclass of QC core's Input Splitters, which depends on DataTools.

I think this is misleading — QC core's Input Splitters should not have a dependency on DataTools.

I don't think it's appropriate to enable this failed experiment in DataTools — even if marked private, since pretty much everyone has private patches enabled anyway and there's no reliable way to tell from the QC Editor that a patch is private.

However, if we can modify the implementation such that the Input Splitters no longer depend on DataTools after being created, then I'd be happy to include that (and mark them public). I don't expect to have time to look at this soon, but diff-patches/pull-requests are welcomed.

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

No branches or pull requests

2 participants