#QT6 Support

1 messages · Page 1 of 1 (latest)

sly wind
versed flame
#

How possible is it to get the 3p package usable locally without dealing with the CDN lol

#

oh cool its in your 3p PR

sly wind
versed flame
#

I know @pulsar pecan was looking into getting the 3p working with macos and linux too

sly wind
#

But then you need to link your local QT build against o3de, without going though a zip file, I believe I saw some doc about that in the 3p repo

#

Simplest way might be to nuke and replace the content of .o3de\3rdParty\packages\qt-5.15.2-rev7-YOUR_PLATFORM

versed flame
#

yeah, for me id need to see how building the wayland support of Qt works in qt6 since i think its still separated

#

i think in the newest versions of 6 they merged it into their normal qtbase repo

#

yeah its not in the 6.9 branch lol but its in dev so maybe in 6.10 lol
oh 6.10 is a released version and yup its there

pulsar pecan
#

I can start looking into Mac support sometime next week

wild obsidian
#

Following as I'd love to get back into working on the editor and help with styling, but I don't have time in the short term 🙂

midnight scroll
#

Hey guys! I've done some work on the 3p packages for mac arm support, and QT is one of the places where things just break down for me as well. (That and oddly enough python?)

Not really a comfortable C++ developer at this point, but working at re-learning modern C/C++ syntax.

sly wind
#

As I had to do a fresh linux dual boot I started to test QT6 branch on Linux. Currently fixing o3de code, and currently only builds as non-unity. There is some work remaining, when it builds I'll update the PR with build instruction to test on linux

pulsar pecan
#

I started looking at the mac build (on mac silicon) for the qt package. I mostly changed the original way we built qt5 to follow what was there for linux (setting the platform to macx-clang) and everything seems to have been built. I havent taken a deep look at the results yet, and haven't looked at the need to update thr RPATH values in the built binaries like we did before, but will take a deeper look at this later this week

sly wind
#

I don't know if we'll still have to use docker for the cross build for arm devices, got rid of it for now for easier setup

pulsar pecan
sly wind
#

Fixed remaining compile issues on linux, now I'll try to link and run with xcb

sly wind
#

Fixed most of the styling without the need for any custom QT changes or access to private classes !

versed flame
#

Awesome, it would be nice if we could get wayland building in the 3p package before it gets merged into main if possible

opal osprey
#

finally found the magic, any word on compilation on windows, how the libraries looking now (havent looked at the code properly) trying to trim out and replace anything i can on windows end that got microsoft in it with open source

im not sure where discussion about qt6 was at, and im not sure if it was brought up (brain tired been working all day )

but how far does the support go, i think i remmeber reading part of the engine was in qt not all of it, and it needed parts of stuff to be ported to work, (mayeb somethign abotu qt6 gem, i forget exactly)

#

love the features requested so far, i have nothign else to add, looks perf to me atm

stark fern
#

Qt is only part of the editor toolset, it is kept entirely out of the runtime client/server that you would ship to game players

sharp adder
#

Hey, trying to build the qt6 branch on linux, but none of the servers return the at 6.8.0 library. Is there anything else I need to do?

sly wind
sharp adder
#

Awesome, I'll take a look at it tomorrow

sly wind
#

@versed flame the CI is building the wayland package by the way, not used by our cmake files but at least you won't have to bother to rebuild QT

versed flame
#

My system is locked to podman so i cant really run docker stuff so thats really helpful

#

I'll try the qt6 changes then :)

versed flame
#

Trying to figure out why im getting this error on the qt6 branch:

--   Using package /home/drogonmar/.o3de/3rdParty/packages/qt-6.8.3-rev1-linux

.....

CMake Error at /mnt/Shits/o3de/cmake/LYWrappers.cmake:716 (message):
  You must provide at least a file to copy
Call Stack (most recent call first):
  /mnt/Shits/o3de/Gems/LmbrCentral/Code/CMakeLists.txt:135 (ly_add_target_files)

debugging the cmake script it seems to stop at LmbrCentral.Editor

#

ahh what was the reason for commenting out lrelease_linux.cmake ?

#

Ahh gets stuck in a inf loop if i uncomment it lol

sly wind
#

Skipping it and its calls should be done I'm surprised you run into a configuration issue, will try on linux again tonight been 2 weeks last i tried

versed flame
#

yeah like it says it wants at least a file to copy

#

patching out the effected ly_add_target_files in LmbrCentral lets it continue but its still stuck in a inf loop

stark fern
#

"You must provide at least a file to copy" usually means that a variable is empty

#

like its calling a function like file(COPY ${somevar} ${some_other_var}$) but one of those 2 is empty or unset, so it resolves to file(COPY xxxxxx) but expects 2 params

sly wind
sly wind
#

Hmm maybe because wayland is enabled on this qt build, we have the uic executable which tries to load libicui18n from qtranslate that we don't build

stark fern
#

most linuxes have lib icui18n available, e.g. apt get libicu-dev or whatever
on windows though, we'd have to grab and build it ourselves

#

alhto prveiously we used the -no-icu flag in our docker qt build

#

its possible we need a diff library now to build on windows, but I'd be okay with adding libicu (from package manager) as a dep on the install / setup instructions on linux

opal osprey
sly wind
#

Its a third party package which every editor module depends on

sly wind
#

QT6 running smoothly on linux X11, readme updated it should be straightforward for anyone to test it out

image.png
past grove
#

Crazy awesome work!

sharp adder
#

Got some new warnings (as errors) with clang 21 so I'm temporarily disabling -Werror on my end but after a bunch of effort it's finally building 😄 I did have to replace the hash of the qt6 artifact.

#

nevermind... an enum unit test is failing for some reason.

#

Might chalk it all up to clang but I hope not

sly wind
#

Yeah unit test building on linux clang fails for now because of qpalette, but shouldn't prevent building the editor

sharp adder
#

Will have to take a closer look when I have time later today after work

versed flame
#

I tried going through the steps but my cmake still gets stuck, tried deleting the old 3p package too just in case

#

my cmake options are pretty basic, just using ninja multi config and turned off unity build

sly wind
#

So for the configure issue it seems super random, re-configuring after that it got stuck makes it work, and its linux only, will have to repro to see where it occurs and why its random. And yeah non-unity build fails must have some missing include that I'll fix (but unity build works)

sharp adder
#

I got as far as it compiling and even launching the project browser, but the editor itself just refuses to open, even with the all of those additional files copied over

sly wind
#

Just fixed the unity build on linux and added more details into the PR "how to test" section. Yet weirdly enough in non-unity build main viewport does not render, don't know if its something in my setup

sly wind
sharp adder
#

I'm not launching the editor directly, just ./o3de

#

also, the hamburger menu for projects has an invisible background, so it seems there's quite a bit wrong with my setup still

#

Tried to follow the current steps 😅

sly wind
#

There are things like this all around which will have to be looked at before opening a PR

sharp adder
#

I managed to get the splash screen going launching the editor with a project path

sly wind
#

Thanks for going into the trouble of testing btw 😄 Its still rough but thanks to feedbacks like yours we'll polish it all

sharp adder
#

but then I get a SIGSEGV 🙂

sly wind
sharp adder
# 
<00:56:51> [Plugin Manager] Successfully loaded plugin 'QtAssetImporter', version '1' (GUID: {0abf28f2-ef56-4ac9-a459-175abb40d649})
fish: Job 1, './Editor --project-path /home/g…' terminated by signal SIGSEGV (Address boundary error)
sly wind
#

Building the editor target will only bulid barebone editor

#

Whereas if you target editor and cmake was configured with a project, it will build the project gem dependencies as well

sharp adder
#

Seems there's quite a bit that broke from trying to upgrade qt eh?

sly wind
#

(added it all in the readme)

sly wind
sharp adder
#

well that's a step in the right direction, at least

#

I'm hesitant to try to fix issues I'm finding with the main qt5 editor considering this thing will basically replace it eventually

#

but it seems it's a fair ways out

#

Qt is such a pain to be honest 😅

sly wind
#

It has its quirks yeah but all UI framework have, at least its stable and performant enough that many game engines editor are built with it

sharp adder
#

It's a shame something like rmlui isn't more widely adopted

#

Speaking of qt5 issues, I haven't opened a ticket for this because I haven't dialed in what's causing it, but the color picker breaks saving the level 🙃

#

It seems like such an odd thing for these two to be somehow tied together

#

I was hoping to get the qt6 branch running to see if that just resolves itself on my system. Seems it'll be a bit until I figure out how to properly set up the editor build still

sly wind
#

Qt6 port is more bound to break things rather than repair them 😄 something invalid in qt5 is also invalid in qt6, but it also mean fixing the issue right now in qt5 version, your fix will still be valid in qt6. Its very rarely an issue of qt but rather the code calling it

sharp adder
#

Alright, I'll look further into it then

sly wind
#

Just fixed all non-unity build issues for all modules

broken grail
past grove
#

I think at this point the effort to replace the UI for the editor would be absolutely monumental, and definitely doesn’t Trump the animation or getting rid of slices in game UI. It’s a tough balance for sure

broken grail
#

Qt is fine. Its probably not the absolute best, but others suck too, and a rewrite has to yield a very sizable difference to make it worth.

#

Defold has its editor written in a very fancy wrapper around JavaFX and in Clojure.

It's not that Clojure is a bad language for this, and still, they don't find people to maintain it.

Now you can look for other UI toolkits for popular languages that find someone like Guillaume to update them.

GTK is an even greater pain, and less cross platform compatible.

I would have personally chosen QML instead Qt-Widget, and that's about it.

Everything more fancy and you will find it hard to attract contributors.

#

The custom Qt modules already proved to be a roadblock for this update, and if I followed the conversation correctly, might the update happened way earlier without them (or would at least have been attempted earlier)

Now imagine the whole system 'custom'

opal osprey
# broken grail The custom Qt modules already proved to be a roadblock for this update, and if I...

This, pointless to code a whole system, if we can just wait on people to implement base standard, with gems and all we can go nuts with other systems

Qt platform currently only one I can think of that can in theory support machines as old as 2000. Not really useful for dev, but we gonna see smaller games on this that might wanna target lower end not available for whatver reason, and qt6 easiest jumping off bridge in middle between bleeding edge and supporting low end

wild obsidian
#

Qt platform currently only one I can think of that can in theory support machines as old as 2000. Not really useful for dev, but we gonna see smaller games on this that might wanna target lower end not available for whatver reason, and qt6 easiest jumping off bridge in middle between bleeding edge and supporting low end
Qt is only used on the Editor side, not on game builds. So I don't think there's any relation between upgrading to Qt6 and support for games targeting lower end hardware for their finished product.

stark fern
#

Yeah, we have very carefuly kept certain things out of the runtime dlls and such, qt is one of those. the actual game runtime that is built has a much lower req than the editor on the developer end.

opal osprey
opal osprey
stark fern
#

The engine runs on fairly low hardware, (the games, I mean), but the tools require a lot more compute since they're doing things like compressing huge textures and stuff

#

things like loading in a lot more data, for example, an entire level, when the game might stream just pieces in it. Dev hardware is always bigger than gamer hardware

opal osprey
# stark fern things like loading in a lot more data, for example, an entire level, when the g...

That's true, I think disconnect happens when folks jump from blender to o3de and they end up of making games or on roblox, need to run way more profiling to see what's up.

But thays probs for another chat. Cut down portable editor has a place beyond low end rigs, artists who mostly export assets for example dint need most code stack, baked down materials to a preset and they csn dress up a whole level for rest of team to palce code in

south mica
#

As a random note: someone who wrote an bgfx-based game engine, wrote the tools using Vala+GTK.

stark fern
#

I think Qt is being used primarily here due to momentum. theres an enormous amount of UI code to rewrite if you want to convert to something else. Every single dialog, every single control like the outliner, animation editor, spline editors, all of that stuff.

#

I'd actually prefer something like blender, unity, or etc approach (render ui using native renderer, directly.). Not necessarily immediate mode UI, although it could be, but something where the whole window is the renderer. Not some parts some other sceheme. However taht is just a dream becuase there is so much code and converting UI code to other UI code that looks the same is the least glamorous job out there

tardy ledge
#

Nice to see the progress, hope no customization is needed anymore.

versed flame
south mica
tawdry crater
#

But is QT a bad choice? I know many KDE programs uses it, although there may be a wrapper.

tawdry crater
versed flame
#

I dont think its a bad choice, but in my opinion its really nice when an engine uses the same gui system that you use in your games since you dont need to understand two separated systems

#

theres not really much to talk about with this unless someone REALLY wants to do the work of making a gui library or integrating one that uses the RPI/RHI better and replace all the editor tools with it

#

other than that were just talking about something that wont happen anytime soon

tawdry crater
#

I see

versed flame
south mica
sly wind
# tawdry crater But is QT a bad choice? I know many KDE programs uses it, although there may be ...

My 2 cents is that moving to QT was an excellent choice from o3de team back in the day and would still stand today, as your in-game ui framework has radically different purpose and usage as your tooling ui framework.

in game ui:

  • must be as fast as possible and take as less memory as possible
  • must support crazy animations
  • you might want to have it as much data based (could even be node based) for users to jump in
  • if you're not making europa universalis you won't have to support crazy nesting or huge tables of data
  • can contain hack only for your game

