[Closed] Qt, or not Qt, that is the question

MaxPlus is going away in Python3.
So, now it in pymxs only.
I want to know more about what;’s bad in this implementation and what u want to see to be better.

Too, i don’t understand the problematic with “Qt python binding” ?

It’s standard pyside2 with little helpers fonctions for docking in 3dsmax ui.

You can use “its power to the fullest”.
You have the only choice if you use standard python implementation or PySide implementation for somes features like XML, network or other base filesystem access. But it’s like other developpement with PySide, embedded or not.

(i’ve give my opinion : use maximum standart python lib, and use Qt only for UI )

First of all, I have been using Qt for many years. I have many tools created using Qt for different platforms.

I never liked the fact that 3DS MAX simultaneously uses many different user interface solutions: Win API, .NET Forms. WPF, Qt and others … This made its appearance ‘ill-conceived’ from a design point of view and unprofessional.
Now we have Qt, and theoretically everything can be streamlined, back to order and standardized. But…

To begin with, the plug-in part (everything related to Param Blocks, SDK objects and Interfaces) still relies on the Win API (and you should not be confused by the fact that it looks like Qt, because it is just drawn with Qt graphics). Such use of Qt deprives us of the opportunity to expand and ‘enrich’ the user interface with the help of built-in Qt (UI) solutions.

As I have already said, the most effective method for developing tools for 3DS MAX from the point of view of productivity is programming the algorithmic and system parts of tools in the C ++ SDK, and the User Interface part using MAXScript.
And everything was fine until Qt was included in the process.
To be honest, the existing bridge between the 3DS MAX SDK and Qt is very flimsy and miserable. And Python, which could connect them (as was done, for example, in Maya), is too primitive in terms of working with the system. In fact, this is the same MAXScript.

And then the question arises – What to do?

First of all, I want to exclude .NET and WPF from my tools. If with WPF all is easier, because I did not particularly abuse it, but rather just experimented, following the fashion of the time; then .NET sits very tightly in many of my tools which required an intensive and advanced interface.

Since I simultaneously design and develope tools for 3DS MAX and Maya, I have solutions for certain User Interface tasks using:

• [C# + .NET] (MAX)
• [Python + Qt] (Maya)

And now I am at a crossroads and I think – should I “wait for mercy” from Autodesk, or make my own “quick and simple” bridge between MAXScript and Qt using the C ++ SDK?

and here is the confirmation of my reasoning –
multilistbox

this is an example of how built-in and ready-to-use solutions in .NET Forms or Qt can easily help with creating and working with UI control such as LIST, where an alternative rollout control’s solutions are very limmited.

Since 2017, all new features added in Max has native Qt UI.
Win32 is here to stay for 3rd party plugins.
All max built-in UI will be ported to Qt eventually.

If u want unified look of it, you can go with Qt.
I still stick to dotnet. Look doesn’t bother me much.
If it is production tool,XS UI is more than enough for me.

Why do you think so?
You can go and check that all Modifier Panel controls are still Win32 (try MS Spy++ for example to see)

Hmm… how about docking .NET dialogs to MainMax?

regardless of what max do with their interface… as it’s a windows box you’re always going to have the full range of windows controls to choose from use/not use via the sdk or .Net. What you get via MXS is probably going to be most tied to QT