[Development] redistributing QPA and platform style plugins

René J.V. Bertin rjvbertin at gmail.com
Tue Apr 4 10:33:13 CEST 2017

On Monday April 03 2017 15:33:34 Jake Petroules wrote:

Thanks for all your answers.

>> Are there legal restrictions to making my modified versions available (say on github) other than maintaining the license headers and any licensing files? 
>In short, no. You know Qt is licensed under GPL & LGPL, right?

Yep. I just wanted to be sure.

>Actually, I'm working on making the platform styles into plugins right now, so it'll be very easy to build QMacStyle standalone once 
>https://codereview.qt-project.org/#/c/186909/ is merged. Keep in mind it'll still require a number of private headers, though.

Good new, thanks! I haven't looked yet but with luc that'll make it easier also to isolate the current style sources too (5.8). For the private headers I was thinking I'd include any of those that aren't installed in a complete install. Using private headers is acceptable for low-level plugins like this; the Plasma integration platform theme plugin also does that (and so does my Mac fork of that plugin).

>Possibly, if others contribute to your modifications, they'll also need to sign the CLA and somehow "co-submit" the changes to the Qt Project alongside you.

The only contributions I'm daring to hope for are ideas and opinions ;)

>On that note, why not upstream the changes immediately and make things better for everyone?

Others made similar remarks, and normally I wouldn't disagree. In this case I'm not sure:
- I've been getting a bit of an idea about what's upstreamable and my modifications might not be, or not in a form that I am happy with. In the latter case I'd still be wanting to make my own take available. FWIW, most of the modifications I make aim at improving what I call the "KDE experience" (where that cannot be done directly in KDE code).
- Providing modified Qt behaviour through plugins rather than patches to apply to the Qt sources makes it easier for others to use them, which in turn should allow me to present a more mature and tested concept if and when I decide to go for upstreaming. In an ideal world and all that ;)
- In addition, that modified behaviour becomes available *now*, and not in some more or less far-off future version. That also has a practical consideration for me personally: I don't have the resources to maintain a development Qt install with all dependents to test things properly.

The cocoa QPA plugin isn't very big (QMacStyle certainly not) so keeping a fork in sync with upstream developments shouldn't be very hard even when done manually at intervals. With that it might be possible to build and use newer/development versions of those components with a Qt release version, no?


More information about the Development mailing list