C++ SDK vs. QT

istan · ‎10-22-2019

So what's the deal with QT? As far as I found out, it just makes development more complex. Still the ParamBlock and the Get/Set functions are required. Just the dialog designer is different, but requires to connect all QT controls by hand additionally. What am I not understanding? Shall QT just "fix" the dialog control scaling for Quad-HD monitors?

Anonymous · ‎10-22-2019

What would you suggest as a unified UI Framework for 3dsmax instead?

denisT.MaxDoctor · ‎10-22-2019

All MAX built-in user interface is still windows API. Only controls are drawn now by Qt graphics. It just helps to make built-in UI and custom UI (made via Qt or Rollout controls) look similar.

istan · ‎10-22-2019

I was only curious about finding a serious reason to port my plugins to QT, but I did not (yet) find one.

Additionally the QT license issue is not fully clear to me: since I'm using just the Open Source QT license, do I have to distribute my source code then?

denisT.MaxDoctor · ‎10-22-2019

@istan wrote:
I was only curious about finding a serious reason to port my plugins to QT, but I did not (yet) find one.
Additionally the QT license issue is not fully clear to me: since I'm using just the Open Source QT license, do I have to distribute my source code then?

if your plugins were written using 3DS Max SDK, you do not need to port them to Qt (they are automatically Qt drawn).

if you use Qt with MAX, you do not need to show your source code. Only after Autodesk does this 😉

drew.avis · ‎10-23-2019

There are lots of reasons you might want to port to Qt, the big ones are to support high-dpi display scaling, and to re-use your UI on other platforms/DCCs. Qt Designer makes it pretty easy to design complex UIs. There is also a lot of other useful functionality in Qt (networking, XML parsing, etc) that you might find useful. New UIs in Max are 100% Qt now (eg Fluids).

However, there's no requirement to port your plug-in if you don't find any of those reasons compelling.

Drew

Drew Avis
Content Experience Designer

denisT.MaxDoctor · ‎10-23-2019

@drew.avis wrote:
New UIs in Max are 100% Qt now

Could you clarify, starting with which version and what does “100%” mean? Thanks

Anonymous · ‎10-24-2019

@denisT.MaxDoctor wrote:
@drew.avis wrote:
New UIs in Max are 100% Qt now
Could you clarify, starting with which version and what does “100%” mean? Thanks

I guess he meant all NEW UI`s like the UI for the Fluids feature, or the new Chamfer modifier, DataChannel modifier and so on.

istan · ‎10-24-2019

@drew.avis wrote:
There is also a lot of other useful functionality in Qt (networking, XML parsing, etc) that you might find useful.

Honestly, if I would not already use proper libraries for the stuff you mentioned (and a lot more), my company would have locked up.. 😉 QT might be nice, but as a long time Borland user, I was probably expecting more of automated code creation (UI control -> EventHandler -> ParamBlock -> Getter/Setter -> CfgFile ->..)

istan · ‎10-24-2019

There's also a discussion on the beta forum about porting to QT..

denisT.MaxDoctor · ‎10-27-2019

@istan wrote:
There's also a discussion on the beta forum about porting to QT..

could you add a link, please?

denisT.MaxDoctor · ‎10-27-2019

@drew.avis wrote:
New UIs in Max are 100% Qt now.

what is the difference of how MAX UI is made for version 2018 vs 2019+ ?

For me "100% Qt" is when all controls and dialogs in built-in max UI are QWidgets.

istan · ‎10-27-2019

@denisT.MaxDoctor wrote:
@istan wrote:
There's also a discussion on the beta forum about porting to QT..
could you add a link, please?

"Scripting" / Topic: "some notes about porting plugins to Qt"

In addition to my own investigations, it affirms my decision not starting with QT in max, as I have no time for such beta tests. I usually look for quick workarounds and honestly, I also gave up reporting everything, as most of these bugs AD is not fixing anyway. They probably have higher pressure on adding new features with new bugs instead of making the current status working first..

denisT.MaxDoctor · ‎10-27-2019

@istan wrote:
In addition to my own investigations, it affirms my decision not starting with QT in max

after a lot of experimenting with different UI solutions (.net forms, wpf, Qt, etc.) i decided to use only built-in Rollout controls + my own extensions of them. I think that Autodesk must provide their correct display for any screen resolution and monitor type. I don't care how built-in user interface looks like - good, bad or ugly (but would be happy to see them nice). I just want that my tools look the same as built-in.

drew.avis · ‎10-28-2019

@denisT.MaxDoctor wrote:

what is the difference of how MAX UI is made for version 2018 vs 2019+ ?

For me "100% Qt" is when all controls and dialogs in built-in max UI are QWidgets.

We're not there yet. New features / UIs (in general) are now in Qt, but older UIs have not been converted from Win32.

Drew

Drew Avis
Content Experience Designer

denisT.MaxDoctor · ‎10-28-2019

@drew.avis wrote:
We're not there yet. New features / UIs (in general) are now in Qt, but older UIs have not been converted from Win32.

so it means that about 10% of the recent MAX UI is true Qt 😉

Honestly, I am terrified of what will happen when the entire ParamBlock <-> Rollout interface is rewritten to Qt 😶

As a bit of a nightmare, I imagine about continuity of development and at same time supporting of old versions in this case.

istan · ‎10-28-2019

@denisT.MaxDoctor wrote:
@istan wrote:
In addition to my own investigations, it affirms my decision not starting with QT in max
after a lot of experimenting with different UI solutions (.net forms, wpf, Qt, etc.) i decided to use only built-in Rollout controls + my own extensions of them. I think that Autodesk must provide their correct display for any screen resolution and monitor type. I don't care how built-in user interface looks like - good, bad or ugly (but would be happy to see them nice). I just want that my tools look the same as built-in.

In my case, it is exactly the opposite. My users use my interface dialogs and almost nothing of what is built in in Max. I use scaled 3dsmax spinner controls on non-modal 3dsmax rollout dialogs. But since QT all dirty written code is causing troubles again..

istan · ‎10-28-2019

@denisT.MaxDoctor wrote:
Honestly, I am terrified of what will happen when the entire ParamBlock <-> Rollout interface is rewritten to Qt 😶

I am not afraid of as this task will take decades 😉

denisT.MaxDoctor · ‎07-14-2020

@drew.avis wrote:
There are lots of reasons you might want to port to Qt, ... Qt Designer makes it pretty easy to design complex UIs. There is also a lot of other useful functionality in Qt (networking, XML parsing, etc) that you might find useful. New UIs in Max are 100% Qt now (eg Fluids).

If all new MAX versions are “100% Qt oriented”, where can I find an example of creating a simple QWindow using c ++, Qt libs and the MAX SDK?

istan · ‎07-15-2020

hehe.. already asked several times, but even I will not start using QT for my plugins. Since the QT implementation is more or less just an "addon" to the plugin development, it makes development slower and there is no real benefit for my users (they are willing to pay for). For all other dialogs I'm a lot faster in using dotNet or if I need it more flexible I'm using MXS dialogs.

C++ SDK vs. QT

C++ SDK vs. QT

Forums Links

Post to forums