QT distribution

Has anybody got an efficient, low-maintenance way to distribute QT ui for users (in my my case, with Maya 2011)? In particular, what is the absolute minimum set of files I need to distribute for my users to be able to consume QT gui in maya?

Quick answer, you are not legally allowed to distribute Qt to your users. You must have a commercial license for that. Your users must install the open source version of Qt for themselves.

just make a stand alone widget and keep deleting stuff until it breaks. Translations, docs, samples, some SIP stuff, plugins, some exe files (e.g. linguist.exe, designer.exe) can be deleted from what I remember. We’ve done this for internal studio use. I’m pretty sure we’re not alone because I remember quite a few clients giving us their Qt versions with their tools.

About Qt distribution - From what I’m aware you can distribute Qt itself (PyQt is a different matter since it’s GPL) just fine unless you use a statically linked version. Qt is LGPL. In the worst case use PySide which is LGPL too and pick the pyd and dll files required. I heard it works with Maya 2011. And as far as I know there’s no clause that requires you to distribute a complete Qt version either. It’s totally okay to remove items that are not needed.

http://stackoverflow.com/questions/8534964/requirements-when-distributing-a-commercial-application-which-is-dynamically-lin

Bryce on our team distributed the whole thing into a site-packages folder that each project branched. It was a lot of files (too many…), but once there we could distribute pyqt tools with ease, as everyone had what they needed. People were annoyed when they first synced a project, but new tools from there on out were only 1-2 files.

Don’t let Digia or PyQt legal departments read this forum. You guys would be in trouble.

If “your users” is company internal that should not be a problem, no?

http://www.gnu.org/licenses/gpl-faq.html#InternalDistribution

You seem knowledgeable, yet you’re not really offering answers - care to elaborate for everyone’s benefit?
I would be interested to know how the LGPL\GPL conflicts with common practice in the CG industry when it comes to Qt, PyQt respectively.

For the immediate future I’m not sending this out of house, although I try never to do anything I could not.

<IAmNotALawyer>

QT itself uses the both GPL and LGPL. I’m using the LGPL version, which means I can distribute the binaries as long as I don’t modify them and include the appropriate legalese and the info needed for users to compile it for themselves (usually, a link or email address they can use to get the source). Using a python PYD under LGPL license is not a case I’ve seen talked about much, but the most common opinion I’ve seen (not from lawyers of course) is that using binaries as-is (they way I’d use the QT Pyds) imposes no obligations on the rest of the project. On the other hand compiling a new binary with statically linked QT code would trigger the GPL and require open sourcing.

PyQT is GPL or commercial: if you use the GPL version, you _must _ distribute source with the application. I probably can’t do that mostly because I’m too lazy to get the legal permission from The Man. I’m not planning on selling our toolset, however, and if it were up to me I’d open source it (under a less annoying license like MIT or Berkeley) just so other people could help me improve it – but it’s not a primary issue for me. I’ll happily buy the commercial license if/when this particular bit of code goes out of house; i’d assume that (since I’m not planning on touching the source code for PyQt unless something nasty crops up) that I’d go with the ‘Embedded license’ Relevant quote:

In particular, providing copies to contractors for use off-site is distribution.

</IAmNotALawyer>

License issues aside…

Do you have a centralized way of managing python paths? If so, typically what I’ve done is package all of the QT stuff up into its own directory with this pattern:

Qt-4.7.1\
    bin\
    Lib\
    plugins\
    sip

I then ensure that <QtRoot>\bin is in the PATH and <QtRoot>\Lib\site-packages is in the PYTHONPATH. Everything then seems to work for the users.

I’ve got it working with my usual distribution setup, which unloads the binaries more or less they way you describe into a folder in the user’s maya project and adds the folder to paths with site.addsitedir. Surprisingly it worked the first time :slight_smile: