How does this change in ownership affect Traction_engine? Now they have different owners.
Tracktion Corp has always been a separate company from JUCE/ROLI, and nothing has changed with the change of ownership of JUCE.
cough cough
This is all I’m asking to be added:
int getCurrentPopupIndex() const { return currentPopupIndex; }
There’s a different issue regarding accepting PRs that relates to ownership.
I’m fuzzy on the details but I think that whoever writes the original pull request by default maintains ownership of those lines of code.
This complicates accepting PRs because now you have different bits of code technically owned by different people and then you’re distributing all the code together under the GPL or selling it as a commercial licence.
To clean this up contributors usually sign a “contributor licence agreement” or “CLA”. For example, Facebook has a form you have to agree to before they’ll accept PRs from you.
GitHub has some text you can can customise when a PR is opened but I’m not sure if this is enough to be an “implicitly accepted CLA”.
Can anyone who has more knowledge on the subject clarify these points or correct me where appropriate?
This isn’t really the thread to be promoting your PRs, but it’s useful as I think it helps to prove my point. On the face of it that looks like a simple one-liner that we should just add to the library, but from the perspective of the library designers this is a bad idea. If we start exposing the guts of classes like MenuBarModel which are used in a lot of people’s code, then users start depending on that code and we can’t refactor the internals of the class in the future. So a simple one-line change becomes a much more complicated process of trying to figure out if there is a better, cleaner way to do what you want which doesn’t change the public API of the class, or does so in a future-proof way.
@ed95 - why can this kind of response not be made in the PR? (and then close it)
It would then also serve as a message to other potential contributors browsing PRs.
I think the more responses about style and appropriateness contributors receive the more likely future PRs will be to adhere to style and be more appropriate for inclusion in the library.
does this mean that in the near future i will need an iLok to run my juce code? 
Yeah, I think this might be the most important point. I experienced both: Raising a pull request and not getting any official response for some weeks and then suddenly seeing my feature request appear in JUCE 6 as a reaction to that and a different PR with no response for some months now.
I would never expect that a PR will make it straight into the official JUCE codebase, I would interpret it as some proof-of-concept, “works this way for me” sort of proposal that might maybe contain a few pointers towards whatever could be relevant in that context.
Now if there would be some kind of response like
- “Sensible request” / “We already thought about something like this too” / “We are already working on a solution to this”
- “We will put it on our backlog but with lower priority”
- “This one won’t make it into JUCE because of…”
this could greatly help the person raising the PR to keep on working on whatever project he/she is working on. Because I guess no one just makes up PRs if there is no realistic need for the feature in a project someone is working on. Getting feedback on what will likely happen could make the decision easier if this is something to wait for or if a custom solution to that problem should be found.
That being said, what about moving the whole PR policy topic to a different thread – seems like there are too many topics mixed up here?
@ed95
I didn’t get a response to my thread explaining the reason behind this PR either other than “don’t tag us” so…
Y’all say you read every thread, but do you?
![]()
related: Pull Request policy thread
I wonder if part of the problem here is that the forum isn’t really split up into separate sections, is certainly not enforced to be as such, and sometimes things can just get buried under the weight of posts.
I had to resort to spamming edits/responses to a question I raised about plugin resizing twice before members of the community gave some of their own insight, but still no-one from the JUCE team (who might be able to give a definitive answer) weighed in, which was mildly disappointing.
I’ve got a new question, I know that JUCE will never integrate fully into iLok services, but can there be some tools or codes related to software protection (such as bytecode virtual machine protection technology) integrated into JUCE?
