State of Community PRs

Hey JUCE team,

Don’t hate me! I understand you are all engrossed in JUCE 7, bug reports, community clamoring over CLAP, etc :slight_smile:

I’m wondering if there are more plans in place for community’s PR evaluation. Maybe that’s happening behind the scenes, or maybe there’s a plan to look through them post JUCE 7 release? The last communication was: critical fixes only + the team doesn’t want to be distracted by a lot of back and forth on code review.

Selfishly, I have a few open, so it would be helpful to know whether or not I should keep submitting those types of fixes and encouraging others to (it takes time to troubleshoot and prep them). Tangent: I might open a FR for a future JUCE release to focus only “quality of life improvements,” like the text editor usability issues I ran into, as I think that would be popular.

There seems to be some historical wariness on both the community side (nobody will look at it, not worth it) and JUCE team’s side (review burden, code quality concerns, varied bang for the buck). I thought maybe having a bit more communication might be helpful all around. I’ve kept this to Regulars only, as I think we’re all on a similar pages and can help out with setting expectations for others.

I’ve also been daydreaming a bit about whether or not the community can help the team relieve the burden in some way. Example: having a few members be on the “front lines” of responding to PRs, setting expectations, light code review around scope/style… I understand that coordinating something like that likely sounds like a hassle/risk and there might be a reluctance to involve non-core members to the party. But given the positive momentum of the CLA, perhaps this could keep things humming a bit when you guys are heads down.

Thanks for reading!


Yes, we’re all still busy with post-release fallout so responses to the forum are lagging a bit.

If a PR is more valuable than whatever is at the top of the JUCE team’s backlog then it will get looked at. Unfortunately the JUCE team’s time is very valuable, so we have to be careful that we’re focusing on things that deliver the biggest impact. Although PR’s will feel very important to their authors, that’s not a guarantee that we can justify spending some of our bandwidth to look at it.

I don’t think having people outside of the team evaluate PRs is a good idea. We typically have to rewrite the bulk of a PR, so getting minor things correct like style beforehand would be wasted effort. It typically takes a new member of the JUCE team 12 months or so of full-time work to get up to speed with good API design practices and writing code that meets our quality expectations. We cannot expect that level of reviewing from the public, and we don’t have the bandwidth to manage it.

PRs are still a good way of communicating the changes that you would like to see, and they may end up on our backlog, but we can’t provide any assurances about when, or even if, they’ll end up there.


Hi Tom,

Thanks for the response. It confirms what I suspected, but I appreciate the time you spent elaborating (especially given my post’s poor timing with the JUCE 7 release).

It typically takes a new member of the JUCE team 12 months or so of full-time work to get up to speed with good API design practices and writing code that meets our quality expectations.

This is understandable, especially with JUCE’s surface area and history. In a community open source project, it might take someone years before they’d be qualified to make API design decisions.

As someone building their livelihood on JUCE, my motivation is quality as well, with an emphasis on quality of developer experience and end user experience.

To use myself as an example: I spent a week of dev time on TextEditor before I felt it was “quality” enough that I would ship it in a paid product to users. I took the time to investigate, document and provide fixes for those issues. I got no response from the team on forum posts or PRs, so in the absence of information, my assumption is that widget UX is low priority. (Perhaps this isn’t true and it was partly bad timing with JUCE 7?) I walked away debating if the next time I should quietly fix on my fork or if it’s worth spending that extra effort documenting the details and prepping a PR. I’m starting a business and my time is also very valuable.

As you said, every company has their high priority pet topics. They all have JUCE forks with fixes and changes that are important to them. I think this is the biggest potential “feature” of community contributions. We can geek out and improve code quality in ways that a small core team just can’t make time for.

However, when small things like doc improvements don’t get contributed back, the codebase accumulates papercuts — bugs/improvements too small to be deemed worthy of prioritization, but add up to seriously impact dev/user experience. Devs duplicate effort, hunting the forum for issues first encountered years ago, chasing peers down to ask how they worked around things, etc.

Opening the floodgates to strongly opinionated devs pushing for their pet topics sounds like an absolute nightmare — especially given your existing backlog!

However, maybe there are improvements that are slow and safe, done in areas that the core team doesn’t consider high risk. Examples: Docs-only or small fixes only get reviewed. Assessing and responding to PRs could happen quarterly, or only between big releases. The widget library (or some lower priority module) could be broken out into its own repo and 10% of new team member’s time could be babysitting it as a trial. JUCE 7.2 could be “community focused” or a “little details” release. There are ways to limit impact to the JUCE team’s time while taking advantage of community contributions that would improve the developer experience and raise the quality of the framework itself.

