| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
OK. this is a bit strange. It seems the topdata->resizer value is used
to control whether or not we should show a resize handle based on a
count (0 no, non-zero yes). Since we somehow decided that this value
will never be larger than 15, we made it 4-bits wide. There's a "Qt/Mac"
API, QWidgetPrivate::qt_mac_update_sizer(QWidget *, int = 0) which
would adjust this value by the int passed in.. We use that in several places, not excluding
the QStatusBar where we would pass 1 if we want to show, and -1 if we
didn't. Now if you subtract -1 from zero when you are 4 bits wide, well,
bad things happen. Therefore protect that (since if it's at zero we have
succeeded, we don't want to show the resizer). This seems to work well.
The private API is certainly an interesting way of solving the problem,
but is easy to abuse (for example, this code will break if resizer = 1
and we are passed -2 in the function.
Task-number: 257485
Reviewed-by: Prasanth Ullattil
|
|
|
|
|
|
|
|
|
|
|
| |
Seems this was a victim of our cursor fixing. Cocoa does a lot for us
with setting cursors. This meant that we didn't need to do as much
meddling and as a result qt_mac_set_cursor does nothing in Cocoa.
Unfortunately, this broke setOverrideCursor. Luckily Cocoa has a stack
that works exactly like Qt, so we can just use that.
Task-number: 257507
Reviewed-by: Prasanth Ullattil
|
|
|
|
|
|
|
|
| |
Looks like this `&&' was meant to be `||'.
QNetworkProxy::FtpCachingProxy is 5 so it's clearly impossible for type
to be less than 0 and greater than QNetworkProxy::FtpCachingProxy.
Reviewed-by: Aaron Kennedy
|
|
|
|
|
|
| |
The comparison was mistakenly only uppercasing one side, so mixed case
table names were reporting back as if they weren't found for both
QSqlDatabase::record() and QSqlDatabase::primaryIndex()
|
|
|
|
|
| |
When the precisionpolicy is high, and the field is numeric, it was getting
confused as a string field and pulling the wrong length value.
|
|
|
|
| |
Reviewed-by: Donald <qt-info@nokia.com>
|
|
|
|
|
|
| |
Add unsupportedCompositionMode to the output.
Reviewed-by: TrustMe
|
|
|
|
|
|
|
| |
After we implemented hitTest for QCocoaView, this function is no longer
used.
Reviewed-by: Norwegian Rock Cat
|
|
|
|
|
|
|
|
|
|
|
| |
Drag and drop events should consider the WA_TransparentForMouseEvents
attribute like the mouse events. If this attribute is set for a widget,
the event has to be passed to right widget under mouse. The widget is
identified by calling hitTest. In such cases the leave event has to be
delivered to the widget which actually accepted the enter event.
Task-number: 252088
Reviewed-by: Norwegian Rock Cat
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Cocoa calls hitTest on our view to determine if
the view should get the mouse press. We always
said, "yes" and did all the logic ourselves. Turns
out that we can say "no" if I'm transparent to
mouse events and remove all that code where we do
all the work ourselves. Big maintenance win!
For the time being I've kept the
"transparentViewForEvent" method since it might be
useful for others, but no one is using it at the
moment and we may just kill it soon. HitTest should
handle this situation correctly.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Tracking of mouse events was only enabled when enableMouseTracking or
Hover or a tooltip had been set explictly on the item, but this meant
that the dynamic QEvent::Tooltips would never get dispatched. So, in
order to help out people that might use this feature, all QCocoaViews
must pay the mouse move event tax *sigh*.
I added comments in the proper places so that we DO the right thing for
a release where we can force the change in behavior.
Task-number: 257320
Reviewed-by: Denis
|
|
|
|
|
|
| |
Reported via qt-bugs.
Reviewed-By: Peter Hartmann
|
| |
|
|
|
|
|
| |
Tinyint only supports 0-255, so mark it as unsigned despite sign flag,
which have the time is inverted/wrong.
|
| |
|
|
|
|
|
|
| |
This ifdef was simply in the wrong place.
Reviewed-by: Donald <qt-info@nokia.com>
|
|
|
|
|
|
| |
Also. Make sure to call QRasterPaintEngine::end()
Reviewed-by: Donald <qt-info@nokia.com>
|
|
|
|
|
|
|
| |
Move the code from QDirectFBPaintEnginePrivate::(end|begin) into
QDirectFBPaintEngine::(end|begin)
Reviewed-by: TrustMe
|
|
|
|
|
|
| |
Clearifying details on a warning about a function call (setValue())
Task-number: qtp 4.5Workarea
|
|
|
|
| |
Reviewed-by: trustme
|
|
|
|
|
|
| |
Correcting typos
Task-number: 257225
|
|
|
|
|
|
|
| |
This is related to the following fix:
70137e0601549af1056082cdfbb4f141c70befab
Reviewed-by: trustme
|
| |
|
|
|
|
|
|
| |
- as was not the case for the psqlODBC driver
Reviewed-by: Bill King
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There was a bug in the Carbon code when an item went in full-screen,
than out with a unified toolbar. In those cases the toolbars would end
up getting but into the mainwindow area. The reason this was happening
was that we were calling transferChildren() after we had set up our
toolbar. This cause problems because we end up pulling the QToolbars
right out of the unified toolbar. The easiest way to solve this is to
just update the status on it again. This should solve any issues. I also
added some logic to avoid calling this too many times in that one case.
Luckily, this seems to only affect Carbon.
Task-number: 254462
Reviewed-by: Jens Bache-Wiig
|
|
|
|
|
| |
Task-number: 256762
Reviewed-by: TrustMe
|
|
|
|
|
| |
Task-number: 256818
Reviewed-by: Trenton Schulz
|
|
|
|
| |
Reviewed-by: mauricek
|
|
|
|
|
|
|
|
| |
The windowDidResize notification now differentiates an internally
triggered resize from a user triggered resize.
Task-number: 256269
Reviewed-by: Norwegian Rock Cat
|
|
|
|
|
|
|
| |
- case for QVariant::Bool in switch statement was missing
Task-number: 215511
Reviewed-by: TrustMe
|
|
|
|
|
|
| |
These variables are never used.
Reviewed-by: TrustMe
|
|
|
|
|
|
| |
We already do this in QDirectFBWindowSurface::scroll
Reviewed-by: TrustMe
|
|
|
|
| |
Reviewed-by: Thiago
|
|
|
|
|
|
|
|
|
|
|
|
| |
Frameless windows wouldn't get shadows in Cocoa, which they do in
Carbon. You can argue over who is more correct, but the fact is they
can't be inconsistent. Since Cocoa is the newcomer, I'm bending that.
Though it would seem useful to have an ability to provide some developer
control over the shadow. At the moment, the only thing we have to ensure
is that we always turn on the shadow.
Task-number: 254725
Reviewed-by: Denis
|
|
|
|
|
|
| |
A few "fixes" to make that number go down..
Reviewed-by: Thiago Macieira
|
|
|
|
|
|
|
|
|
|
|
| |
Add SuperH to the ever growing list of architectures which can't
correctly dereference a short* which is not 16-bit aligned. Turning this
into a white-list rather than a black list might make sense at some
point, but as QT_ARCH_I386 isn't defined on windows, the white list
looks even uglier at the moment. :-)
Task-number: 257077
Reviewed-by: TrustMe
|
|
|
|
|
|
| |
These two entries were not removed since the server was an OOP server
Reviewed-by: Prasanth
|
|
|
|
|
|
|
|
| |
Coverity was complaining because we were not checking the return
value of find() but instead using the pixmap handle to check the
result. This makes the call more consistent
Reviewed-by: mgoetz
|
|
|
|
|
| |
Task-number: 217003
Reviewed-by: Bill King
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some QDBusAbstractInterface can have empty paths or service names, for
wildcard purposes. If someone tries to make a call using those
interfaces, the application crashes.
So check for the invalid conditions and don't make the call. If we
return 0 here, the message-sending code will generate an error in
QDBusConnectionPrivate.
Reviewed-by: TrustMe
|
|
|
|
|
|
| |
The path /lib/ld-linux.so.2 is correct for i386 only, possibly some
other archs. But on x86-64, it's usually ld-linux-x86-64.so and it can
be in either /lib or /lib64.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is mainly a stop-gap solution for 4.5.x. It trades painting performance
for correct painting.
Commit 7988d05da changed the opaque test from q->testAttribute(Qt::WA_OpaquePaintEvent)
to qt_widget_private(w)->isOpaque in qt_mac_update_widget_posisiton. This means
we'll do optimized moves in more cases. Unfortunately it also causes painting errors
in some cases (see the task).
Revert the commit for now to put the 4.5 branch in a god shape.
Task-number: 252295
Reviewed-by: nrc
|
|
|
|
|
|
|
|
| |
Line and polygon strokes did not respect the join/cap styles set
on a painter.
Task-number: 256914
Reviewed-by: Samuel
|
|
|
|
|
|
|
|
|
|
| |
Use the fully qualified classname at relevant places in the
moc-generated code. Also, QMetaObject::newInstance() needs to
strip the namespace part, since the constructor signatures
don't contain the fully qualified name.
Task-number: 246064
Reviewed-by: Simon Hausmann
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
e65b4879116f4a8b0ee8b09607eef666c68c61d6 )
Changes in WebKit since the last update:
++ b/WebCore/ChangeLog
2009-06-25 Simon Hausmann <simon.hausmann@nokia.com>
Reviewed by and done with Tor Arne Vestbø.
Fix shortcut keyboard handling with plugins on the Qt/Mac build.
When we receive shortcut events like Ctrl+V then the text in the QKeyEvent is
empty. If we're asked to disambiguate the event into a Char keyboard event,
we try to detect this situation and still set the text, to ensure that the
general event handling sends a key press event after this disambiguation.
* platform/qt/PlatformKeyboardEventQt.cpp:
(WebCore::PlatformKeyboardEvent::disambiguateKeyDownEvent):
|
|
|
|
|
|
|
|
|
|
| |
This fixes a bug that occured together with a QProgressDialog.
The signal emission was like:
readyRead readyRead readyRead [...] readyRead finished readyRead
Now finished should be properly at the ending of this sequence.
Task-number: 256630
Reviewed-by: Thiago Macieira <thiago.macieira@nokia.com>
|
|
|
|
|
|
|
|
|
| |
enabled.
This allows mixing of debug and non-debug code (possible on Unix
systems) without causing assertion failures.
Reviewed-by: Bradley T. Hughes <bradley.hughes@nokia.com>
|
| |
|
|
|
|
|
|
| |
This bug made us call lock more than we needed to.
Reviewed-by: Donald <qt-info@nokia.com>
|