Tools ui:

  • must be as stable as possible for as long as possible, some code can be 10years old
  • should support a crazy amount of data easily (content browser with tens of thousands of assets)
  • similarity to other engines is best to recruit tools dev (forstbite, starengine, insomniac and many other uses qt, snowdrop uses a custom thing very close to qt)
  • you're not so tied to memory consumption or supper low budgeto
  • content is mostly static, but you will use specific data visualisation stuff
#

It's cool to see the trend of imgui editor but I'm waiting to see if it can really have the complexity a AAA engine has without huge drawback (I heard that the metro exodus people are moving from wpf to that so waiting to see their feedback)

opal osprey
# sly wind It's cool to see the trend of imgui editor but I'm waiting to see if it can real...

hard agree on that, personally i dont think tools that are used by non coders should follow the same logic as tools for those who do

What i mean by that

qt6 is in everything, as long as engine looks roughly like any other program in qt6, its one step less for someone to figure out the engine better

untill imgui can match versitility of actual analog user interfaces, i dont know how it could be made to work for us without someone spending atleast 300 hours of dev time, figuring out how to make imgui now be confusing to newer users

stark fern
#

the original move to qt had not real choice, the original app was a Win32 MFC app and it needed to become cross platform. A certain contracting company had heaps of experience in converting win32 MFC apps directly into the identical Qt app and was contracted to do that.

#

there wasn't like, another company that would be contractable at the time that woudl for example move it from win32 MFC to say, imgui

#

the move still took that expert company something like 4 people full time half a year ish (? its a long time ago, decade or more, so I can't remember fully) to complete it, since theres just so much code, in case somoene wants an idea of the magnitude of what it would mean to move it to some other ui toolkit (and they were paid)

flint shuttle
#

My personal opinion to this topic would be :). The fact is, you can’t really compare Qt with ImGui. Qt is a professional framework used in countless commercial and open-source applications, while ImGui is great for quick prototyping and development tools. O3DE is intended to be a AAA game engine (at least that’s what I hope for it), capable of competing with engines like Unreal and Unity. Using ImGui as the main UI framework will never achieve the same level of complexity or visual fidelity. None of the major AAA engines use ImGui for their primary interfaces. It’s typically reserved for debugging tools and developer consoles.
Nerveless, yes the current usage of QT with all the custom modifications in O3DE is not perfect, so in my point of view as O3DE community we need to fix those instead thinking of a full rewrite which would be just waste of time.

sly wind
#

Back on the topic of the QT6 state in o3de, these are the remaining issues 😅 There might a ton more that I haven't discovered yet, given that the upgrades broke existing hacks and do not contain any custom Qt6 code which some path required

  • ❌ Renderer for EMFX window is not rendering anything
  • ❌ Floating window are not hiding the OS Toolbar (o3de uses a custom toolbar, and doing so hides the OS-one)
  • ❌ With 2 monitors, when expanding floating window while on secondary monitor, window is lost (can be retrieved by clicking on it via the toolbar again)
  • ❌ On linux, jump into game not currently working (there is a QT6_TODO for that in the X11 code, just need the code to grab the X11 handle)
  • ❌ linux cmake not currently copying required X11 files (need to do so by hand)
  • 🪲The text next to the spinbox (X, Y, etc) is not draggable with the mouse
  • 🪲Scriptcanvas node styling falling appart when node is hovered (likely a missing condition in .qss file)
  • 🪲Window minimize and expand icons do not change when hovered (no white background as usual)
  • 🪲Qt translate still not built on the CI as it is a pain to build
  • 🪲Alignment of QMenu items and dropdown arrow next icon is not correct
  • 🪲Scrollbar background is not transparent when not hovered
  • 🪲Drag and drop in one tableview of EMFX needs to be ported so that it don't require accessing private QT class (ParameterWindowTreeWidget::dropEvent)

Any help is appreciated !

image.png
versed flame
#

is there a good reason to send X11 events to the existing XCB input classes or could we just have QT input classes and use that instead?

#

i dont think Qt's wayland handling will let me dequeue wayland wire RPCs so i was gonna look into making a new type of input device for o3de that uses qt

sly wind
sly wind
versed flame
#

yeah, the reuse of the input code for the game launcher doesnt seem great for what ill need to do

#

the idea ive had from the start from looking into editor support was just having Qt input devices that the viewport just forwards over

#

without care of what QPA is under the hood

#

libwayland (pretty much the implementation you have to use) uses callbacks instead of events that you dequeue

#

the main reason callbacks are used is because things like surfaces, seats, input devices have object Id's so those callbacks are tied to a obj id.

#

ive implemented the wayland wire protocol and while in theory it could be possible to intercept these RPC's its not gonna be as simple and robust as just having a Qt o3de input device

stark fern
#

❌ Renderer for EMFX window is not rendering anything

EmFX integration has always been a little weird since it was a seperate app and got merged in. not surprised...

#

Any help is appreciated !

How can I help? I do have latest ubuntu installed at home (travlling at the moment tho)

flint shuttle
#

maybe I can help out here too on Linux. I can checkout the branch. Is it the qt6 branch?

versed flame
#

instructions here

#

and yeah the qt6 branch on the main repo

#

trying to build the branch again, i did a fresh clone and still getting the bug where cmake cant finish running

#

my cmake options are -G "Ninja Multi-Config" -DCMAKE_C_COMPILER_LAUNCHER=ccache -DCMAKE_CXX_COMPILER_LAUNCHER=ccache
cmake version: 3.31.6

Deleted the old qt6 package in my .o3de dir, refreshed the Qt6 package with the latest build in the PR too

flint shuttle
#

i do have the same issue. cmake hangs creating project files

versed flame
#

good to know im not the only one 😅

flint shuttle
#

but you couldn't solve it?

#

having this message:

CMake Error at ~/.o3de/3rdParty/packages/qt-6.8.3-rev1-linux/qt/lib/cmake/Qt6/QtPublicCMakeHelpers.cmake:185 (cmake_parse_arguments):
  Maximum recursion depth of 1000 exceeded
Call Stack (most recent call first):
  /home/yaakuro/.o3de/3rdParty/packages/qt-6.8.3-rev1-linux/qt/lib/cmake/Qt6/QtPublicCMakeHelpers.cmake:215 (_qt_internal_collect_buildsystem_targets)
#

seem to have a recusive whatsoever issue 🙂

versed flame
#

yeah, i debugged the cmake project and saw the recursive function too

flint shuttle
#

can't we use qt 6.9 🙂

sly wind
sly wind
sly wind
flint shuttle
#

Ok. I will have a look if I can find something why we do have that issue.

#

Btw. Are you building the engine from its root directory or a project pointing to an engine

sly wind
flint shuttle
#

mmm, fun is, when i run:

cmake -B cmake-build debug -DCMAKE_BUILD_TYPE=Debug

within the root directory of the engine the build system runs normal.

#

when i try to run to configure my project one, then we do have this recursive issue

sly wind
flint shuttle
#

O3DE on the qt6 branch on Linux.

image.png
wild obsidian
#

Floating window are not hiding the OS Toolbar (o3de uses a custom toolbar, and doing so hides the OS-one)
I would argue for the removal of the window toolbar customizations, if possible. There's not a ton that was done with them that isn't the default OS behavior IIRC, so if we could just restyle to use the default windows and have it look ok, it would probably save us a lot of hassle.

sly wind
wild obsidian
#

🤔 admittedly I was just thinking of the main windows, that's right for the floating tabbed windows... I should know since I implemented that lol

flint shuttle
#

I've found the issue for the black render viewport in EMFX. Just working on the fix. At least one part. Here on Linux

image.png
#

Some widgets in the TimeView using QOpenGLWidget 🙂

flint shuttle
sly wind
broken grail
#

It's called ImSIM, and it is really interesting programming that way. Very concise, especially with F# as coding language.

#

(Their own editor uses ImGUI directly, so not their own system.)

broken grail
# tawdry crater But is QT a bad choice? I know many KDE programs uses it, although there may be ...

KDE libraries itself are a straight extension to Qt.

They are not a wrapper, they are extending the functionality of Qt, and lots of KDE stuff ends up being in Qt anyway.

Half of the work on Qt is also done by KDE people, and the KDE Foundation has even a special legal option, to enforce the open source licensing of Qt, if the Qt company ever turns crazy.

They almost triggered that around the time Qt dropped Qt5 support, as they wanted to continue doing it under a proprietary license to enterprise customers.

The whole reason why Qt continued to deliver updates against their wishes, is this special power the KDE Foundation has over the Qt company.

Without this, O3DE would have been in deep trouble, since the updates would have stopped years ago.

KDE initially announced they would succeed with the updates themselves, and then convinced Qt to do it themselves.

People also use Qt often as a replacement for the standard library in C++, because its more than an UI toolkit.

sly wind
south mica
#

i can't wait for Qt6 O3DE editor, that might solve some of the jankiness that happens in Linux, like it's hard to move the window, and the docking windows on X11, but rather have an option to use the native window decorator/manager to handle it instead O3DE custom drawn. And the most annoying one that the Editor may freeze when opening an Level if there's audio playing in the background (i.e youtube)

flint shuttle
#

Have to disappoint you but it still has those issues. It comes from the custom widget changes we have. We need to find that bug.

south mica
#

dang, the audio one i still thinking there's some sort of deadlock, but even disabling the MiniAudio gems it still may hang

midnight mural
#

I was wondering, will the Qt6 Editor fix this problem?
It goes too deep too quickly, taking more space than necessary

image.png
stark fern
#

I don't think QT6 fixes that magically, but I saw a PR to fix it somewhere?

#

its more a matter of, we need to fix that window in the code

#

and first, we gotta decide how we want it to look

midnight mural
#

Thanks for letting me know 🙂

stark fern
#

its probably just an option in the ui file or the code, that lets you resize that column or whatever

#

and there's probably settings in the qt code for liek, margins / indent

midnight mural
stark fern
#

yeah, I'm not sure how to do it but surely there's some way

#

thhe property inspector for components is highly controlled custom drawn control so theres going to be some way to adjust the width given there

#

the skeleton outliner and stuff on the other hand is probably just a basic QTreeView

#

so however you do that in normal Qt is how we'd fix it here

midnight mural
#

i guess that's something for sig-ui-ux ?

stark fern
#

maybe by adjusting border and padding props

flint shuttle
#

I had a fix for that in the animation editor

#

But might be there are other skeleton dialogs with the same issue

#

Which one is that?

#

Maybe we need to get rid off them and use only one

stark fern
#

maybe. One might bein emotionfx for the actual animated skeleton, vs, like, the fbx import

#

that screenshot seems to be anim view though

flint shuttle
#

@midnight mural can you tell me which dialog you opened for your issue?

midnight mural
flint shuttle
#

not sure the icon close to the actor name but i see it, its the Skeleton Outliner

rare arch
#

Hey all! We were ideating on an editor theme overhaul to modernize the aesthetic of the editor. https://discord.com/channels/805939474655346758/1450287189736034346

We've been identifying the style-sheets and contact points for the re-styling but wanted to know if the migration to QT6 would cause conflicts or drastically change the styling and format.
We want to identify if we should wait and just plot out the theme until Qt6, or actually see what we can chip away at, now.

sly wind
#

The styling won't drastically change but there will be conflict or unmatched arguments for sure

flint shuttle
#

How does the qt6 port look like. What are we missing?

sly wind
#

Hey ! Sorry for the delay, its still pretty swampped at work. So the last mention above still stand (outside of EMFX which was fixed thanks to you):

  • Floating window are not hiding the OS Toolbar (o3de uses a custom toolbar, and doing so hides the OS-one),
  • With 2 monitors, when expanding floating window while on secondary monitor, window is lost (can be retrieved by clicking on it via the toolbar again),
  • On linux, jump into game not currently working (there is a QT6_TODO for that in the X11 code, just need the code to grab the X11 handle),
  • linux cmake not currently copying required X11 files (need to do so by hand),
  • The text next to the spinbox (X, Y, etc) is not draggable with the mouse,
  • Scriptcanvas node styling falling appart when node is hovered (likely a missing condition in .qss file),
  • Window minimize and expand icons do not change when hovered (no white background as usual),
  • Qt translate still not built on the CI as it is a pain to build,
  • Alignment of QMenu items and dropdown arrow next icon is not correct,
  • Scrollbar background is not transparent when not hovered,
  • Drag and drop in one tableview of EMFX needs to be ported so that it don't require accessing private QT class (ParameterWindowTreeWidget::dropEvent)
#

I'll try to continue a bit over the weekend 🙂

sly wind
#

So Qt translations now build fine in the CI for both linux and windows, I still have to cleanup these scripts but it mean the PR to update 3p-package can be merged soon, making QT6 branch way easier to test

stark fern
#

Whats the best way for me to help with this effort ? I have access to windows and mac, vs2022 and vs2026

#

this is starting to be really urgent

simple sorrel
#

Also happy to help if I can!

stark fern
#

@sly wind I'll clear up my current ToDo for this

#

I have a feeling we're going to want to accept some slight mess in the UI/UX temporarily get this in, then get it running better

#

and I'm okay with that.

simple sorrel
#

Guillaume, were you able to use vanilla Qt6, or did you have to include the stylesheet modifications from the 5.15.1-o3de branch?

rare arch
#

