Ahh yes.. Good point..
99% of my mapTo usage is with event handler and menus... but Andre is 100%
correct
From: Interest
[mailto:interest-bounces+scott.bloom=onshorecs@qt-project.org] On Behalf Of
André Somers
Sent: Wednesday, February 17, 2016 22:29
To: interest@qt-project.org
Subject:
Thanks again, Tony, this works perfectly for me now.
On 18/02/16 4:59 pm, Tony Rietwyk wrote:
Hi Frank - sorry for replying to you directly before!
Have you looked at event filtering? A derived QObject can monitor,
and supress events going to another QObject - including windows. So:
-
Op 18/02/2016 om 05:33 schreef Scott Aron Bloom:
If you know the parent, you can use parent->mapToGlobal( QRect ) to
find the global rectangle.
You don't need to know the parent if you call mapToGlobal on the widget
itself, using a rectangle with the right size at origin (0,0).
André
Thanks Tony,
that sounds way more sensible than my approach.
I will try this and report back.
Cheers,
frank
On 18/02/16 4:59 pm, Tony Rietwyk wrote:
Hi Frank - sorry for replying to you directly before!
Have you looked at event filtering? A derived QObject can monitor,
and supress events
Thanks Scott,
I'm pretty sure I tried that but I will give it another go.
My transparent widget is parented to the parent app, so geometry()
should return all I need to know.
Also, the fact that moving the parent window slightly makes geometry()
return the expected pos() does make it look like
In the docs for QWidget::geometry() it says whats going on here..
http://doc.qt.io/qt-5/qwidget.html#geometry-prop
"This property holds the geometry of the widget relative to its parent and
excluding the window frame."
It does NOT return a global position, if you want a global position, you
Hi Frank - sorry for replying to you directly before!
Have you looked at event filtering? A derived QObject can monitor, and
supress events going to another QObject - including windows. So:
- when the hot key occurs, you installEventFilter on the current window,
- if KeyPress Esc,
Hi Tony,
sorry, let me clarify:
QT's co-oridnate system starts at the top left, right?
So when I scale the window by dragging the left side (or the top), the
point of origin changes and thus I expect a different global position
for the widget.
The reason I am tying to determine the exact
anybody?
is this a bug?
On 16/02/16 12:21 pm, Frank Rueter | OHUfx wrote:
Hi,
I am trying to figure out my host application's window geometry
reliably and am struggling a bit.
I use QApplication.activeWindow().geometry() to drive my custom
widget's geometry (I need to sit exactly on top of
Today I built another port Qt Charts for MinGW 4.9.2 32-bit on Windows.
And it works for me. Should work for you.
If you already tried to msvc2013, then just uninstall and then again
add Qt Charts via the Qt Maintenance Tool.
I will be glad reviews and suggestions.
Details below.
16.02.2016,
Hi,
I’m embedding a QMacNativeWidget into another application plugin window.
Before embedding, the plugin window doesn’t do anything with the keyboard
input, so, it flows down to the host, performing utility and important
functions. As soon as I embed the QMacNativeWidget into into the plugin
Hi,
I need to use libpng directly (for handling 16-bit depth & custom color
spaces correctly) in a Qt application.
>From your experience, what is the best way? Is it possible to use the
libpng from Qt, or is it better to use a separately built libpng? This
could lead to duplicate symbols when
12 matches
Mail list logo
