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
> ...
> 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
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
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
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
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
> 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
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
> 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
day, 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 j
> -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 a
> 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
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
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
14 matches
Mail list logo