I'm going to see if I can wrap up "feature complete" for #1420141263448965210, and make it ready for deployment when this is ready.
There will be a handful of library dependencies alongside PySide6, like the ability to read documents and things. I'm not sure the entire extent relative to the standard O3DE python support.
I definitely argue that it's all worth it, to have a robust and powerful Component Creator from here on out.

rare arch
stark fern
#

I guess I'll start by grabbing the branch mentioned and testing it... on windows?

#

but to summarize it sounds like we also want to update python, then compile pyside6 against qt6 and python?

#

online searches are showing me that python can be very old if you use the macos system python, and later versions don't bundle it at all

#

however, due to all the signing and package reqs it seems we'd need to make something special for python in o3de to be able to run it embedded inside the editor / etc (ie, the o3de app package would have to include the dylib, and would also have to be signed and the signature would need to include the hash of the python embedded inside it)

#

to be more specific, it does not seem like the os will accept you just running a random binary sittign on your hdd anymore

#

so our current approach of like, donwloading a python executable and plopping it in 3p unsigned, and then making a virtualenv there, is not going to work

#

it has to live inside a signed bundle of some sort

#

which we could make, ie, sign, python bundle

#

frameworks can be signed, apps can be signed. when a framework is signed, it cna be put inside an app Frameworks folder, IIRC, and then the app does not need to recursively sign that folder, as long as each framework itself is already signed. But you used to be able to run executables from unsigned frameworks, and I don't think you can anymore on latest os

#

we should upgrade to latest 3.14.2 PIthon

#

gosh it would be so nice if we could just have people use the built in 3.14.2 python from the normal mac installer

#

but I'm not sure mac plays nice with multi different pythons installed, etc

stark fern
#

as for the qt6 rev1 package, I tested it in editor, asset processor, asetbundler, materialeditor, etc, and on windows, I cannot see anything seriously wrong at all

#

do we need to focus more on linux or something?

simple sorrel
#

I could be totally wrong, but I can check

stark fern
#

maybe? I don't have a mac to test with

#

and I don't know what the redistribution license is

simple sorrel
#

No prob, I can check

simple sorrel
stark fern
#

licenses make no sense and can be whatever, make 0 assumptions

#

and redistributing binaries is legally very different from redistributing source

stark fern
#

Not a lawyer but glancing at the license it seems pretty permissive

sly wind
#

This week (weekend included) I will finish the 3p pull request so that the QT package is available with everything we need, then I will annotate the code on o3de side to pinpoint the remaining todos (easier to follow than bullet point)

sly wind
simple sorrel
#

WOO! That's fantastic

sly wind
#

Sorry for being so OOO lately, its difficult to find the time 😅

#

But yeah, with the few remaining things put in clear in the code, and the testing being as easy as just switching branch, I expect us to reach the finish line within the two next months

simple sorrel
#

I could probably find the answer myself, but is the work you've done based on the 6.8 LTS, or a non-lts minor version?

stark fern
sly wind
#

Its on 6.8.3

sly wind
#

Actually it will be 6.10.1 as Its the only version where the ci was able to build the translation module. I will make adjustments on the qt6 branch to take the change into account over the weekend

rare arch
#

Just going to jump in a bit tangentially.

I put together this Class Wizard, extending from the originator... Quite a lot. And I included PySide6. But, a LOT of these scripts are about scanning and accessing various files throughout the O3DE, and project, AND gem structures around it. All for the proper data points to access common file patterns and core files, and folders, to edit and build on. Certainly, I am not claiming to be able to handle pure 100% custom gem structures and whatnot. Really this is the "80% of most of the things".

But I am not sure what is strongly, and explicitly in alignment with, not PySide6, but PySide6 adjacent functionality that is "only" served by that level of python support.
Seeing a lot of the discussion in #sig-build has me wondering if even the 'non-advanced' libraries or tech is not actually supported by O3DE and "if" it can be supported. Reading entire folder structures, creating all sorts of tertiary and staging files, and then deploying those files to your code structure, including generative lines and additions to present, or staged files..

If this is far removed from the O3DE python support, I would like to try and find how I can reduce and reclaim these systems in a way that is far more compliant with O3DE... If I can.

#

The PySide 6 is very tied to Qt6, but I am not nearly as clear about the "entire" codebase and what may be working even against the Qt6 implementation... or at least making the new implemetation more complex than normal.

sly wind
#

Well to be honest it's not qt6 related what you mention its rather o3de api related

stark fern
#

Yeah, we could always write it as a C++ module, with QT also. But we do intend to support pyside6

#

its my understanding that whatever we do, we're going to have to basically
*update python (3.14.2 probably)

  • update qt (whatever version, 6+)
  • update Pyside6/QtForPython (we already ship this but it needs to be upped to 6)
#

and they all have to agree with each others verisons

sly wind
#

O3de runs smoothly on QT6.10.1 on windows and linux, I have just have to add a bunch of "QT6_TODO" in the code for the remaining polish.

  • On linux it looks solid, just minor UI things so far
  • On windows, the docking needs some work

I will try to make QT translation cmake command work before allowing the 3p-package pull request to be merge-able

stark fern
#

is there any items you'd like us to swarm on to try to fix? (and in which OS?)

pulsar pecan
#

I'm going to take a stab at mac arm64 this week on that branch

stark fern
#

are we still modifying qt in this one, or can we go vanilla?

pulsar pecan
#

I'm going to target Qt6, I wasn't able to build 5.x anyways,

simple sorrel
sly wind
# stark fern is there any items you'd like us to swarm on to try to fix? (and in which OS?)

I don't have anything in local and the branch is open to all maintainer so its really about anything you find while testing, and the QT6_TODO. Right now I only see two critical things

  • Windows docking behavior, where your window will sometime fail to go to full screen, appear with an unwanted top bar, or expand always go to first screen (TitleBarOverdrawHandlerWindows, TitleBarOverdrawHandlerWindows and StyledDockWidget are the classes of interest)
  • The QT6_TODO regarding EMFX parameter window drag and drop. I don't know how to port that yet without doing the same hack (916b5c9769b723f64b95fe6a0a085754f40a7008 commit)
stark fern
#

I'll take a look at the TODO then, I guess?

#

it hapens on windows?

sly wind
#

Yeah its on windows

#

Don't hesitate to push on the branch your changes

stark fern
#

I think I have a fix, testing it now, really dont need to reach into private for this particular case

#

its just trying to fin the index that hte drop will insert on

#

which is available

#

gotta do something about the weird window decors on windows too

stark fern
#

gah, can't test my fix because pulling any actor into EMFX causses a crash in atom mesh feature processor, going to compare with development but I tried the same thing just 2 days ago and it was fine on the previous qt6 drop

sly wind
#

I clear the cache folder anytime I run into an issue with atom just in case, last time it solved some level opening could be worth a try

sly wind
stark fern
#

not sure what setups we might be dealing with, its probably all about those tool windows and floating docking windows related

#

I think the desire was simply to make the docked tabs look like the floating ones

#

but I personally believe that the chrome around a root window is the OS's responsibilty

#

we also need to try it in debug mode

versed flame
#

I do like having native decorations over CSD, as for docking does qt6 have everything we need for that built-in?
EDIT: Found some good news, qt 6.6.3 apperently has support for xdg toplevel drag, so dragging tabs out of a surface should be very smooth

stark fern
#

it crashes immediatrely in debug mode with

