Re: [Interest] Click and hold on close button
On 8/31/19 5:00 AM, Jason H wrote: https://i.imgur.com/CDqD1KV.jpg - How I imagine Thiago right now. LOL - that's funny. -- Roland Hughes, President Logikal Solutions (630)-205-1593 (cell) http://www.theminimumyouneedtoknow.com http://www.infiniteexposure.net http://www.johnsmith-book.com ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Click and hold on close button
> ... > Replace "thread" with "process" and it correctly matches what Chrome does and > what would work on Qt. > > You cannot start another QApplication in another thread in the same process. > And that's also not what Chrome does. https://i.imgur.com/CDqD1KV.jpg - How I imagine Thiago right now. Anyway an equivalent system would be each tab as a QApplication, with a coordinating master QApplication. I wonder how hard it would be to make the QTabOfApplication and TabBarApplication classes if people wanted to use a similar architecture? (tab process isolation) ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Click and hold on close button
On Thursday, 29 August 2019 05:20:48 PDT Roland Hughes wrote: > This is the architectural flaw of requiring all things GUI to occur in > the main event loop. I haven't dug into the Chrome code, but what you > describe is each tab/pane/whatever executes in its own thread doing > whatever GUI thing it needs so quite honestly it doesn't care when the > thread for the main application blocks as it continues merrily on its way. > > Until we can do all things GUI in other threads, you're hosed. > > Your only other option (and it might be a catastrophe) is to make your > parent/mainwindow/enclosing application its own QApplication of whatever > flavor and have it launch another QApplication in its own thread for > everything visible inside of the decorated frame. I've never tried it, > just a thought which occurred to me before I had even one swallow of Mt. > Dew this morning. Replace "thread" with "process" and it correctly matches what Chrome does and what would work on Qt. You cannot start another QApplication in another thread in the same process. And that's also not what Chrome does. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Click and hold on close button
Il 27/08/19 20:09, Murphy, Sean ha scritto: I've attached a sample application below that can be used to test. When you build and launch it, a QLabel blinks between green and "normal", switching palettes every second. On Windows, if you click and hold on any of those 3 buttons, and while holding the mouse, move off the original button so that the release event doesn't happen on the same button, the blinking will cease the entire time you have the button pressed. Do the same thing on Linux and the QLabel keeps blinking happily the entire time. Please put aside the "conspiracy theories". The very simple reason that the event loop blocks is that Qt doesn't know what to do with that event, and it ends up calling DefWindowProc [1], "the default window procedure to provide default processing for any window messages that an application does not process" [2]. That is a blocking call (!); execution stays in there until the OS knows what to do, which seems to be not until you release the mouse button. If you enable QPA logging in the qt.qpa.events category (e.g. via QT_LOGGING_RULES), and add "verbose" > 2 to your QPA plugin loading (e.g. -platform windows:verbose=2) you'll see the mouse press correctly received by Qt. If also you run your app in a debugger and make it print a stack trace while keeping the mouse pressed on a window decoration button, you'll see the stack trace in there. E.g. C:\> timeout 5 & cdb -p 12345 [timeout trips into the debugger] 0:010> ~* k 0 Id: d90.3334 Suspend: 1 Teb: 0095`0578d000 Unfrozen Child-SP RetAddr Call Site 0095`058fbad8 7ffb`72b44f7a win32u!NtUserMessageCall+0x14 0095`058fbae0 7ffb`72b4470f USER32!RealDefWindowProcWorker+0x1fa 0095`058fbbe0 7ffb`6ecb984e USER32!RealDefWindowProcW+0x4f 0095`058fbc20 7ffb`6ecd24f7 UxTheme!DoMsgDefault+0x2e 0095`058fbc60 7ffb`6ecbc49f UxTheme!OnDwpNcLButtonDown+0xa7 0095`058fbca0 7ffb`6ecbbf81 UxTheme!_ThemeDefWindowProc+0x50f 0095`058fbe80 7ffb`72b44c4f UxTheme!ThemeDefWindowProcW+0x11 0095`058fbec0 7ffb`38488d92 USER32!DefWindowProcW+0x1bf 0095`058fbf30 7ffb`72b4681d qwindowsd!qWindowsWndProc+0x422 0095`058fc170 7ffb`72b46212 USER32!UserCallWinProcCheckWow+0x2bd 0095`058fc300 7ffb`3a30d443 USER32!DispatchMessageWorker+0x1e2 0095`058fc380 7ffb`385524f4 Qt5Cored!QEventDispatcherWin32::processEvents+0x5c3 This also answers why other applications don't freeze -- they must be handling the event internally, keeping their event loops unstuck. For instance, Chromium / Firefox may just be using client-side decorations, and handling clicks on the decoration buttons themselves. (This has nothing to do with the fact that their rendering is out of process, etc.; actually it's highly likely that you need an event loop running in the "main" application, in order to gather the rendering from the other processes.) So why does Qt call into a blocking Win32 API from the main thread? I have absolutely no idea; I'm not a Windows user and I know close to 0 Win32 API programming. Event loop code looks hairy enough, but if anyone knows if there's a "better" way to handle these events, please submit bug reports. [1] https://code.woboq.org/qt5/qtbase/src/plugins/platforms/windows/qwindowscontext.cpp.html#1600 [2] https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-defwindowprocw My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Click and hold on close button
On 8/29/19 5:00 AM, Murphy, Sean wrote: That's just it, I'm not sure that it does work like other Windows applications that don't use Qt. I just tried both Chrome and Windows Media Player and they do NOT exhibit that behavior. For Chrome, if I go to a website that has animations then do the click-and-hold sequence, the animations continue to play. Similarly, Windows Media Player will continue to play the movie while going through those steps. This is the architectural flaw of requiring all things GUI to occur in the main event loop. I haven't dug into the Chrome code, but what you describe is each tab/pane/whatever executes in its own thread doing whatever GUI thing it needs so quite honestly it doesn't care when the thread for the main application blocks as it continues merrily on its way. Until we can do all things GUI in other threads, you're hosed. Your only other option (and it might be a catastrophe) is to make your parent/mainwindow/enclosing application its own QApplication of whatever flavor and have it launch another QApplication in its own thread for everything visible inside of the decorated frame. I've never tried it, just a thought which occurred to me before I had even one swallow of Mt. Dew this morning. -- Roland Hughes, President Logikal Solutions (630)-205-1593 (cell) http://www.theminimumyouneedtoknow.com http://www.infiniteexposure.net http://www.johnsmith-book.com ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Click and hold on close button
Porting an existing application which is in production because of something I would not really consider as an issue (you are closing the window anyways) to something like this would mean maybe hundreds of hours of work and new bugs guaranteed, on all platforms. On Wed, Aug 28, 2019 at 5:25 PM Murphy, Sean wrote: > > > If you want to put the effort for this, port to client side decoration and > > handle events in your application. > > I mostly don't want to have to deal with it at all, mainly because it takes a > decent amount of work to execute that correctly, for no real gain, since I > don't think normal users are likely to do this sequence anyway. The complaint > was from our QA team that naturally tries to doing weird, crazy things to > break the application. > > And I actually just did some client side decoration recently for this > application, and there's issues with that, namely that there are issues with > custom windows on Windows related to the window shadow and a small 6 pixel > band. See my earlier post from 8/19/2019: > https://lists.qt-project.org/pipermail/interest/2019-August/033636.html, so > in that instance I was forced to choose between having a window without a > shadow (which looks weird) or having the small white band above my custom > window buttons (which also looks weird). > > But for me to be able to ignore this, I'm probably going to need to prove > something along the lines of "this is normal Windows behavior, not a bug in > my application". But after light testing with other applications, as well as > the simple application I uploaded here, it appears that this might be a > Qt/Windows problem, not necessarily "all Windows applications do this". > > Sean > > > This message has been scanned for malware by Forcepoint. www.forcepoint.com > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Click and hold on close button
> When it loses focus it stops rendering a cursor altogether (you can test this > out with another application arranged side-by-side with notepad). Good point, so at least in the Notepad case, it does appear to follow the same behavior as my quick Qt sample application - clicking and holding on one of the window minimize/maximize/close buttons causes Notepad's cursor to still be visible, but stop blinking, while clicking & holding on Notepad's title bar (but not on any actual button) allows the cursor to keep blinking. Which I think gives me the ammunition I need to say this isn't my application doing something weird and we shouldn't waste any time (well, at least more than I already have) trying to fix this. Sean This message has been scanned for malware by Forcepoint. www.forcepoint.com ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Click and hold on close button
On Wednesday, 28 August 2019 06:57:18 PDT Murphy, Sean wrote: > > I would just tell the user that it behaves like notepad and 99% of other > > Windows applications. > > That's just it, I'm not sure that it does work like other Windows > applications that don't use Qt. I just tried both Chrome and Windows Media > Player and they do NOT exhibit that behavior. For Chrome Chrome and Firefox aren't good tests because of their multi-process architecture. The renderer process is a child of the one holding the main window, so even if the main process is frozen, the child can still render. The architecture is done because usually the situation is the reverse: the renderer freezes and the main process can kill it and reload. I don't know about the Media Player. It's quite likely that the video itself is decoded entirely out of process, but I thought the feeding of the bytes from the file would come from the process itself. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Click and hold on close button
> If you want to put the effort for this, port to client side decoration and > handle events in your application. I mostly don't want to have to deal with it at all, mainly because it takes a decent amount of work to execute that correctly, for no real gain, since I don't think normal users are likely to do this sequence anyway. The complaint was from our QA team that naturally tries to doing weird, crazy things to break the application. And I actually just did some client side decoration recently for this application, and there's issues with that, namely that there are issues with custom windows on Windows related to the window shadow and a small 6 pixel band. See my earlier post from 8/19/2019: https://lists.qt-project.org/pipermail/interest/2019-August/033636.html, so in that instance I was forced to choose between having a window without a shadow (which looks weird) or having the small white band above my custom window buttons (which also looks weird). But for me to be able to ignore this, I'm probably going to need to prove something along the lines of "this is normal Windows behavior, not a bug in my application". But after light testing with other applications, as well as the simple application I uploaded here, it appears that this might be a Qt/Windows problem, not necessarily "all Windows applications do this". Sean This message has been scanned for malware by Forcepoint. www.forcepoint.com ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Click and hold on close button
If you want to put the effort for this, port to client side decoration and handle events in your application. On Wed, Aug 28, 2019 at 5:05 PM Mitch Curtis wrote: > > > -Original Message- > > From: Interest On Behalf Of Murphy, > > Sean > > Sent: Wednesday, 28 August 2019 3:57 PM > > To: interest@qt-project.org > > Subject: Re: [Interest] Click and hold on close button > > > > > I would just tell the user that it behaves like notepad and 99% of > > > other Windows applications. > > > > That's just it, I'm not sure that it does work like other Windows > > applications > > that don't use Qt. I just tried both Chrome and Windows Media Player and > > they do NOT exhibit that behavior. For Chrome, if I go to a website that has > > animations then do the click-and-hold sequence, the animations continue to > > play. Similarly, Windows Media Player will continue to play the movie while > > going through those steps. > > > > I'm not sure how you would test whether it works with Notepad? I just tried > > it there, and all I can see is that the cursor stops blinking while going > > through > > the click-and-hold sequence. Microsoft Outlook behaves similarly. But I > > guess > > I can't tell if the cursor stops blinking because that application's event > > loop is > > blocked, or if it's because the widget with the cursor is losing focus as > > I'm > > clicking on one of the window control buttons. > > When it loses focus it stops rendering a cursor altogether (you can test this > out with another application arranged side-by-side with notepad). > > > So it seems to be a mixed bag, although it's tough to be sure what I'm > > testing > > since it's not like I have access to those applications' source code. > > > > Sean > > > > > > This message has been scanned for malware by Forcepoint. > > www.forcepoint.com > > ___ > > Interest mailing list > > Interest@qt-project.org > > https://lists.qt-project.org/listinfo/interest > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Click and hold on close button
> -Original Message- > From: Interest On Behalf Of Murphy, > Sean > Sent: Wednesday, 28 August 2019 3:57 PM > To: interest@qt-project.org > Subject: Re: [Interest] Click and hold on close button > > > I would just tell the user that it behaves like notepad and 99% of > > other Windows applications. > > That's just it, I'm not sure that it does work like other Windows applications > that don't use Qt. I just tried both Chrome and Windows Media Player and > they do NOT exhibit that behavior. For Chrome, if I go to a website that has > animations then do the click-and-hold sequence, the animations continue to > play. Similarly, Windows Media Player will continue to play the movie while > going through those steps. > > I'm not sure how you would test whether it works with Notepad? I just tried > it there, and all I can see is that the cursor stops blinking while going > through > the click-and-hold sequence. Microsoft Outlook behaves similarly. But I guess > I can't tell if the cursor stops blinking because that application's event > loop is > blocked, or if it's because the widget with the cursor is losing focus as I'm > clicking on one of the window control buttons. When it loses focus it stops rendering a cursor altogether (you can test this out with another application arranged side-by-side with notepad). > So it seems to be a mixed bag, although it's tough to be sure what I'm testing > since it's not like I have access to those applications' source code. > > Sean > > > This message has been scanned for malware by Forcepoint. > www.forcepoint.com > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Click and hold on close button
> I would just tell the user that it behaves like notepad and 99% of other > Windows applications. That's just it, I'm not sure that it does work like other Windows applications that don't use Qt. I just tried both Chrome and Windows Media Player and they do NOT exhibit that behavior. For Chrome, if I go to a website that has animations then do the click-and-hold sequence, the animations continue to play. Similarly, Windows Media Player will continue to play the movie while going through those steps. I'm not sure how you would test whether it works with Notepad? I just tried it there, and all I can see is that the cursor stops blinking while going through the click-and-hold sequence. Microsoft Outlook behaves similarly. But I guess I can't tell if the cursor stops blinking because that application's event loop is blocked, or if it's because the widget with the cursor is losing focus as I'm clicking on one of the window control buttons. So it seems to be a mixed bag, although it's tough to be sure what I'm testing since it's not like I have access to those applications' source code. Sean This message has been scanned for malware by Forcepoint. www.forcepoint.com ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Click and hold on close button
On 2019-08-27 19:09, Murphy, Sean wrote: One of my users reported an issue that I think falls into the "nothing can be done about it" category, but wanted to see if anyone had any ideas. On a Windows build of our application, if the user clicks AND HOLDS the mouse on any of the Windows buttons (so the standard Windows Minimize, Maximize, and Close buttons) the application's event loop apparently is blocked until the mouse is released. This happens whether it's the QMainWindow window, or any currently shown dialogs. The same application on Linux does not behave this way - at least on Elementary 5.0, I certainly haven't exhaustively gone through all flavors of Linux. But at least on that version of Linux, the user can click and hold the window close button and the application still updates the UI while the mouse button is pressed. I've attached a sample application below that can be used to test. When you build and launch it, a QLabel blinks between green and "normal", switching palettes every second. On Windows, if you click and hold on any of those 3 buttons, and while holding the mouse, move off the original button so that the release event doesn't happen on the same button, the blinking will cease the entire time you have the button pressed. Do the same thing on Linux and the QLabel keeps blinking happily the entire time. FWIW, it works with Firefox, so should be possible, depending on the amount of effort you can put :) I would just tell the user that it behaves like notepad and 99% of other Windows applications. Regards, -- Sérgio Martins | sergio.mart...@kdab.com | Senior Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt, C++ and OpenGL Experts ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Click and hold on close button
You can implement CSD decorations and handle the events in your application. May takes a lot of time though. On Tue, 27 Aug 2019, 21:10 Murphy, Sean, wrote: > One of my users reported an issue that I think falls into the > "nothing can be done about it" category, but wanted to see > if anyone had any ideas. > > On a Windows build of our application, if the user clicks > AND HOLDS the mouse on any of the Windows buttons (so > the standard Windows Minimize, Maximize, and Close buttons) > the application's event loop apparently is blocked until the > mouse is released. This happens whether it's the QMainWindow > window, or any currently shown dialogs. > > The same application on Linux does not behave this way - at > least on Elementary 5.0, I certainly haven't exhaustively gone > through all flavors of Linux. But at least on that version of Linux, > the user can click and hold the window close button and the > application still updates the UI while the mouse button is pressed. > > I've attached a sample application below that can be used to test. > When you build and launch it, a QLabel blinks between green and > "normal", switching palettes every second. On Windows, if you > click and hold on any of those 3 buttons, and while holding the > mouse, move off the original button so that the release event > doesn't happen on the same button, the blinking will cease the > entire time you have the button pressed. Do the same thing on > Linux and the QLabel keeps blinking happily the entire time. > > Sean > > > > > This message has been scanned for malware by Forcepoint. > www.forcepoint.com > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest > ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
