@swt2c maintains wxGTK in Fedora, and he may be able to provide insight on wxWidgets packaging work for offering wxQt in Fedora too.

I was gonna ask, on a scale of 1 to 10, how difficult is it to package it?
1 = ez, 10 = chromium

I was debating about whether to package wxWidgets 3.3, as it is an unstable release (we'd need to keep wxWidgets 3.2 as well). But at the very least, it probably does make sense to build wxQt from the same source package as wxGTK. Are there end user packages that are interested in building against wxQt?

I was debating about whether to package wxWidgets 3.3, as it is an unstable release (we'd need to keep wxWidgets 3.2 as well).

It doesn't seem like there's that much difference these days, and even wxWidgets upstream acknowledges this.

But at the very least, it probably does make sense to build wxQt from the same source package as wxGTK.

If we do this, then probably the source package should be called wxWidgets instead of wxGTK. It might be useful to do that anyway so we could have MinGW packages (wxMSW) built from this source package too.

Are there end user packages that are interested in building against wxQt?

Not really sure. I think potentially a candidate in the future would be KiCad, maintained by @stevenfalco.

The main reason to offer it is so that people developing wxWidgets applications would be able to consider it at all. Right now it's realistically not a option even for developing new applications since nobody has it.

The main reason to offer it is so that people developing wxWidgets applications would be able to consider it at all. Right now it's realistically not a option even for developing new applications since nobody has it.

Somewhat like I've explained at https://forum.qt.io/post/830271, I am one of those who chose Qt over wxWidgets due to this.