Anyway, that’s my full pitch. Thanks for taking the time to read. It took me 2 years to feel “integrated” enough to clearly state these opinions, but this was the primary concern of mine when selecting and onboarding JUCE, and still on my mind re: “marrying” my business/future to JUCE (to be clear, the concern isn’t directly about the ability to contribute, but the quality of lower prioritized parts of the framework given its large surface area and small team). I understand and respect the JUCE’s team current position, and understand that it’s historically consistent. I wanted to explicitly bring it up in detail before I go heads down on shipping products enabled by this fantastic framework. I’m willing to make time available in the future to help with any effort in these directions, but consider my expectations set. Thanks Tom!


A little OT from the original intention maybe, but what stops you from deploying your own text editor as an external class to JUCE? I’ll certainly be happy to switch to a new one if you can make it available, especially if I can also have the original one for backwards compatibility.

1 Like

Good Q!.. I’ve rolled my own components for everything else, but decided to draw the line at TextEditor. Dealing with glyphs, caching, caret positioning, and especially multi-line editing/highlighting is pretty serious detail work. Building a replacement would mean getting sucked into it for many weeks…

Also, the current TextEditor feels pretty solid internally to me, it’s just in need of some UX attention, especially around cursor behavior and text positioning/highlighting. Like some of the other JUCE widgets, it would be great to see it get a facelift with modern defaults and attention to detail. I can always tell when an app/plugin uses JUCE as the current defaults (hard corners, lack of padding, vertical centering quirks) tend to “leak” through unless intentionally designed away — but it was no problem customizing it (outside of resolving the cursor papercuts).


I’m not suggesting you write all the code from scratch.
Unless what you’ve done involved forking something internal in the library, you can copy-paste your text editor and just call it with some other name, and then share it with other people - straight away.

I agree that having a nicer TextEditor would be great but changing my code to use NewTextEditor isn’t hard either…

1 Like

So far, I kept changes minimal to make them attractive to merge. I usually see copy-n-paste-n-modify as a last resort — things get messy and I’d lose the connection to changes upstream. I do like the idea of “pillaging” the official one to make an alternative implementation, I’ve done that with other components (usually to get rid of the look and feels and greatly simplify them). But I don’t have beef with the official TextEditor implementation outside of a few small changes.

I’m running a fork of develop (rebasing when pulling upstream so my commits always stay visible on top and the history isn’t polluted with merge commits). Others could add it as an origin and cherry-pick what they want into their fork (seems like a lot of people shipping products have forks already).

I walked away from this thread excited by this other idea I had when first starting with JUCE, which was to have a professional designer theme the widgets, tweak with community feedback and open source the implementation as sort of a “community theme” — my main concern is newcomers often struggle with git and JUCE modules are sort of “advanced,” but with good docs, could be a cool project…

Maybe i’ll open this thread up to the public unless there’s objections? Tom’s response was helpful, and this discussion was productive. I just didn’t want people to pile on about the PR stuff, as my intention was to diffuse not create tension.


Yes, that sounds good.

Generally speaking I don’t like the idea that JUCE is taking too much “stylistic” decisions both in UI and the flow of DSP/Plugin design.

Instead what I’d like is for JUCE to make it as easy as possible to write my own high level/stylish libraries on top, or use great community ones.

However, I would not like forking to be how I consumed those new style ideas. Forking implies that I now need to maintain the JUCE fork, and this is mental overhead that I would only go to as a last resort.

I personally even vote for all the “Widgets” to be moved in a separate library/module so that all you get with juce_gui_basics is Component and it’s support classes like Graphics.


Agreed on all points! For me, maintaining a fork is also sort of last resort-y before the true last resort of copy-n-paste. (The “community theme” idea was for a JUCE module look and feel with maybe some custom components/tools thrown in).

It would be cool to see widgets broken out as you describe, with a bit more of an ecosystem. But like you, I mostly end up rolling my own components. I’d love more tooling to accelerate that. I have a PaddedComponent, that lets one set sizes with padding, and lets the clickable area be larger than the content area, providing helpers like getContentBounds. And other similar things to support components with rounded corners, etc… interested in hearing what ideas you have.