Creator 13 no longer comes to foreground on hitting breakpoint
-
Ubuntu 24.04, Creator 13.0.0. GNOME desktop, running Wayland.
When debugging (a UI program) and code either hits a breakpoint or gets a signal like
SIGSEGVCreator does not come "up-front" as the active window.On my old Ubuntu 22.04 Creator 6.0.2 it certainly does so.
There is a Debugger setting Bring Qt Creator to foreground when application interrupts. That is set on both. However it appears that is not the requirement, I tried unchecking it on old Creator/Ubuntu and Creator still comes up-front e.g. on hitting a breakpoint.
Is it possible this has anything to do with wayland? It is true that on the newer system my application runs under Wayland whereas on my old one it ignores the Wayland setting and runs under xcb. However I would have thought if anything it might matter whether Creator runs under wayland, not the application being debugged? And presumably that is the same on both GNOMEs.
It is possible, I guess, that I made some alteration to GNOME settings to allow this under 22.04, but if so I don't remember, does anyone?
Before I throw the baby out with the bathwater and give up with 24.04/newer Creator/Qt6, to my mind this behaviour is absolutely vital when debugging, certainly if you don't have multiple monitors. It is not viable to hit breakpoints in Creator debugger but be totally unaware of that and so continue trying to interact with the application. I cannot live without this, a vital behaviour in all debuggers!
-
Hallelujah! With some playing it's a Wayland issue.
If I
export QT_QPA_PLATFORM=xcband then runqtcreatorit reverts to Ubuntu 22.04 behaviour and hitting a breakpoint up-fronts the debugger as it used to.If I go back to 22.04 and
export QT_QPA_PLATFORM=waylandthat Creator turns into the non-up-fronting behaviour. And there, but not now, got helpful error message for every up-front:qt.qpa.wayland: Wayland does not support QWindow::requestActivate()I have decided to put that for xcb in my
.bashrcso all my Qt apps, Creator or my own, stick to xcb. Wayland and I just don't get on.I don't totally understand the Ubuntu 22/24.04 GNOME xcb vs wayland situation. I thought they both run Wayland. In the old one I got a message every time I ran a Qt program
Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.Maybe it's changed behaviour in Qt. It seems like Qt programs never used to run under wayland but now they do. Which my change will now revert :)
[As an aside. I also noticed that running under wayland all my Qt applications do not show any window title at all, it's blank, on whatever their main window is. Title appears when run under xcb.]
In some ways I'd actually like to get rid of GNOME using Wayland completely, nothing to do with Qt. In my VirtualBox there are known problems running Wayland where it "runs lines all over the screen" actually making whole screen unreadable depending on size of desktop window/resize, experienced by others too. But that feels like a bigger step for now.
So everyone will presumably be pleased to hear that I will not abandon new Qt/Qt6 stuff on this basis, and so doubtless ask further questions about that when they arise ;-)
-
J JonB has marked this topic as solved on
-
Ubuntu 24.04, Creator 13.0.0. GNOME desktop, running Wayland.
When debugging (a UI program) and code either hits a breakpoint or gets a signal like
SIGSEGVCreator does not come "up-front" as the active window.On my old Ubuntu 22.04 Creator 6.0.2 it certainly does so.
There is a Debugger setting Bring Qt Creator to foreground when application interrupts. That is set on both. However it appears that is not the requirement, I tried unchecking it on old Creator/Ubuntu and Creator still comes up-front e.g. on hitting a breakpoint.
Is it possible this has anything to do with wayland? It is true that on the newer system my application runs under Wayland whereas on my old one it ignores the Wayland setting and runs under xcb. However I would have thought if anything it might matter whether Creator runs under wayland, not the application being debugged? And presumably that is the same on both GNOMEs.
It is possible, I guess, that I made some alteration to GNOME settings to allow this under 22.04, but if so I don't remember, does anyone?
Before I throw the baby out with the bathwater and give up with 24.04/newer Creator/Qt6, to my mind this behaviour is absolutely vital when debugging, certainly if you don't have multiple monitors. It is not viable to hit breakpoints in Creator debugger but be totally unaware of that and so continue trying to interact with the application. I cannot live without this, a vital behaviour in all debuggers!
@JonB said in Creator 13 no longer comes to foreground on hitting breakpoint:
When debugging (a UI program) and code either hits a breakpoint or gets a signal like SIGSEGV Creator does not come "up-front" as the active window.
LOL that brought back memories of a topic I've read here "someday" a long time ago...
IIRC the app was covering the QtCreator debugger / debug-pane, including any breakpoints, options and tools, when crashing or stopping while debugging, so the debugger became completely unusable.Had no idea who this posted, where (category) and when.
Must have been between my registration and 1-2 years ago from now.Started to use the Forum Search function by typing keywords I remember...
Found it now from a Google search...
and surprise surprise, guess whose topic it was... @JonB :))))TADA:
[Memo: the forum search function somehow does not find sh*t when you don't know the exact topic name :D]
Edit:
Funny enough, the topic starts with:@JonB said in Qt::Popup window in debugger seizes up whole windowing system:
I asked this question a long time ago, but never got an answer. I am trying again
So the initial problem or its first appearance was even way before that.
The linked one is the one I was referring to :)
Haven't seen the topic before that, I guess.And looking back now, the issue might also be Wayland related... but not sure...
If debugging is the process of removing software bugs, then programming must be the process of putting them in.
~E. W. Dijkstra
-
@JonB said in Creator 13 no longer comes to foreground on hitting breakpoint:
When debugging (a UI program) and code either hits a breakpoint or gets a signal like SIGSEGV Creator does not come "up-front" as the active window.
LOL that brought back memories of a topic I've read here "someday" a long time ago...
IIRC the app was covering the QtCreator debugger / debug-pane, including any breakpoints, options and tools, when crashing or stopping while debugging, so the debugger became completely unusable.Had no idea who this posted, where (category) and when.
Must have been between my registration and 1-2 years ago from now.Started to use the Forum Search function by typing keywords I remember...
Found it now from a Google search...
and surprise surprise, guess whose topic it was... @JonB :))))TADA:
[Memo: the forum search function somehow does not find sh*t when you don't know the exact topic name :D]
Edit:
Funny enough, the topic starts with:@JonB said in Qt::Popup window in debugger seizes up whole windowing system:
I asked this question a long time ago, but never got an answer. I am trying again
So the initial problem or its first appearance was even way before that.
The linked one is the one I was referring to :)
Haven't seen the topic before that, I guess.And looking back now, the issue might also be Wayland related... but not sure...
@Pl45m4
LOL. I read that one.
There, years ago, I apparently settled for running Qt programs under Wayland in old OS in order to get round a debugging problem for pop-ups which apparently is Xcb issue.
Now for the current one I am settling for running Qt programs under Xcb in new OS to get round debugging problem for breakpoints which apparently is Wayland issue.
Plus ca change, plus c'est la meme chose :)[I can't manage without debugger up-fronting itself on breakpoint. Hopefully I don't have any pop-ups to mess it up now.... :) ]
