| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Reviewed-by: Trust Me
|
| |
|
|
| |
Reviewed-by: Trust Me
|
| |
|
|
| |
Reviewed-by: Trust Me
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Prematurely creating a dialog as a sheet and then calling
exec() on it will show a window w/o decorations. The problem is
that first telling a window to be a sheet, and then tell it to
exec, is unambigious. Because doing the latter implies application
modality (when modality is not set), which again implies not
using a sheet. Calling exec (and setting modality) will win over
window flags, so in this case, we now recreate the window as a
normal app-modal dialog.
Task: 254524
Reviewed-by: Trenton Schulz
|
| |
|
|
|
|
|
|
|
| |
The inputContext's focusWidget was not reset when disabling input
methods.
Thanks to Benjamin P.
Task-number: 257832
Reviewed-by: Denis
|
| |
|
|
|
|
|
|
|
|
| |
It seems there is a bug in AppKit which will automatically reset a
cursor even when it is grabbed, but won't reset it when it's brought
back into the window. The upshot of this is that doing a setCursor()
inside of mouse handling behaves slightly different than on the other
platforms (including Carbon). However, we are at the mercy of Cocoa here
and I would rather have all the other things AppKit does right and live
with this bug which they may fix some day.
|
| |
|
|
| |
Reviewed-by: Trust Me
|
| |
|
|
|
|
| |
documentation.
Reviewed-by: TrustMe
|
| |
|
|
|
|
|
|
|
|
|
|
| |
both visible and invisible widgets.
This is a quick hack to avoid a crash in Qt when setting a focus on a
visible widget that has invisible parent. Proper fix was committed
into master 1a7da7096bbda17197738061902f4489af234bc0, see it's
description for more details.
Task-number: 254563
Reviewed-by: Thierry Bastian
|
| |
|
|
|
|
| |
Usually, "the the" is not proper English
Reviewed-By: Thiago Macieira
|
| |
|
|
|
|
|
|
|
|
| |
My great metal hack simply needs to hack more and not do the "extra"
assign since I'm doing this through a back door in set attribute. We
probably should have had the brushed metal go via an actual QStyle
subclass instead of through the attribute.
Task-number: 253448
Reviewed-by: ogoffart
|
| |
|
|
|
|
|
|
|
| |
When building docs for the mac, qdoc comments for functions defined
in the .h file were not found in any of the .cpp files in the mac
package because they were in the x11 or windows .cpp file. So I
moved them to a .cpp file that is in all the packages.
Task-number: 252496 252492
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The crash only occurred on Windows and X11 when running with
-graphicssystem raster. The reason is that the actual paint device
in QRasterPaintEngine::begin() is changed to pixmap->data->buffer(),
which means QPaintEngine::paintDevice() returns something else than
what it was told to paint on (see cb0c899b56b84154f69ddc545991bc6ded96ab01)
The root of the problem, however, was that we used a weird condition
(painter->worldMatrixEnabled(), added in 345072b9 for Qt 4.4) to find
the target device. We did that because the shared painter was completely
different in 4.4. We refactored it in 4.5.0, and we can only trust
QPaintEngine::paintDevice to be the target device.
Auto-test included.
Task-number: 252837
Reviewed-by: Trond
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The problem was that we didn't take the painter's clip into account
when setting the system viewport ("hard clip"). We only used the system
clip, but we have to use system clip + painter clip, which is the
current engine clip. Unfortunately, we have to calculate it again
since there's no cross-platform way of retrieving it.
This was only a problem with Qt::(Replace|No)Clip, since we
in all other cases combine the old clip with the new one.
(Uber cool) auto test included.
Task-number: 250482
Reviewed-by: Samuel
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
QGLWidget does not support partial updates unless the context is
single buffered and auto-fill background is disabled. The problem
was that QPaintEvent::region() returned the requested update region
without taking into account the limitation of QGLWidget. If QGLWidget
doesn't support partial updates, it means everything has to be updated,
and QPaintEvent::region() must return the whole widget rect.
Auto test included.
Task-number: 241785
Reviewed-by: Trond
|
| |
|
|
|
|
|
|
| |
There are different types depending on Carbon and Cocoa, and it is
probably helpful to point that out.
Task-number: 251001
Reviewed-by: Kavindra
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
an untransformed painter
When passing a painter to QWidget::render, we use the
painter->paintEngine()->systemClip() as the "system viewport",
i.e. all painting triggered by render() should be limited to
this area. The only way to achieve this is by always ensuring the
system clip is clipped to the same area (systemClip &= systemViewport).
The problem however, was that we only did this for transformed
painters. We must of course always do it when there's a systemViewport
set, regardless of whether the painter is transformed or not.
Auto test included.
Task-number: 248852
Reviewed-by: Trond
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
QWidget::childAt() makes some assumptions about its children (they are
all contained in its geometry). This does not hold up when using the
unified toolbar because the toolbar ends up in the "non-client" area.
So, when dispatching an enter/leave event in tooltip show, we end up
dispatching to the wrong widgets and that results in the tooltip
cleverly thinking that it needs to hide itself because we've left the
widget that needs the tooltip. I've special cased this by just having a
"native" mapFromParent() that is only called for on the mac, though
there is nothing that is limiting this from being called on other
platfroms.
Also QWidget::mapFromParent() probably needs to be looked at at some
point.
Task-number: 248048
Reviewed-by: Richard Moe Gustavsen
|
| |
|
|
|
|
|
|
|
| |
RevBy: bnilsen
Task: 249394
Details: When going through the backingstore a repaint in a
toplevel resize should just discard the repaint() as
it will repaint shortly after anyway. This is in line
with the implementation of update().
|
| |
|
|
|
|
|
|
|
| |
Fixed the behavior of the function that was broken by me some time
ago. But anyway this function is for convenience only since
QInputContext that operates on the widget is available to the user
directly.
Reviewed-by: Prasanth Ullattil
|
| |
|
|
| |
Reviewed-by: TrustMe
|
| |
|
|
|
|
|
|
| |
When the current focus widget enforces the creation of the native
window handle we should reset the input context.
Task-number: 249578
Reviewed-by: Brad
|
| |
|
|
|
|
|
|
|
|
|
| |
On X11 when user manually creates a QDesktopWidget object it breaks
notifications from the root window since we have several
QDesktopWidgets that have the same native window id and the
wid->qwidget mapper (QWidgetPrivate::mapper) goes crazy. So whenever
we get x11 event from the root window we cannot find a qwidget that
corresponds to the window id and discard these events.
Reviewed-by: Brad
|
| |
|
