Setting up Qt C++ for Maya

Hello. I was starting to use Qt for creating UIs for Maya but I confused how to start. I want to develop it in a plugin, all the UI and backend inside a plugin. I already have the environment in Visual Studio for developing plugins, so could I just include Qt and then start? I’m planning to design a UI in Qt Designer and integrate the code it gives me to the plugin.
I have found this but it didn’t help much.

Sorry, I can’t really help. But I can give you THE Annoying Forum Answer™ :smiley:

Why are you doing that?

In all truth, that’s an honest question. What structure do you have in mind that requires Qt as part of the plugin? I honestly haven’t come across a reason to use Qt in C++ for Maya. Every time I need to make a UI, I just write it in Python, and I haven’t come across any reason to do otherwise.

And make no mistake, “Because I want to learn” is 100% a valid answer


Hmm I wasn’t expecting that question because I thought this is not that uncommon and has an obvious reason, maybe there is something I don’t know.

My idea is keeping all the setup process at easiest level. If I code the UI inside the plugin too, everything will be easy as just loading a plugin. So it’s not just UI there is also a plugin and I wanted to merge them all. Also I like to code in C++ more, though the pain, and it’s faster.

Heh, fair enough. It also may be that I’m privileged to work someplace that makes distribution easy, so it doesn’t cross my mind. (But also, modules and .mod files are REALLY easy)
However, in my searches of github, I don’t remember coming across any projects that do the UI in c++. But I also know that I’m as susceptible to confirmation bias as anybody else :slight_smile:

That said, if you do the UI in c++, I have a request: Please don’t make it a tight integration. Don’t call unexposed computation functions from the UI, and don’t invoke the UI in the middle of your computation. Think of them as two completely separate projects. You can bundle them together in the plugin .mll/.so at the very end.

This will force you to build the API that your plugin actually needs, instead of the one that you think it needs. And personal experience has shown me that these two things are often very different. And since this is a forum for tech artists, it’s more likely that the people here would use what you write, should you open source it. And it will make it easier for you to update in the future should you want to change something.

Also I VERY HIGHLY recommend that you start using CMake to build your project. It creates Visual Studio projects that you can still use to debug your code, but it’s much easier to re-use, and it’s cross-platform.

I did a search on github, and I found this repo that seems like a short’n’sweet example:

Looks like the CMakeLists.txt file has these lines that I’m guessing do the Qt setup:

find_package(Qt5 REQUIRED COMPONENTS Widgets Core)

And it appears there’s an include for a .moc file in the .cpp code.

I’m willing to bet that’s about all you’d need.


Great, thanks for all! As my searches shown me too, it appears to be treating the UI as a separate Qt project and then applying it to Maya is the way. I may switch it to Python as well and process would be the same I think? I will start using CMake too.

One more thing:

I’m not that clear what you meant here.

If you build your plugin and UI at the same time, there’s a very easy trap to fall into.
Say you’re writing your UI, and you think of a really neat feature to add that requires some data from your plugin. In that situation, it’s very easy to include your plugin header, get your object from maya, cast it to your plugin class, and read its internal state to get the data. It’s nice and convenient, and it’s fast, but it kinda screws over the next coder that wants to mess with your plugin.
If it’s something that you needed for your UI, then that’s something that the next person would need for their UI, or the pipeline guy that wants to integrate it into an export process. But since you didn’t provide easy access to that data, they’re out of luck.

So what I’m saying is, don’t write that quick accessor. If you’re making a node, make sure that data is available on an attribute. Or make sure it’s available from a mel command.

Another trap that’s easy to fall into is writing logic that’s required for the plugin into the UI. That makes it very difficult for you to update the UI, or write UI version 2. Also, it can break maya batch mode (We recently ran into that one)

So keeping your UI and plugin separate forces you to think about how your plugin should be interacted with. What options and data should be exposed, and what’s the most convenient way to access and manipulate that data. And from personal experience, the ideas you have for that interaction before you start writing your UI can be woefully inadequate.


Thanks, I will consider it all.

1 Like

This thread is the closest to getting help on this topic, hoping someone has the secret knowledge.

I need the c++ Qt5 libs, and got things working in visual studio. Was trying to to convert the project to use cmake but I just can’t seem to get

find_package(Qt5 REQUIRED COMPONENTS Widgets Core) to work.

Tried every permutation of the docs

Maya ships with zipped Qt5 files under the devkitBase/cmake folder as well as the Maya2023/cmake folder. I’ve unzipped those and set them to CMAKE_PREFIX_PATH, but it just kept failing with path not found.

Any clues what I’m missing?

Got this working manually. Would be nice if this worked as expected with find_package.
Could it be that the bundled Qt5Config.cmake isn’t setup for windows?

# Set moc Path
set(Qt5Core_VERSION_MAJOR 5)
set(Qt5Core_VERSION_MINOR 15)
add_executable(Qt5::moc IMPORTED)

set(Qt5::Widgets_PATH $ENV{DEVKIT_LOCATION}/lib/Qt5Widgets.lib)
set(Qt5::Core_PATH $ENV{DEVKIT_LOCATION}/lib/Qt5Core.lib)
set(Qt5::Gui_PATH $ENV{DEVKIT_LOCATION}/lib/Qt5Gui.lib)