I admit that if a widget looks like a top-level window, one would expect to
see it working [mostly] as a top-level window.
But at the same time I think it's too late to change the current behavior
as it may break some existing code (technically QMdiSubWindow-s are just
child widgets, the fact
On 24-Apr-2013, at 2:57 AM, Immanuel Weber wrote:
did you not post that on the mailing list for a reason or just by mistake?
Crap. By mistake. I'll re-send it; don't be surprised if you get another copy :)
-John
___
Interest mailing list
OK- this time I got the correct message sent to the correct address. Sorry
about that whole series of mistakes. I gotta say, I really disagree with the
general notion that putting the list as the Reply To: is a bad thing...
Yep- I got caught by this one, too. The explanation is that a
Thanks John for the code. It works fine. I'm not really into the qt internals,
I don't know if it is enough to overload in QMdiSubWindow size() and resize()
to account for your code snippets. Should this be reported as a bug?
Am Mittwoch, 24. April 2013 um 17:49 schrieb John Weeks:
OK- this
This is not a bug -- as both John and Qt documentation say, the
frame-client area distinction applies only to top-level widgets/windows
(quote from the page you gave link to: Note that the distinction only
matters for decorated top-level widgets. For all child widgets, the frame
geometry is equal
Hi all,
I'm trying to set the inner area of a QMdiSubArea to a specific size, but
the the resize(..) member of QMdiSubArea includes the frame. As stated in
the documentation (
http://qt-project.org/doc/qt-5.0/qtwidgets/application-windows.html#window-geometry)
resize(..) (belonging to size())
On 23 Apr 2013, at 10:22 PM, Immanuel Weber wrote:
Hi all,
I'm trying to set the inner area of a QMdiSubArea to a specific size, but the
the resize(..) member of QMdiSubArea includes the frame. As stated in the
documentation