QTranslator* EditorQtApplication::CreateAndInitializeTranslator(const QString& filename, const QString& directory)
{
    Q_ASSERT(QFile::exists(directory + "/" + filename));

with the directory and file name referring to ./Translations/editor_en-us.qm

#

not sure where those are or come from, but probably related to translation stuff

#

the crash I get in debug does not actually make sense to me

#

<11:06:25> AZStd::fixed_vector<>::at - position is out of range
its crashing at
auto& meshInfoIndices = m_meshInfoIndicesByLod[modelLodIndex];
but

-        m_meshInfoIndicesByLod    fixed_vector[0x0000000000000001] capacity 0x0000000a    AZStd::fixed_vector<AZStd::vector<AZ::RHI::Handle<int,AZ::RHI::DefaultNamespaceType>,AZStd::allocator>,10>
        [size]    0x0000000000000001    unsigned __int64
        [capacity]    0x0000000a    int
+        [0x00000000]    vector[0x0000000000000004]    AZStd::vector<AZ::RHI::Handle<int,AZ::RHI::DefaultNamespaceType>,AZStd::allocator>
+        [Raw View]    {...}    AZStd::fixed_vector<AZStd::vector<AZ::RHI::Handle<int,AZ::RHI::DefaultNamespaceType>,AZStd::allocator>,10>
#

its asking for index 0

#

in a fixed vectror with capacity 10 (0x0A) and a size of 1

#

tripping up this code

AZSTD_CONTAINER_ASSERT(position < size(), "AZStd::fixed_vector<>::at - position is out of range");

but in the debugger (this is in a debug build)

-        this    ... fixed_vector[0x0000000000000001] capacity 0x0000000a  AZStd::fixed_vector<...,10> *
        [size]    0x0000000000000001    unsigned __int64
        [capacity]    0x0000000a    int
+        [0x00000000]    vector[0x0000000000000004]    

     position    0x0000000000000000    unsigned __int64
#

unclear to me why the container woud trigger that assert

#

since in fact, poisition < size() returns true in debugger

sly wind
#

I tested on profile I thought it wasn't crashing anymore, should have checked the bool

stark fern
#

yeah, as for my fix for the onDrop, that works fine

#

I'm goign to have to dive deep and find out why AZSTD_CONTAINER_ASSERT is triggering in debug

#

when the assert is (position < size()

#

and position is 0

#

and size is 1

#

and continuing anyway has no ill results

sly wind
stark fern
#

not sure, it was an attempt to reuse the internals

#

the code was trying to figure out the index of where to drop

#

and you can do that by asking it for the item under the drop position, and then calling another function to ask it whether the drop location ius "above", "below", or "on" the item (so insert before, insert after, insert as child)

#

if its "above" (insert before) then you can just insert at that index

#

since "insert" by definition, puts it before the index youy specify

#

if its "Below" (insert after) you have to ++ the index

#

so you can totally write a function to do that

#

like first call "get index" then use a switch statement for adjusting the index to be ++ if its trying to drop it after the highlighted item, check for self drop, etc...

#

but thats literally what the private onDrop() function does

#

so I guess they just called it instead

#

would recommenxd viewing in split, without whitespace

#

guess I'll take a look at the docking behavior nextg?

#

should I just mess with docking till I repro it?

sly wind
# stark fern should I just mess with docking till I repro it?

Its straightforward by just playing around, but its actually 3 different issues, all on windows

  • O3DE minimized won't show anymore. Might need 2 screens to repro will check, but basically, if you minimize o3de main window, clicking on it on the taskbar won't trigger the maximize and you are locked out of the app (issue might lie in WindowDecorationWrapper::showEvent logic)
  • Floating window on screen 2, click maximize, it will maximize on screen 1 instead of screen 2 (issue lies in TitleBar::handleMaximize())
  • Floating window, they will have the windows OS topbar on top of the O3DE one (fixed by nuking TitleBarOverdrawHandlerWindows and isWin10() calls, but then if we go down this route, need to update the background clear color of QT so that we don't see the 4 pixel margin on top of the o3de minimize/maximize buttons)
stark fern
#

I bet almost all of this is "us messing with the normal Qt application stuff"

#

since normal qt apps work just fine with all of those

stark fern
#

is the same issue present on other os, or mainly just windows

#

helps me narrow down the code if its just 1 plat

#

going to have to look at this crash first tho of course

sly wind
#

Will try to get translation working over the weekend so that 3p-package pull request can get ready for merge, and will look at the remaining annoyance with the docking as its the only thing blocking the PR

sly wind
#

I'll be opening the QT6 PR likely tomorrow, waiting for the last version of the 3p-package build 🙂

simple sorrel
stark fern
#

I haven't got a chance to try to clean out those dociking issues yet but anyone can swarm on it

sly wind
#

I did actually, a few quirks might remain but the bulk fix is in the branch

stark fern
#

verry nice!

sly wind
#

Delaying a bit the PR as for some reasons I'm now running out of disk space on the ubuntu runner, removed the debug build in there hopping its enough

#

We will also need to check for which msvc version we want to build, as QT 6.10 cannot use 14.29 toolset its too old

stark fern
#

We need it to work on vs 2026

#

and 2022 I believe?

#

so 14.44

#

We only used to build on 14.29 becuase our earliest supportted version was vs2017 (14.29)

#

and when you pre built 3rd party binaries (shipping dlls, libs, etc) they are only compatible with newer toolset/sdks

#

so if we built it with vs2026 it would not work on 2022

#

so we should probably switch it up to 14.44 (v143)

sly wind
# stark fern so 14.44

Cool so nothing to change for the PR regarding msvc version, given that its using "Microsoft Visual Studio/2022/Enterprise/VC/Tools/MSVC/14.44.35207/"

#

Triggered yet another linux build without symbols this time, if its still not enough I'll have to cut the translations from the ubuntu build

#

I wonder what changed on the runners lately, it worked for weeks and just few days ago the disk space was sliced

stark fern
#

maybe it filled up with cache or maybe they're shrinkflation

stark fern
#

the Qt 6 upgrade WILL therefore finally actually deprecate 2019 though so we should make sure thats already been messaged

sly wind
#

Nice looks like CI went through after a retry, we even got the mac build in there thanks to steve 🙂 I won't have access to a linux computer for a week, can someone try on linux ? I did on 6.8 but not on 6.10 https://github.com/o3de/3p-package-source/pull/293

#

Also since the debug build of QT is not on ubuntu, I hope I won't have to change the cmake file

pulsar pecan
#

Currently getting this error on Mac Arm:

Undefined symbols for architecture arm64:
  "CDockTitleBarWidget::SignalCustomButtonPressed(int)", referenced from:
      CDockTitleBarWidget::OnCustomButtonPressed() in DockTitleBarWidget.o
  "vtable for CDockTitleBarWidget", referenced from:
      CDockTitleBarWidget::CDockTitleBarWidget(QDockWidget*) in DockTitleBarWidget.o
   NOTE: a missing vtable usually means the first non-inline virtual member function has no definition.

and

Undefined symbols for architecture arm64:
  "vtable for CDockTitleBarWidget", referenced from:
      CDockTitleBarWidget::CDockTitleBarWidget(QDockWidget*) in DockTitleBarWidget.o
   NOTE: a missing vtable usually means the first non-inline virtual member function has no definition.
ld: symbol(s) not found for architecture arm64
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
#

Interestingly enough, this custom dock title bar widget is only used by CAudioControlsEditorWindow

pulsar pecan
#

Testing latest package on Linux:

ninja: error: '/home/spham/.o3de/3rdParty/packages/qt-6.10.2-rev1-linux/qt/plugins/platforms/libqxcb.so', needed by 'runtime_dependencies/profile/AzQtComponents.stamp', missing and no known rule to make it
pulsar pecan
#

I fixed the branch and had to restart the GHA builds. For some reason, it kicked off all 3 platforms.

#

Getting weird errors on startup on Ubuntu:

qt.core.plugin.loader: /home/spham/github/o3de/build/linux/bin/profile/platforms/libqxcb.so.lock: failed to map to memory: Invalid argument
qt.core.plugin.loader: /home/spham/github/o3de/build/linux/bin/profile/platforms/libqminimal.so.lock: failed to map to memory: Invalid argument
qt.core.plugin.loader: /home/spham/github/o3de/build/linux/bin/profile/iconengines/libqsvgicon.so.lock: failed to map to memory: Invalid argument
qt.core.plugin.loader: /home/spham/github/o3de/build/linux/bin/profile/imageformats/libqtga.so.lock: failed to map to memory: Invalid argument
qt.core.plugin.loader: /home/spham/github/o3de/build/linux/bin/profile/imageformats/libqtiff.so.lock: failed to map to memory: Invalid argument
qt.core.plugin.loader: /home/spham/github/o3de/build/linux/bin/profile/imageformats/libqjpeg.so.lock: failed to map to memory: Invalid argument
qt.core.plugin.loader: /home/spham/github/o3de/build/linux/bin/profile/imageformats/libqico.so.lock: failed to map to memory: Invalid argument
qt.core.plugin.loader: /home/spham/github/o3de/build/linux/bin/profile/imageformats/libqgif.so.lock: failed to map to memory: Invalid argument
qt.core.plugin.loader: /home/spham/github/o3de/build/linux/bin/profile/imageformats/libqwebp.so.lock: failed to map to memory: Invalid argument
qt.core.plugin.loader: /home/spham/github/o3de/build/linux/bin/profile/imageformats/libqsvg.so.lock: failed to map to memory: Invalid argument
qt.core.plugin.loader: /home/spham/github/o3de/build/linux/bin/profile/imageformats/libqicns.so.lock: failed to map to memory: Invalid argument
qt.core.plugin.loader: /home/spham/github/o3de/build/linux/bin/profile/imageformats/libqwbmp.so.lock: failed to map to memory: Invalid argument

I'll have to investigate

rare arch
#

Quick checkin:
In order to support Qt6 6.10, I've updated the ClassWizard to be PySide6 6.10.x compatible.

This means we will be using PySide6 tag v6.10.x

Otherwise, it's ready to deploy!

pulsar pecan
#

Don't we need to update the pyside 3P targets as well? Its still on 5.15

#

in fact, once the Qt6 3P branch is merged in and the packages are pushed to prod, i can start that process since it needs the artifacts from that package as its dependencies

sly wind
stark fern
#

They all need to be in sync, that is, Qt, Python, Pyside.

#

Usually its build python and qt to whatever version you want of those, then build pyside against those packages

#

since the pyside build depends on those packages (it downloads and unzips the one you tell it to use

simple sorrel
#

today is a good day

image.png
sly wind
sly wind
#

Updated the links to point to the online qt packages, so testing qt6 is now just a matter of switching branch 🙂 (if you tested before, would be wise to delete any trace of it in the 3rd party package folder in local)

#

Will check the issue above then open the qt6 PR for the main repo

stark fern
#

when you say it doesn't work in dev you mean its broken with qt5.x right now?

sly wind
#

No it works with qt5, while with qt6 Gems\AtomLyIntegration\TechnicalArt\DccScriptingInterface\Editor\Scripts\bootstrap.py, which is called by PythonSystemComponent::ExecuteBootstrapScripts, fails. I'm looking at how to attach a debugger to the python env to see what's up

stark fern
#

yeah, I mean, unless we also updated the pyside package, its not goign tow ork

#

the pyside package needs to be built against the qt package and the python package we actually use

#

the "Build script" downloads a pinned qt version

#

you cant use pyside 5.x on qt 6.x

#

its actually very speciifc, you can't use pyside 6.2 on qt 6.3 even

#

so untill all those packages "agree" with each other pyside wont boot

sly wind
#

Which makes sense, its a good design I believe to have python integration use the same qt runtime environment as the editor

stark fern
#

Yeah, I just mean that, don't expect it to work until we have a new pyside package also

#

and dont waste time trying to diagnose why the old pyside doesn't work with the new qt 🙂

#

it wont, by design

#

the package scripts should be pretty easy to updat ehto, the json file lists the package hashes and names of the qt package and python package to get

#

and then the cmd/sh files just import those

#

and we dont modify pyside in our 3p at all afaik

#

and its from qt

#

so pyside 6.10.2 should work with vanilla qt 6.10.2

#

the benefits of not messing with an imported 3p anymore 🙂

sly wind
stark fern
#

Oof, I'm praying we dont need it

#

note that we explicitly disable QML

#

so thats probably what its about

#

some of these are silly

-option(FORCE_LIMITED_API "Enable the limited API." "yes")
+option(FORCE_LIMITED_API "Enable the limited API." ON)
sly wind
#

Might be worth a check to have that as a fetchpackage instead of relying on the CI

stark fern
#

to CMAKE, "yes" is ON

#

pyside2 is like, a bit long to compile

#

iirc

#

I'm hoping that we can remove the patch

#

we should not need to modify the cmake

simple sorrel
stark fern
#

absolutley

#

I learned it, I used it, I regretted it deeply. we integreated it into O3de then we UNINTEGRATED it

sly wind
#

I might open the QT6 PR before the pyside update, listing all regressions identified so far (python included)

simple sorrel
stark fern
#

it is horrendous and worse, it leaks GPL copyleft into things

pulsar pecan
#

i concur, it was all over the Project Manager

stark fern
#

original AP was qt quick, and we had a Qt QML Docking Pane in the editor, removed

#

the size of all our binaries was so much larger thanks to having to essentially pull in an entire javascript VM

simple sorrel
#

I don't want to detract from the thread, but I want to hear the story sometime. I worked over a year on a QML app, and thought we made great progress, but it just started falling over on itself

stark fern
#

so I'm glad its gone

#

but nothing in the pyside2 script seems to indicate that we actually need these changes

#

eg, the diff appears to delete a block like

if(${Qt${QT_MAJOR_VERSION}Qml_FOUND})
...
   set(QML_SUPPORT 1)
endif()

and replace it with

set(QML_SUPPORT 0)
#

but if we've done our package right, then Qml_FOUND wont be true

#

since we would have disabled QML in the QT build

#

this part is interesting tho
+// getTypeId returns an interface similar to the std::type_info returned by typeid, but will attempt to use
+// Qt's meta-object system for QObject subclasses instead - this allows Shiboken to interop with libraries that
+// are built without RTTI

#

but like, we.. dont need to interface with libs without RTTI

#

our pyqt impl is for tools only

#

and our tools are allowed to selectively turn on RTTI (and several do) if they need it

#

I'd try it w/o applying the patch tbh

#

I'm doing a quick try right now of that

sly wind
# stark fern I'm doing a quick try right now of that

Thanks I appreciate it, I had a doubt about the python version we use but it seems to be still the one we pull from the CI, just that its set from o3de\cmake\3rdParty\Platform\Windows\Python_windows.cmake instead of the json filelist as for the other packages

stark fern
#

the only issue I found so far is that the pyside 6.10.2 script has a bug in it

#

it does this

if self.dict["internal-build-type"] is None:
   return None
#

however, you can't do that

#

like, this raises a keyerror since its initializeing

#

it should be in a try block

#

or a get

#

so I'm not sure how its working for anyone

#

ah, it has a completely quiet line in there

# 
if qtpaths is None:
   sys.exit(-1)
#

no printf, nothing

#

ok yeah, figured it out, needs a very specific env set up

#

you need the qt bin folder in your PATH

pulsar pecan
#

Here is a PR for the mac arm64 support for the Qt6 branch: https://github.com/o3de/o3de/pull/19571
I think I got through a large chunk of the issues. At this point, I am hoping for others to try to help on getting Mac Arm64 support for O3DE through the Qt6 branch. The PR description is a high-level list of things I had to update to support mac. Of the remaining items so far that I know of are:

  • There seems to be in issue with fix_bundle related to Qt6, specifically the QtDBUS framework and RPATHS
  • Some post-compile steps copying over some files from the framework
  • A dylib issue with the mcpp library (I'll take a look at this one)
pulsar pecan
#

The Qt6 branch has updates to support building for Mac Silicon (Arm64). There are 2 build issues that I am aware of, one of them related to a mis-packaged mcpp 3P library, and another related to cmake's fixup-bundle having issues with the Qt6 package.

#

The 3P issue I'll look into, but the other one I hope someone can take a stab at:

📎 message.txt
stark fern
#

there was talk about ditching MCPP at some point, but I'm not remembering what the replacement suggestion was

#

I think we use it to preprocess the azsl

#

ie, replace #includes with the content of the files, replace #ifdefs, etc

simple sorrel
#

It's not used in AZSLC itself, so that would be weird. But maybe the AP is doing something prior to running AZSLC

stark fern
#

no idea, my understanding is its a preprocessor of some sort

#

its not a compiler, just a preprocessor

#

of course, I feel it was chosen becausse its tiny and its free

#

so switching it out with an entire installation of clang would be bad. altho if we can do the same thing with the compiler thats already being used that'd be great

pulsar pecan
stark fern
#

are there other things blocking it besides @sly wind finding the time to work on it? Packages? Platforms?

pulsar pecan
sly wind
stark fern
#

I guess we get Qt6 in then the i18n one?

#

and then straight after that I want to get into the i18n one and do some fixups

#

but we need to get out of the 100000000 file PR asap

#

get it in, then iterate 🙂

pulsar pecan
#

So update on pyside6, i've hit an issue that looks like its a problem with the qt6 windows 3p package.

CMake Error at D:/github/3p-package-source/package-system/pyside6/temp/qt-6.10.2-rev1-windows/qt/lib/cmake/Qt6QmlAssetDownloader/Qt6QmlAssetDownloaderTargets.cmake:127 (message):
  The imported target "Qt6::QmlAssetDownloader_resources_1" references the
  file

     "D:/github/3p-package-source/package-system/pyside6/temp/qt-6.10.2-rev1-windows/qt/qml/Qt/labs/assetdownloader/objects-Debug/QmlAssetDownloader_resources_1/.qt/rcc/qrc_qmake_Qt_labs_assetdownloader_init.cpp.obj"

  but this file does not exist.  Possible reasons include:

  * The file was deleted, renamed, or moved to another location.

  * An install or uninstall procedure did not complete successfully.

  * The installation package was faulty and contained

     "D:/github/3p-package-source/package-system/pyside6/temp/qt-6.10.2-rev1-windows/qt/lib/cmake/Qt6QmlAssetDownloader/Qt6QmlAssetDownloaderTargets.cmake"

  but not all the files it references.
#

I've disabled almost every possible module I could in the setup, but the pyside build still is reading these module cmakes and validating them regardless. I suspect that the qt6 package needs to not only specify the reduced modules, but also remove these cmake modules as well if they are going to be trimmed from the package

sly wind
#

Qt6QmlAssetDownloader what the hell is that 😆

#

And I'm afraid its just the first of a list of not required deps

#

Do you have a branch or setup where I could try the pyside setup ? Or the command you used to generate the solution

#

I'll get to the bottom of the review and listing regressions over the weekend

stark fern
#

we actually want ot disable all qml and all qt labs qml things

#

My guess is 1 of 2 things i shappening here.

  1. we're compiling our qt package with bits and pieces of QML, and need to turn additional things off, so it has nothing, so the pyside doesn't try to generate bindings for it
  2. something in the pyside cmake need sto be patched to not go looking for it
#

I think its probably 1

#

qt has this annoying build script where things are on by default

#

so if they add a new package, it ends up building

#

and everyone who doesnt want it has to go amend their build scripts to turn it off

sly wind
stark fern
#

gross

#

we could always tell people to just go download the qt tools and stop building them ourselves. We'd still need the cli tools like lupdate, lrelease but its not a huge thing to say "go get the gui tools from qt"

#

might make our installer a lot smaller and only a fraction of our user base is likely using qt to actually design guis and stuff

simple sorrel
#

Might also be nice to replace all UI code with C++ implementations, rather than needing UIC at all

#

There are currently 196 ui files, but many of them are pretty trivial

stark fern
#

Maybe. I'd rather replace all UI code with imgui (whether its actualy dear_imgui or another different im gui) tbqh but thats just a dream 🙂

#

but the point here is, we cna make a lean and mean Qt

#

it would acutally benefit our average user to not have to get monsterqt when they just wanna run the editor and build games

#

but for now, if we want to do as little as posisble we may have to hack the pyside6 cmake files or somehting to cut it out evil style

sly wind
#

It might be possible to skip the whole qtwebengine nonsense if we provide lrelease, lupdate and lconvert executables to the build command, this way we would really only build what we use in o3de. I'll keep that in the back of my head for after the Qt6 PR review, hoping that it would solve the pyside build problems

stark fern
#

yeah, I'd love to see a Qt6 3p package that ocntians only what we need

#

we would need uic, moc, lrelease, lupdate, lconvert but NOT "designer.exe" or "linguist.exe" or anything qml related

sly wind
#

uic, moc etc we build ourselves its part of qtbase

#

Its really these nasty qttranslations deps the issue

stark fern
#

qttranslations... yeah, if only there was a weay to build only the cli tools and not linguist or anything qml related

#

if they've gone and tied their CLI tools to QML uguuugh

simple sorrel
#

qttranslations need qml? Last time I built qt6 I only needed qtbase, imagefomats, svg, and tools

stark fern
#

we do need at least cli tools lupdate, lrelease, lconvert

#

but those just read cpp files and output xml files

#

would be so dumb if they required qml

simple sorrel
#

Yeah--is that only because lupdate requires linguist? I assumed it was part of qttranslations itself

sly wind
simple sorrel
#

Ah

#

Localization is a big win for the editor, but pulling Qt into the game code to make it work has me concerned. Makes it even harder to escape that ecosystem.

#

That has been my hangup on the massive i18n PR

sly wind
#

Well fortunately o3de is very strict there so no game logic is ever linking against Qt, its always only lives on the tooling side which never ships

simple sorrel
#

Just lots of QT_TRANSLATE_NOOP in reflect code now

sly wind
#

If you were to use Qt in a release game, you would have to give money to Qt even

simple sorrel
#

Even if it is truely no-op

stark fern
#

they actually defined an AZ_TRANSLATE_NOOP for gamecode I believe

#

or a QT_TRANSLATE_NOOP in AZ that doesn't actually use qt

#

after all, its literally a no op

simple sorrel
#

It's just a marker, for lupdate, which is why they kept it as QT_TRANSLATE, because it wouldn't work if it was AZ.

stark fern
#

I think they just put this in azcore somwhere

#if !defined(QT_TRANSLATE_NOOP)
  #define QT_TRANSLATE_NOOP(x,y) y
#endif
#

so no need to actually pull Qt into your game

#

not real ysure how else to do it, tbh. Another custom translation system just for core I guess

#

its not for game localization anyway

#

thats handled by a completely different custom runtime system

#

its all the strings that show up to devs in compile errors / gui of editor / imgui / asset processor / material editor / lua ide / etc

simple sorrel
stark fern
#

yeah, but its the thing thats for actual show on th game screen as opposed to tools/debug

simple sorrel
#

Yeah, I just wonder if there couldn't be a new localization system that covered both use cases. Similar to UE's FText system

#

LM is old, and Qt is editor specific. So it could kill two birds

pulsar pecan
#

@sly wind So I found out the issue. The file that is missing in the error was actually in the package, but there is an error in the packaging script that creates the tarball package where hidden folders were not picked up with glob:

# 
    # Note:  While it would be great to use pathlib.glob, it doesn't 'see' symlinks!
    # We have to use glob.glob instead, then wrap it in a pathlib.Path:
    path_list = list(glob(f"{path_to_scan}/**/*", recursive=True))
#

Since python 3.11, they added an 'include_hidden' option to glob, but the scripts are still using python 3.10. So a work-around that I found was to use pathlib's Path object's own glob function, which does include hidden files/paths. Once I test everything out, I'll send out some PRs

simple sorrel
#

Any reason 3p scripts still uses 3.10? Doesn't seem like it has the same upgrade struggles the engine has

sly wind
pulsar pecan
sly wind
#

Addressed PR comments and listed more minor regressions, I'll look at the unit test then proceed with more testing of the tools

#

I noticed the Mac build failing on 3rd party setup steve, I leave that in your good hands since I cannot test it

stark fern
# simple sorrel Any reason 3p scripts still uses 3.10? Doesn't seem like it has the same upgrade...

We can use any version of python for 3p scripts, actually , does not have to be the o3de one. only risk is if thers something python puts in the ENV when it launches sub-shells or sub-processes that cuases confusion if part of the compile process wants to use 3.10 from o3de to pack appropriate dlls / so's. Like for example, compiling openimageio compiles and embeds python modules, so that one better be using the one from the engine.

sly wind
rare arch
sly wind
#

Due to the sheer amount of changes, anything that is not catching a regression will have to wait for Qt6 to be merged, what remains is the python thing that steve is working on, and making sure that unit tests are running

#

But feel free to jump on the branch and report regressions as you see them 🙂 We might not tackle them all before merge as most are visual annoyances

stark fern
#

yeah, we'd rather get it merged into dev soon and start hunting issues and having lots of little PRs to address them, than continue giant pr

#

The i18n commit is also ready as soon as a conflict or two is done

simple sorrel
#

Should that happen post-Qt6?

stark fern
#

thats a good question

#

the thing now generates the i18n files (.ts) in each gem's folder rather than in one monolithic place
It still globs them BUT cals a function on each found gem, which we can invert and have the gem call from its cmake file once committed.

#

its hard to iterate and improve such a giant pr

#

I think we're going to have to do a bunch of iterating on it

#

same qith qt6

simple sorrel
#

I hope to help a bit with the i18n stuff when it's in. I have done it before with Qt, more on the cmake and linguist pipeline side, which idk if we need help with or not

stark fern
#

same same, I think we just wanna set a really good starting pattern tbh

#

make sure it follows the modularity

#

so the glob thing must be fixed pretty quick

pulsar pecan
stark fern
pulsar pecan
#

I've pushed a branch in 3p-package-source called 'pyside6_support' (https://github.com/o3de/3p-package-source/tree/pyside6_support) which is based on the qt6 windows package above. It uses my local install of vs2022 community for the windows compiler, so feel free to update the 'build_windows.bat' file accordingly. The error that i'm currently running into is:


C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.44.35207\include\tuple:939:9: error: static_assert failed "get<T>(tuple<Types...>&) requires T to occur exactly once in Types. (N4971 [tuple.elem]/5)"
C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.44.35207\include\tuple:951:9: error: static_assert failed "get<T>(const tuple<Types...>&) requires T to occur exactly once in Types. (N4971 [tuple.elem]/5)"
...
#

The package name is pyside6-6.10.2-py3.10-rev1-windows, e.g.

python  D:\github\3p-package-scripts\o3de_package_scripts/build_package.py --search_path D:\github\3p-package-source pyside6-6.10.2-py3.10-rev1-windows
mint dirge
pulsar pecan
mint dirge
#

Ok, fixed that too

pulsar pecan
#

I fixed the merge conflict but there looks like a DCO issue with a previous merge

sly wind
#

Rebased and fixed the DCO, for some reasons it expected my signature after the rebase

sly wind
pulsar pecan
sly wind
#

"CMake Warning at cmake/ShibokenHelpers.cmake:199 (message):
You need LLVM version 18.0 or greater to build PySide without issues, and
14.0.0 was found. A lower version might case problems, specially on
Windows."

#

Ok it was as dumb as that 😅 Bumped to libclang-release_20.1.3-based-windows-vs2019_64 and was able to build it just fine

#

Just some qt5 refs in the script somewhere, but else all good, I'll test the package tomorrow

image.png
pulsar pecan
#

I didn't see down the list

south mica
#

How close they are to merge it to the development branch?, it feels so close yet so far.

stark fern
#

I think we were just waiting for pyside2 (6)

#

and then final checking

pulsar pecan
#

I've updated the pyside6 branch. The packaging script was updated, but based mostly as a guess right now until I can verify it against the qtforpython gem

sly wind
#

So there are 3 things remaining:

  • pyside support, ETA is this week for Linux and Windows thanks to steve (i'll look at the linux side tomorrow)
  • Unit test all passing, they depend on pyside so ETA is this week on windows and a bit later for linux
  • Mac support, this is an unknown to me as some deps are not currently there so I don't know where further in the process it will fail
#

Also I know we've all been waiting for it but I prefer to be cautious regarding the merge as we don't want to break workflows, visual annoyances are fine but anything more than that that we find would be a blocker until its fixed

rare arch
#

We have till the fall launch. There's plenty of time to ease into things. It's exciting, but there's no need to rush.

#

You're all doing fantastic. 💯

sly wind
#

(its a pyside6 GUI on windows)

image.png
#

I'll create a new branch as there are a bunch of scripts to port, at boot time no one is listening to python output so I redirect the info there, will look at hooking a debugger as well

image.png
pulsar pecan
#

Is this using the 3P package? I updated it last night and will work on the Linux (and maybe mac) versions this weekend

sly wind
#

Yeah its using 3p package built in local, pushed something on the branch to fix some windows paths

#

Only thing missing on windows is in the packaging steps some files are not copied over (the setup.py)

pulsar pecan
#

nice! The last update added setup.py and init.,py as well

sly wind
#

I'll clean the python script, and continue to look at qt regressions + unit tests 🙂 Once the python side is good I'll do a PR into the qt6 branch, this way we can have some reviews on these files

sly wind
sly wind
#

(as a side node I rediscovered this object tree script which allow to inspect the editor widget layouts, can be quite useful to debug qt layouts )

image.png
past grove
versed flame
#

Trying to build the qt6 branch and still getting this issue with recursion when building my project. I verified im on the latest branch. is there anything to watch out for when building it in a existing project that im missing?

image.png
#

Tried deleting my cmake build folder and that didn't do anything

stark fern
#

something miohgt be a dependency of itself or a loop

versed flame
#

Another person had the same issue when trying to build for a project: #1420144310908616725 message

sly wind
#

Can you try with a new project ? I use the newspapper sample to do my testing

versed flame
#

OpenXRTest is something I can easily start testing with, that should be clean enough

#

same issue in OpenXRTest, I also cleaned its build dir

#

Ill create a new minimal project template but OpenXRTest is just something that already exists on my system and is easy for me to quickly try

sly wind
#

I'll try with a few other projects to find a repro, you're on linux right ?

versed flame
#

yup, linux fedora using cmake 4.1.2

#

cmake options: -G "Ninja Multi-Config" I cant use clions cmake debug but its getting stuck at the same spot on a minimal project template

sly wind
#

Do you configure with LY_PROJECTS or do you build the engine inside your project ?

versed flame
#

Build the engine in my project

sly wind
#

Ok so indeed I'm only able to repro when I build the engine within the project, tried on windows

versed flame
#

I'll try the LY_PROJECTS method just so I can continue but would be good to have that issue fixed before its merged into dev.
EDIT: Yeah that worked with my rhythm game project.

stark fern
#

I thought newspaper sample was a script only game, doesnt use a compiler

#

not a great test for compilation

versed flame
#

viewport controls are broken, ill see what I can do with that, I dont know why it gave the surface a toplevel role when its properly using the subsurface role for the actual vulkan viewport, possibly just need to give the same hints the viewport uses to the viewport controls.

rare arch
sly wind
sly wind
#

Ok found it, now I have to see where this is declared and if its not going to break things

image.png
#

I would prefer to fix that by improving the code on Qt side, but since we removed all our custom patches that would be annoying

sly wind
#

So that's where the list from the screenshot above is filled, I'll have to think what's the clean approach would be, as in my opinion o3demain shouldn't be a subdirectory property of shootthefurtinure (as when building in-engine instead of in-project), but it seems that there is no way around it

image.png
sly wind
#

I think I will have to patch QT, I can't think of something that is not a hack or won't be annoying to maintain

versed flame
#

close to wayland ready :) #1482590802273374299 message

pulsar pecan
#

@sly wind I added Linux support to the pyside6_support branch

sly wind
stark fern
#

I just noticed on vs2026 I get a new problem (vs just updated) where th vs system disallows source files to be in 2 different build sets at once

e.g. you can't do this

<ccompile "somefile.cpp"/>
<cppcompile "somefile.cpp"/>
<none "somefile.cpp"/>
#

but our "qt" rule generates a

<custombuild "blah.ui" ... command="uic.exe ..."/>
#

but it also leaves the 'ui' file in the sources list which causes the cmake 2022 and 2026 generators to also generate a

<none "blah.ui .../>
#

this causes the project to no longer load at all in vstudio, emitting a parsing error

#

I solved this by just modifying our UIC rule in our cmake to strip the files out of SOURCES after submitting them to our UIC stuff to make custom uic commands to avoid the duplicates

#

I figure I'll make a PR for this in stab and get it into release, but I thought I'd give a heads up

stark fern
#

just wondering if people encountered this

stark fern
south mica
#

It's no surprise most newer game engines' tools being released are based mostly either their own UI toolkit (i.e Godot, old Urho3d) or Dear ImGui (WickedEngine, rbfx, Spartan, ezEngine)

past grove
pulsar pecan
#

I ran into something similar with XCode

sly wind
#

Some news :

  • Added a patch to prevent the recursion in cmake files https://github.com/o3de/3p-package-source/pull/368
  • Currently looking at building pyside6 on linux, runs into issue with ‘QStringConverter'. Issue likely lies on the fact that on linux we build QT with the "-no-icu" option, whereas its not present on windows, and windows build works. I will dig, but it seems that -no-icu is not a supported codepath for pyside6
sly wind
stark fern
#

so something about the compiler version and/or stdc++ not good

pulsar pecan
sly wind
#

Tried a a custom qt build without the "-no-icu" and still run into the same issue when building pyside on it :/ I'll play with different config to see how it behaves without all the modules exclusions and see what can impact these method signatures

sly wind
sly wind
#

So yeah, on the CI we use clang12, which is what be built qt6 with, but pyside seems to require clang15 from the logs (on the doc it mentions at least clang13, but doc could be outdated)

📎 logs.log
#

I'll see how it behaves when we feed it the required version, given that on windows we give 20.1.3, but its only used to configure, not to build if I'm not mistaken

image.png
stark fern
#

we honestly should upgrade to at least clang15 if not 16-18

#

across the board

simple sorrel
pulsar pecan
stark fern
#

see the discussion in #sig-build but yeah, I think we should move up to at least clang 16 if not 18

pulsar pecan
#

I was able to at least test the it through the sample python template for both windows and linux, but in doing so, I discovered an issue with Qt6: If you create an external project with a source build of the engine, and try to build the engine into the external project source, the configure phase goes into an infinite loop somewhere in the Qt6 cmake file. (This doesnt happen with Qt5, and it doesnt happen if you build a project within the engine folder). I'm going to investigate that. I did try to use co-pilot to figure out what was happening, and here was its analysis: https://gist.github.com/spham-amzn/d5ea4cddf7801c1134ba661265161c39

sly wind
#

Hey ! I believe I put a pr for that already

#

Let me check that tonight, its a cmake recursive include, the fix is actually a qt patch

pulsar pecan
sly wind
#

I currently don't have the time to pursue work in o3de (maybe in a few weeks) so feel free to rebase or make changes as you see fit 🙂

pulsar pecan
#

yeah, i've been in the same boat, i'll try to find time to get that one in

stark fern
#

its become a bit more pressing to get qt6 in due to MSVC just updating in latest that breaks anything using qt5

#

I'm having to do ugly hax to keep it building (see #sig-build)

#

hax we'd like to remove soon

#

so hopefully at least by next release

pulsar pecan
#

I'll be able to work on it this weekend

stark fern
#

well, just by next release

#

we are not going to try to stuff it in this one

pulsar pecan
#

its also blocking the mac arm updates

pulsar pecan
south mica
#

how much remains to get Qt6 merged into development?.

stark fern
#

(and is there any help we can supply)

pulsar pecan
#

I'm following up on the fixes now. I'll have to update the pyside6 as well since the dependencies changed.

pulsar pecan
#

I've updated the qt6 branch with pyside6. For now, we don't have pyside6 support for mac (we never did for pyside2/qt5 anyways), but thats what I want to add sometime in the future. Right now there is a problem getting it to compile on Mac. Whats left is the need to sync all the updates to development to the qt6 branch. I took a shot at it, but a few merge conflicts came up

sly wind
#

Awesome steve that's super nice of you to jump in, so the pyside6 build issues on linux are fixed ? It what stopped me in my progress

pulsar pecan
#

Yeah, pyside6 linux works now (I did a simple python gem example). I just resync'd the qt6 branch with the development branch as well. I'm taking a look at the mac build error, doesn't seem related to qt6

sly wind
#

Ok I'll test all that this week as well, I guess we can nuke the qt6_pyside branch since it was merged into qt6

rare arch
#

Is this suggesting that Qt6 is tentatively done?

sly wind
#

We'll see how it builds on the CI and if the unit test all pass, but yeah its getting close

pulsar pecan
#

oh, mac is failing because its trying to use the intel-mac platform, but we only built qt6 for mac-arm64

pulsar pecan
#

So that leads to the question, should we switch AR to use Mac ARM64 going forward? (assuming that AR can pass on that)

stark fern
#

We aren't planning to support mac intel

#

only their ARM ("M") chips

pulsar pecan
#

I will update the branch to switch the runner to spec mac (not mac-intel)

sly wind
#

Just did a rebase in development of the qt6 branch, I might clean a tad the commit history as well, due to the large amount of changes its better for the future to track what was actually changed

uneven kite
sly wind
#

Good catch, I'll check but should already be in the branch as I don't think this api exists anymore in qt6

uneven kite
pulsar pecan
#

Another FYI is that I've switch the target macos to be 15.0 (Sequioa), which was what all the 3P libraries for Mac ARM was built with anyways

rare arch
pulsar pecan
#

yes

#

not add, more like replace

rare arch
#

Awesome thanks. I bound it to the Qt6 PR. (Trying to clean out some GHI's)

Once again, spectacular work everyone. It's always a pleasure to see all the incredible stuff being built and coordinated.

pulsar pecan
sly wind
#

Summary of tests failures:

[ FAILED ] ModularViewportCameraControllerFixture.CameraSystemStopsMovingWhenViewportLosesFocus

[ FAILED ] AzQtComponents.FloatToString_TruncateShowThousandsSeparatorTruncateNoRoundWithLocale
[ FAILED ] AzQtComponents.FloatToString_TruncateShowThousandsSeparatorOnlyOneDecimalWithLocale

[ FAILED ] SpinBoxFixture.SpinBoxMousePressAndMoveLeftScrollsValue
[ FAILED ] SpinBoxFixture.SpinBoxChangeContentsAndLoseFocusCommitsNewValue
[ FAILED ] SpinBoxFixture.SpinBoxClearContentsAndEscapeReturnsToPreviousValue
[ FAILED ] SpinBoxFixture.SpinBoxChangeContentsAndEscapeReturnsToPreviousValueAndExitsField
[ FAILED ] SpinBoxFixture.SpinBoxEscapeExitsFieldWithoutPropagating
[ FAILED ] SpinBoxFixture.SpinBoxChangeContentsAndCtrlZReturnsToPreviousValueAndExitsField
[ FAILED ] SpinBoxFixture.SpinBoxCtrlZWithNoInProgressEditDoesNotExitField
[ FAILED ] SpinBoxFixture.SpinBoxSuffixRemovedAndAppliedWithFocusChange
[ FAILED ] SpinBoxFixture.SpinBoxCheckHighValueTruncatesCorrectly
[ FAILED ] SpinBoxFixture.SpinBoxCheckBugValuesTruncatesCorrectly
[ FAILED ] GrowTextEditFixture.EscapeRevertsAndExitsField
[ FAILED ] GrowTextEditFixture.CtrlZRevertsAndExitsFieldWhenTextChanged
[ FAILED ] GrowTextEditFixture.CtrlZDoesNotExitFieldWhenTextUnchanged
[ FAILED ] LineEditRevertHandlerFixture.FocusInCapturesTextForLaterRevert
[ FAILED ] LineEditRevertHandlerFixture.EscapeRevertsAndExitsField
[ FAILED ] LineEditRevertHandlerFixture.EscapeExitsFieldEvenWithoutInProgressEdit
[ FAILED ] LineEditRevertHandlerFixture.CtrlZRevertsAndExitsFieldWhenTextChanged
[ FAILED ] LineEditRevertHandlerFixture.CtrlZDoesNotExitFieldWhenTextUnchanged
[ FAILED ] LineEditRevertHandlerFixture.ReadOnlyLineEditDoesNotExitOnEscape

#

Then there are crashes on linux during some tests which are not present on windows, so the summary at the end is longer

stark fern
#

bear iun mind that on this machine,
] ModularViewportCameraControllerFixture.CameraSystemStopsMovingWhenViewportLosesFocus
crashes because the test name is too long unless I do the test with the engine root being D:\a

#

on windows, at least

#

linux does not have that issue

#

looking at some of those errors tho

#

Note that a lot of these are new tests added 5 days ago when @rare arch added ESC behavior to these fields

#

so I imagine its not an incompatibilty but maybe QT6 needs a few fixes for these tests

#

the floattostring_ ones are old ones though

#

and probably something changed about qt6's assumptions

#

for example all the NEW above tests use

 static void FlushDeferred()
        {
            QApplication::processEvents();
        }
#

e.g.

TEST_F(LineEditRevertHandlerFixture, FocusInCapturesTextForLaterRevert)
    {
        m_lineEdit->setText(QStringLiteral("initial"));
        m_lineEdit->setFocus();
        m_lineEdit->setText(QStringLiteral("changed"));

        QTest::keyClick(m_lineEdit, Qt::Key_Escape, Qt::NoModifier);
        FlushDeferred(); // <----------------------------------------------

        EXPECT_EQ(m_lineEdit->text(), QStringLiteral("initial"));
    }
#

is that enough in qt6 to always process all events

#

or do we need more events to bubbler, do we need more ProcessEvents in between those lines

stark fern
#

Or it could be that the focus behavior changed with settext, such that setting text ends focus

#

Setting this property clears the selection, clears the undo/redo history, moves the cursor to the end of the line, and resets the modified property to false. The text is not validated when inserted with setText().

#

says the same thing in qt5 docs

#

the new LineEditRevertHandler, installs an event filter on the control it watches

#

and filters keypress events

#

it captures the text on focus in and then reverts it to that value when esc is hit

#

the qt6-dubious part might be this in the fixture

/ Must have an active top-level window for focus events to fire.
            m_dummyWidget = AZStd::make_unique<QWidget>();
            m_dummyWidget->winId();
            QApplication::setActiveWindow(m_dummyWidget.get());
#

and I'm not sure if winId has changed or whether this is true under qt6

#

I bet it works just fine in real life but tests are not firing right

#

so to summarize the above

Of all the tests mentioned failing, all of them except these three use the same strategy - a QObject that is attached to the text field / line edit / grow text / etc that captures its current text on focus in, and reverts that text on esc via an event filter.

[  FAILED  ] ModularViewportCameraControllerFixture.CameraSystemStopsMovingWhenViewportLosesFocus

[  FAILED  ] AzQtComponents.FloatToString_TruncateShowThousandsSeparatorTruncateNoRoundWithLocale
[  FAILED  ] AzQtComponents.FloatToString_TruncateShowThousandsSeparatorOnlyOneDecimalWithLocale
#

the camera one also has to do with focus changes, so if something changed about native windows, winid, or focus and events, then its whats probably affecting all of hte tests except for floattostring

#

THe float to string thing indicates AzQtComponents::tostring is broken.

EXPECT_EQ(testString, AzQtComponents::toString(1000.1236, numDecimalPlaces, testLocale, showThousandsSeparator));

Failes. If you decode the unicode,
The floattostring is doing this

String A: 1,000.123
String B: 1000.123

#

, AzQtComponents::toString is broken, and is ignoring showThousandsSeparator, so its missing the comma

#

I'm guessing whats going on here is that the locale on the linux machine is set to somethign like the "C" locale which never adds group seps

#

eg, the tests do this on start:

QLocale testLocale{ QLocale() };
#

Constructs a QLocale object initialized with the default locale.

If no default locale was set using setDefault(), this locale will be the same as the one returned by system().

#

this is not good for tests - if we expect separators to work, we should chjoose a specific locale like en-us

#

AzQtComponents::toString doesn't actually add the comma sep to the string, it just removes it if present already

#

it just does locale.toString(value, 'f', (numDecimals > 0) ? numToStringDecimals : 0);

#

so yeah, bug in test perhaps

#

tests need to set their preconditions such that they work the same on any machine

#

so probably to fix those tests we should do QLocale testLocale("en-US" ); instead of QLocale testLocale{ QLocale() }; in them

rare arch
#

I'll have to look into this.

stark fern
#

there could be a number of reasons why its not working under 6 when it worked under 5, the commonality is focus handling though all of those tests deal with focus changing and pumping the event pump

rare arch
#

I have some fixes for those tests. I am not sure how to contribute it to the PR.

rare arch
#

Windows tests succeeded. Linux tests that relate to my work is resolved.
Mac and iOS Asset builds are failing, and there are linux failures that reside beyond my work:

pulsar pecan
#

I'll see what I can do about Mac + iOS at the end of the week

rare arch
#

Finally my tests came through successful.

The remaining Linux issues are:

Qt6 PR #19567 - Linux CI: missing libxcb-cursor0

17 of 17 remaining Linux failures root in one missing apt package on the runner. Qt 6.5+ requires libxcb-cursor0 to load the xcb QPA plugin; without it the loader falls back to minimal, and binaries that need a real platform abort on QApplication construction. AssetProcessor is one of those binaries, which cascades into every pytest that calls ly_test_tools.o3de.asset_processor.start().

Evidence

qt.qpa.plugin: From 6.5.0, xcb-cursor0 or libxcb-cursor0 is needed to load the Qt xcb platform plugin.
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized.

AP's stderr is written to /tmp/tmpXXX/ on the runner and not piped to the CI log, so the cascade tests only show AssetProcessorError: AssetProcessor immediately quit with errorcode -6 in LyTestTools. Same root cause.

Failures

Failure mode Tests
Subprocess abort on QApplication ctor AZ::AzQtComponents.Tests.main, Gem::EMotionFX.Editor.Tests.main
AP exits -6 -> pytest cascade LyTestTools_Integ_Sanity.smoke, APTests.Batch_2_Main, APTests.ap_builder_test, Atom_Main_Null_Render_{Level_Loads,01,02,03,MaterialEditor,MaterialCanvas}, PhysicsTests_Main, WhiteBoxTests, PrefabTests_Main, TerrainTests_Main, MultiplayerTests_Main, EditorTestTesting

Fix

Add to the Linux runner's apt step (alongside the existing Qt deps):

sudo apt-get install -y libxcb-cursor0

Workarounds if the runner image is frozen: QT_QPA_PLATFORM=minimal in CTest env (loses tests that need a real platform), or run under Xvfb. (minimal not recommended by Nick)

#

Qt6 PR #19784 - Mac/iOS Asset: blind link failure on ImageProcessingAtom.Editor

Mac-Asset and iOS-Asset (same build_asset_mac.sh) both fail. The bin/profile/AssetProcessorBatch was not found line is downstream noise -- xcodebuild's failed-commands summary names one Ld step, libImageProcessingAtom.Editor.dylib, with (1 failure). The actual ld: / Undefined symbols text is nowhere in the 16k-line log: cmake -G Xcode drives xcodebuild in pretty-print mode and drops clang/ld stderr.

Fix

  1. Patch scripts/build/Platform/Mac/build_asset_mac.sh to pass -verbose through to xcodebuild (or set CMAKE_VERBOSE_MAKEFILE=ON). Without this, every Mac link failure on the Qt6 branch will look identical.
  2. Re-run. Strong prior: ImageProcessingAtom.Editor's AUTOMOC list (TexturePreviewWidget, ImagePreviewer, MipmapSettingWidget, ...) implies QOpenGLWidget. Qt6 split that out of Qt::Widgets into Qt::OpenGLWidgets -- add it to the gem's BUILD_DEPENDENCIES if missing.
stark fern
#

nicely done with those changes

#

please bear in mind, due to a mistake in the AR system, minimal platform is attempted but not actually used

#

it doesn't actually set the right params and stuff to actually activate it, altho it tries (you'll see it attempt to set it)

#

the real actual linux platform plugin is used even when we try. If you run it under actual minimal, tests fail even under qt5

rare arch
#

DCO hates me.

stark fern
#

it just checks if "name + address on commit" == "name + address registered in github.com"

#

if you need me to punch through DCO let me know, I can. Although I only do so if I can verify the list of names on all the merge commits are legit

rare arch
#

I can punch it through as well. But all my signoffs are there and identical.

stark fern
#

yeah it is not identical

#

but the entire point of clicking the "hide my email" option and using a proxy address is so that you dont actually reveal your real one

#

so choosing "hide my email" option and then still signing your commits with your REAL address is causing this

rare arch
#

Well that all came as default. I've unhidden my e-mail.

stark fern
#

this one, right ?

image.png
rare arch
#

Yes.

stark fern
#

and so your Primary Email under github is now listed on that same page as [email protected]

#

so then, it should pass DCO

#

and you can probably justifiably force DCO to pass

rare arch
#

Alright, I even made it displayed on my profile for good measure.

#

I set DCO to pass. Hopefully this finally stops all the hassle.
Thanks for the help.

stark fern
#

I think github also has an option to protect yourself against commits being pushed with your real name or email in it if you enable that

#

like if I were to try to make a commit with my actual email address in it, it would actually refuse on push

#

but that requires that option to be ON and to be using the relay email

pulsar pecan
#

@rare arch Sorry, I did a small fix for the linux test failures and it seemed to bring back the DCO issues again

rare arch
#

Ahhhgh. Let me look at it.

#

Passed. I swear it won't be such an issue when we move forward.

#

Dealt with 👌

versed flame
sly wind
#

Dang bad timing the CI just got all green for the first time 😄

#

Is that the first time you try out the qt6 branch ?

versed flame
#

nope, I forget when but it was maybe a month ago? or 3 weeks ago and it was working

sly wind
#

Have you tried with a new project ? Just wanna make sure its not the project or engine cmake cache

versed flame
#

Currently trying to build it from the engine dir with a fresh project in LY_PROJECTS, I just deleted my old cmake build folder and same error

pulsar pecan
#

question is which version of cmake are you using?

#

I havent seen any issues on Linux, but i'm on cmake 4.1

versed flame
#

tried 4.3 and 4.2

pulsar pecan
#

(Ubuntu)

versed flame
#

just tried 4.1.6 and same error

pulsar pecan
#

Ok, I cannot repro this on Ubuntu 24.04, with cmake version 4.3.2

sly wind
#

Can you edit your /home/drogonmar/.o3de/3rdParty/packages/qt-6.10.2-rev5-linux/FindQt.cmake and add
line 16

message(STATUS "path ${QT_PATH}")

line 50

message(STATUS "path ${QT_LIB_PATH}")

#

Just wanna make sure its not targeting a QT version you have on your system

#

Not a pro, but I found it weird that in your configuration you end up calling /usr/lib64/cmake/Qt6CoreTools/Qt6CoreToolsTargetsPrecheck.cmake. I don't think we need any internal cmake handling of QT, the fact that this is triggered could mean its not using the o3de qt

south mica
#

I have Fedora 44 KDE in my old salvaged Xeon system , and i'm building Qt6 branch right now, the only difference is i don't have the Qt6 development libraries installed at all.

versed flame
# sly wind Just wanna make sure its not targeting a QT version you have on your system 
--   path /home/drogonmar/.o3de/3rdParty/packages/qt-6.10.2-rev5-linux/qt
--   path /home/drogonmar/.o3de/3rdParty/packages/qt-6.10.2-rev5-linux/qt/lib
CMake Error at /usr/lib64/cmake/Qt6CoreTools/Qt6CoreToolsTargetsPrecheck.cmake:1 (_qt_internal_should_include_targets)

I fixed it by uninstalling qt6-qtbase-devel which is something I cant just leave uninstalled :(
that log was captured with that devel package installed btw.

south mica
#

Also trying to open O3DE's project manager crashes and outputs this error, i'm at the latest of the qt6 branch.

System: Network layer initialized
qt.qpa.plugin: Could not find the Qt platform plugin "wayland" in ""
Python: RedirectOutput installed
ASSERT failure in QCheckedInt<Int, Impl, FailureReportPolicy> QtPrivate::QCheckedIntegers::operator-(QCheckedInt<Int, Impl, FailureReportPolicy>, QCheckedInt<Int, Impl, FailureReportPolicy>): "Overflow in operator-", file /home/user/.o3de/3rdParty/packages/qt-6.10.2-rev5-linux/qt/include/QtCore/qcheckedint_impl.h, line 69
Aborted                    (core dumped) ./o3de
sly wind
sly wind
#

Can you print the CMAKE_PREFIX_PATH variable as well line 47 ? Just wanna make sure that your IDE is not appending the other QT in there

#

Also, you could try to add NO_DEFAULT_PATH in the find_package at line 55

south mica
sly wind
#

So the editor in qt6 is not crashing for you but project manager is ? Interesting maybe something in the engine boot forces qt to use xcp instead of wayland. Can you try to open the material editor or a lua script from the editor ?

south mica
#

aight.

#

yes, it works fine.\

versed flame
pulsar pecan
sly wind
#

approved 🙂

rare arch
#

What is the current status of things?

  • qt6-qtbase-devel is unable to exist on the same machine as it gets auto-picked up.

  • Project Manager is failing?

  • Wayland is unsupported, and doesn't need to be for this PR?

  • Mac is working/supported now? Ongoing MAC implementation work.

  • All checks have passed as far as I see. 🔥

pulsar pecan
#

Sorry @rare arch I merged in one more update to support pyside6 for mac. The DCO thingy came up again

rare arch
#

Punched through, shouldn't be an issue after this PR. DCO things are HOPEFULLY stable for me now.

pulsar pecan
#

I've been mostly focused on mac+qt6, and for the most part, i can launch the editor and at least view the sponza mesh

vague kindle
#

Good going peeps...

#

I'm hoping to be building dev w/Qt 6.10 before SIGGRAPH in mid July. I'd like to show off dev then....to a bunch of industy peeps, anim/vfx/gaming/vp

vague kindle
#

Is the issue Reece is having related to other issues and is there a GHI for it?

rare arch
rare arch
#

Did a full build of the qt6 branch all the way through on windows 10. All successful, 2 seconds of looking at the engine seems perfectly fine.

uneven kite
stark fern
#

should we update to new lua? We could do so, maybe move it to a fetchcontent. Which is something I've been meaning to ask you about, @uneven kite

Some of our 3p packages uses fetchcontent to fetch and build the source, and some uses the prebuilt 3p package. Is there one that makes it easier to port to use the system tools?

simple sorrel
uneven kite
# stark fern should we update to new lua? We could do so, maybe move it to a fetchcontent. ...

I'm going to give you the canned answer here because it's the most descriptive


FetchContent tends to be the easy case in practice because it usually means vanilla upstream source behind a find_package, so there's no prebuilt binary to ABI-match. Prebuilt gets hard in two situations: when it's a patched fork (the custom Qt 5.15 is the poster child, system Qt5 can't substitute because those patches are load-bearing for the editor), or when there's an ABI constraint (anything linked into the editor's embedded Python has to match that Python's ABI). A prebuilt that's just a vanilla tool the engine shells out to is totally fine, the dxc binary for example, we only need a clean executable, no API matching. So a vanilla prebuilt consumed via find_package is just as swappable as fetchcontent; the thing that actually hurts is carrying custom patches in the 3p.

On Lua specifically: it's already one of the easy ones, it's vanilla and we already swap it to the system Lua downstream behind a bcond. Moving it to fetchcontent wouldn't change that, staying vanilla is what keeps it swappable. And if you do bump the bundled Lua to 5.5, that's genuinely helpful for us (rawhide is already on 5.5), but it'll need the two small compile fixes from the issue I filed (the lua_newstate third arg and the LUA_NUMTAGS removal) either way. Our downstream patches are exactly those, and I'm happy to turn them into a PR.

Net: for anything you want system-substitutable, vanilla upstream plus a standard find_package is the pattern that's worked, and keeping custom patches out of the 3p (or upstreaming them) is what really moves the needle. The Qt5 to Qt6 move is the perfect example, vanilla Qt6 is substitutable in a way the custom Qt5 never could be.```
stark fern
#

I mean, we can always start using fetchcontent with the archived release instead of the git clone, speically for vanilla, but, we have had issues where people can, due to univeristy firewalls, access github via git protocol, but NOT github.rawusercontent

#

so as long as the domain and protocol is just http on a standard port, things tht have a tar archive and don't need to be patched are probably fastest that way

#

however, I was thinking more ofhow much of a problem it is to "suppress" the fetchcontent when you want to use a 3p package that is in the system

#

that shim presented above would have to be executed before the fetchcontent tries to get it

For a 3rd party package version, it works because the 3p system only engages if (NOT TARGET xxxx)

#

for fetchcontent, the usual way the gems do it is they add the module path to their cmake Findxxxx.cmake and then they call find_package(xxxx)

#

which infers that for the fetchcontent version, you would also want to engage that shim script before teh gem runs its cmake file

#

this is only an issue from an architectural standpoint - the design of the system is generally, unless a gem is active/enabled in a project, its not supposed to run its script

#

pre-shimming each possible 3p library, whether its actually used or not, before we execute any gem scripts, breaks that concept.

#

of course, standard fetchcontent ones like whitebox are probably easier to shim properly, becuase they do this

list(APPEND CMAKE_MODULE_PATH ${CMAKE_CURRENT_SOURCE_DIR}/3rdParty)
set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH}

and then later, they rely on the 3p system to call find_package(openmesh)
and they have a Findopenmesh.cmake in that 3rd party folder.

#

technically, to "shim" this, you could just prepend a folder with shims in it with its own Findopenmesh.cmake in that folder

#

you would not actually have to invoke find_package or include it

#

the system will do so, if the gem is used

#

one thing I'm missing is how does it know to call FindTIFF-system.cmake for exmaple, since find_package(TIFF) will try to execute FindTIFF.cmake, not FindTIFF-system.cmake

uneven kite
# stark fern one thing I'm missing is how does it know to call FindTIFF-system.cmake for exma...

It never looks for FindTIFF-system.cmake. The -system suffix is just our source-tree naming so the shims are easy to spot in our repo. At package-build time we copy each one into the engine's cmake/3rdParty/ under the canonical name, so FindTIFF-system.cmake lands as FindTIFF.cmake. Since cmake/3rdParty is on CMAKE_MODULE_PATH, the normal find_package(TIFF) resolution picks up our FindTIFF.cmake ahead of cmake's stock one.

#

For the fetchcontent/gem-local case you described (whitebox prepending its 3rdParty dir, then find_package(openmesh) resolving a Findopenmesh.cmake), the clean approach is exactly what you said: prepend a shim directory to CMAKE_MODULE_PATH and let the gem's own find_package pick it up lazily, only when the gem is enabled, no patch, and it doesn't break the gem-only-runs-when-active model.

The ones that still force a patch are the prebuilt-package libs, because the target is created before any find_package runs, so a prepended shim never gets a chance. If the 3p system had a documented hook there (honor an LY_USE_SYSTEM_<X> convention, or consult a system-override module path before associating), distros could swap to system libraries with zero engine patches, we'd drop Patch0006 entirely and just ship the shim directory.

#

(Sorry to hijack this thread 😆 )

stark fern
#

Thanks for the info!

#

Looks like its actually easier to shim a fetchcontent in this case, since you just prepend. No need to add a "USE_SYSTEM_XXX" to stop the package association

uneven kite
#

Thanks for caring 🙂

stark fern
#

Just trying to understand, so we can direct changes to o3de core to maybe make it even easier

#

note that even with prebuilt libs, the "ly_associate_package" call doesn't force it to download or call find_package, it does that only when someone explicitly tells it to,or when something declares a dependency on the library using the format (3rdParty::libraryname) and the libraryname isn't a target at that moment

#

however, maybe there's a way to add a hook or something

#

or as you say, standardize it

uneven kite
# stark fern however, maybe there's a way to add a hook or something

There is! cmake/3rdPartyPackages.cmake:711 I built out a prototype with

macro(ly_download_associated_package find_library_name)
    unset(package_name)
    # System-library override: when LY_USE_SYSTEM_<name> is ON, skip the bundled
    # download and let the caller's find_package(<name> MODULE) resolve a system
    # Find module on CMAKE_MODULE_PATH. Opt-in per package, so anything without a
    # flag set (e.g. Python) downloads exactly as before.
    if (NOT LY_USE_SYSTEM_${find_library_name})
        ly_get_package_association(${find_library_name} package_name)
        if (package_name)
            ly_enable_package(${package_name})
        endif()
    endif()
endmacro()

Running it now: https://download.copr.fedorainfracloud.org/results/hellaenergy/o3de-experimental/srpm-builds/10557054/builder-live.log

stark fern
#

I'm totally okay with conventions like that

#

lots of software has various config macros

#

bear in mind, its case sensitive, and if you want it to not be, you might have to do a actual string compare in cmake with the ignore case option

#

ie, if you want USE_SYSTEM_PYTHON to work even tho the 3rd party package name is Python

rare arch
#

#1457148819396362362

image.png
sly wind
# rare arch What is the current status of things? - `qt6-qtbase-devel` is unable to exist on...

I'll give a go at this "qt6-qtbase-devel" auto-picked up over the weekend, see if I repro and if adding NO_DEFAULT_PATH in the find_package at line 55 of the .o3de/3rdParty/packages/qt-6.10.2-rev5-linux/FindQt.cmake fixes it. I believe its the only thing really preventing the merge of https://github.com/o3de/o3de/pull/19567 into the dev branch, as other things have workaround and can be picked-up as we see issues arise

stark fern
#

I checked out the Qt branch on this dev machine (windows 11, etc) yesterday, compiled fine, etc.

#

I took note of a few issues but I'm going to verify them in qt5 before I note them as qt6 bugs

sly wind
#

Yeah on windows its pretty solid, its on linux that we get sidetracked by stuff

uneven kite
uneven kite
sly wind
# uneven kite What are the current pain points on Linux? Maybe I can help?

I see 3 things currently which are only on linux:

  1. (Critical) Being able to build o3de qt6 branch while qt6-qtbase-devel package is installed. We might have to make changes to the https://github.com/o3de/3p-package-source/blob/main/package-system/Qt/FindQt.cmake for linux to ensure it never tries to use system packages (changes are indicated to messages above, but this has to be tested)

  2. (Not-critical) On a linux with wayland, check how the Qt6 branch behaves. As wayland is currently not supported, I would expect it to auto-switch to xcp but seems like the project manager didn't

  3. (Not-critical) The packaging issue you mentionned above, with the path of the packages build not being relative

sly wind
uneven kite
stark fern
#

one frustrating thing about the old qt5 stuff was that there was a considerable amount of o3de-ness inside its actual Findqt script

#

which was inside the package

#

which means if we got something wrong in there we had to rev the package instead of the engine

uneven kite
# sly wind I see 3 things currently which are only on linux: 1. (Critical) Being able to b...

Confirmed the repro for point 1, and I have a validated fix. Details below.

Repro (fresh Fedora 44 container, cmake 4.3.0): extract qt-6.10.2-rev5-linux, point a minimal harness at the package's FindQt.cmake the same way the engine consumes it. With no system Qt installed it configures clean against the bundled Qt. Install qt6-qtbase-devel (Fedora 44 ships 6.11.1) and the same configure dies with:

CMake Error at /usr/lib64/cmake/Qt6CoreTools/Qt6CoreToolsTargetsPrecheck.cmake:1 (_qt_internal_should_include_targets): Unknown CMake command

Mechanism: the top-level find_package(Qt6) is actually fine, it resolves the bundled Qt6Config.cmake via the CMAKE_PREFIX_PATH append. The escape happens one level down: the bundled Qt6Core config resolves its tool package through QtPublicDependencyHelpers.cmake:100, which calls find_package(Qt6CoreTools), and that nested find searches the standard system prefixes and lands on /usr/lib64/cmake/Qt6CoreTools (6.11.1). The 6.11 config then calls internal macros that don't exist in the already-loaded 6.10.2 machinery, hence the unknown-command error. So it's a version-skew crash between the bundled Qt's loaded machinery and a newer system config file pulled in mid-resolution.

On the NO_DEFAULT_PATH suggestion, tested both shapes:

  • NO_DEFAULT_PATH alone: finds nothing at all (it also disables the CMAKE_PREFIX_PATH lookup the package relies on).
  • PATHS ${QT_LIB_PATH}/cmake/Qt6 + NO_DEFAULT_PATH: the top-level find succeeds, but the option doesn't propagate into the nested find_package calls inside Qt's own config files, so Qt6CoreTools still escapes to /usr and the crash is identical.

Fix that works (validated under worst case, system qtbase + qtsvg + qttools devel all installed at 6.11.1): pin <Pkg>_DIR for every package shipped in the bundle before the find_package(Qt6 ...) call in FindQt.cmake. Nested finds check <Pkg>_DIR before any search path, so every Qt-internal package resolves from the bundle by construction, and non-Qt finds are completely untouched. That last part matters: I also validated two broader containment approaches (a CMAKE_FIND_USE_* hermetic window, and CMAKE_IGNORE_PREFIX_PATH /usr;/usr/local;/), and both work too, but both also blind the nested find_package(WrapOpenGL) to the system libGL that bundled Qt6Gui legitimately needs, so they only pass with an extra OpenGL pre-seed. The _DIR pinning has no such side effect.

The change, just before the find_package(Qt6 ...) call:

file(GLOB _qt_pkg_dirs LIST_DIRECTORIES true "${QT_LIB_PATH}/cmake/*")
foreach(_qt_pkg_dir IN LISTS _qt_pkg_dirs)
    if(IS_DIRECTORY "${_qt_pkg_dir}")
        get_filename_component(_qt_pkg_name "${_qt_pkg_dir}" NAME)
        set(${_qt_pkg_name}_DIR "${_qt_pkg_dir}")
    endif()
endforeach()

Result with that in place and full system Qt6 6.11.1 installed: configure completes, Qt6_DIR and every component resolve from the bundle (Qt6Core at .../qt/lib/libQt6Core.so.6.10.2), and zero config files load from /usr/lib64/cmake. Happy to share the container repro script if useful, and can PR this against 3p-package-source if you want it there.

stark fern
#

the styling of the inspector is the only weirdness I saw

image.png
#

qt5 above

#

qt6 shows these as having an actual hollow checkbox next to them

#

and squashed

#

I also found a qt6-only crash in trackview

#

If you open up track view, create a sqeuence, click anywhere at all in the view

     [Exception thrown at 0x00007FFF1025C120 (Qt6Core.dll) in Editor.exe: 0xC0000005: Access violation reading location 0x0000000000000008.]    
     Qt6Core.dll!00007fff1025c120()    Unknown
>    EditorLib.dll!CTrackViewDopeSheetBase::OnLButtonUp(QFlags<enum Qt::KeyboardModifier> modifiers, const QPoint & point) Line 534    C++
     EditorLib.dll!CTrackViewDopeSheetBase::mouseReleaseEvent(QMouseEvent * event) Line 398    C++
m_rubberBand->DeleteLater()

m_rubberBand is already null

sly wind
uneven kite
#

I'm working on 2 now.

stark fern
#

and as a minor bug I also see " Target PhysX5.Editor contains AUTOMOC but doesn't have any Q_OBJECT macro in a .h or .hxx file" in the log

#

I'll start working on the m_rubberBand crash

#

I can confirm its active in qt6 and not 5

uneven kite
stark fern
#

it kind of should crash on both qt5 and 6 looking at the code
mousePressEvent does nothing with m_rubberBand, its null
mouseMoveEvent creates m_rubberBand (new)
mouseReleaseEvent invokes m_rubberBand->deleteLater() .

#

so clicking without moving should just crash, unclear why qt5 does not crash on this

#

maybe it gets a mouseMoveEvent spuriously

sly wind
uneven kite
rare arch
stark fern
#

I have targetted this to dev

#

because its actually UB in qt5 also, but we "get away with it"

#

QT5's impl of deletelater is a one liner to call static function QCoreApplication::postEvent which I believes checks for nullptr

void QObject::deleteLater()
{
   QCoreApplication::postEvent(this, new QDeferredDeleteEvent());
}
#

if "this" is nullptr due to invoking (nullptr)->deleteLater()

QCoreApplication::postEvent((QRubberBand*)nullptr, new QDeferredDeleteEvent());

While this is incredibly poor form (invoking a function on a nullptr), the function doesn't actually dereference this, and postEvent is a static function

which causes a warning, since postEvent checks for nullptr:

if (receiver == 0) {
        qWarning("QCoreApplication::postEvent: Unexpected null receiver");
        delete event;
        return;
    }

(m_rubberBand is initialized to nullptr explicilty)

#

in qt6, deleteLater is a much bigger function that immediately dereferences this which is why it immediately crashes...

Qt6 impl of deleteLater starts like this:

...
  Q_D(QObject);
  if (d->deleteLaterCalled)
        return;
...
uneven kite
#

Good catch @stark fern there's got to be more just like it out there.

stark fern
#

I didn't find any and I did a pretty deep dive, but perhaps

#

like, I made sure to open every ui, click "add" / "Delete thing" / move stuff around, connect nodes, type stuff, undo, redo, etc

#

that was the only actual crash

uneven kite
# stark fern I didn't find any and I did a pretty deep dive, but perhaps

I ran a mechanical sweep of all 69 deleteLater() call sites in Code/ and Gems/ on development, classifying each receiver by whether it can be null at the call. One more real instance of the exact same shape: LyShine's UI Animation editor, Gems/LyShine/Code/Editor/Animation/UiAnimViewDopeSheetBase.cpp lines 538 and 546. It's a code clone of TrackViewDopeSheetBase: the constructor sets m_rubberBand to 0, only MouseMoveSelect creates it, and both select branches of OnLButtonUp call m_rubberBand->deleteLater() unguarded, so click-without-drag in the dope sheet should crash on Qt6 the same way (code-identical path, though I haven't runtime-repro'd this one). Everything else unguarded in the sweep turned out to be fresh locals, loop variables, or constructor-created members. Happy to put up the mirror fix if you'd like, or it could fold into #19819 since it's the same one-line guard.

#

suprised it was just one.

sly wind
uneven kite
#

We're getting close!

sly wind
#

Definitely ! Thanks again for the help everyone, if nothing else major arises I think we're pretty much done here 🙂 (with the remaining visual regressions being tackeled progressively after)

uneven kite
#

@sly wind Do you want me to fold 379 into 380?

stark fern
sly wind
uneven kite
#

Note 378 as well, though.

sly wind
#

(I also hope we don't have to rebuild pyside6 on linux with this new qt6 linux rebuild)

sly wind
versed flame
#

The project manager doesnt touch atom or the engines input system, its kinda of a normalish qt application so thats gonna be fine, the problems come when you boot the editor

stark fern
versed flame
uneven kite
#

@sly wind I folded 379 into 380

versed flame
#

Lmk when the qt6-qtbase-devel fix is merged, ill get started on the editor support ASAP when thats in.

sly wind
pulsar pecan
uneven kite
sly wind
uneven kite
#

Okay I'll do it.

uneven kite
#

#380 merged

vague kindle
#

@versed flame PR #380 re Wayland as linked above

versed flame
#

the action for it being uploaded to the s3 bucket is still pending

pulsar pecan
uneven kite
sly wind
uneven kite
#

@stark fern Thoughts on merging Qt6 to development?

stark fern
#

deployed to dev

pulsar pecan
#

i need to update the 3p entry for mac6 as well, so there will be another merge coming into the qt6 branch again. (I also want to fix that last straggler RPATH mentioned in github.com/o3de/3p-package-source/pull/381

uneven kite
#

Ah prob the Mac update @pulsar pecan mentioned.

pulsar pecan
pulsar pecan
#

I've updated the PRs for both, and the AR run for Qt6 is in progress now

uneven kite