| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
marshalling code.
Reviewed-By: Harald Fernengel
|
|
|
|
| |
Reviewed-By: Harald Fernengel
|
|
|
|
|
|
|
| |
These tests are useful in QDBusMessage and QDBusAbstractInterface. It
avoids having the same messages all over the place.
Reviewed-By: Harald Fernengel
|
|
|
|
|
|
|
| |
I'm wondering if I should be adding com.trolltech.QtDBus stuff
now. But since there's already one there, I don't see why not...
Reviewed-By: Harald Fernengel
|
|
|
|
|
|
|
| |
Also reorganise a bit, moving the function to create the interface
name from an object's class name to qdbusmisc.cpp too.
Reviewed-By: Trust Me
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Added documentation about the create_prl and link_prl to the CONFIG variable in the qmake manual
Task-number: 165165
Rev-by: Geir Vattekar
Rev-by: Volker Hilsheimer
|
|
|
|
|
| |
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
|
|
|
|
| |
Reviewed-by: kh
|
| |
|
|
|
|
|
|
|
|
| |
Noticed while looking into task 256903, since in case there are no
recent shown pages,we would start Assistant only showning the search.
Task-number: 256903
Reviewed-by: kh
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
Also made sure that the generated code will not have trailing
whitespaces.
Reviewed-by: Thiago Macieira <thiago.macieira@nokia.com>
|
|
|
|
| |
Reviewed-by: kh <qtc-committer@nokia.com>
|
| |
|
|
|
|
|
|
|
| |
resulted in wrong choice of unique properties for characters 451-45f.
Reviewed-By: Thiago Macieira <thiago.macieira@nokia.com>
Reviewed-By: Denis Dzyubenko <denis.dzyubenko@nokia.com>
|
|
|
|
|
|
| |
- as was not the case for the psqlODBC driver
Reviewed-by: Bill King
|
|
|
|
| |
Task-number: 218935
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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: 253902
Reviewed-by: Thierry Bastian
|
|
|
|
|
| |
Task-number: 256762
Reviewed-by: TrustMe
|
|
|
|
|
| |
Task-number: 256818
Reviewed-by: Trenton Schulz
|
|
|
|
| |
Reviewed-by: mauricek
|
|
|
|
|
|
|
|
| |
Information on issues with the icc compiler has been moved in the docs.
Redirected links that still pointed to the old location.
Task-number: 257039
Reviewed-by: Morten Engvoldsen
|
| |
|
|
|
|
|
|
|
|
| |
The windowDidResize notification now differentiates an internally
triggered resize from a user triggered resize.
Task-number: 256269
Reviewed-by: Norwegian Rock Cat
|
| |
|
|
|
|
|
|
| |
The configuration option was not added to the Windows configure.
Reviewed-by: hjk
|
|
|
|
| |
Reviewed-by: Gareth Pethig
|
|
|
|
|
|
|
| |
- 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
|
|
|
|
|
| |
Merge-request: 760
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
Created a table showing the use of different data types in relations with different Qt-supported Databases. Also reviewed by
Task-number: 182851
Rev-by: Geir Vattekar
Rev-by: David Boddie
Rev-by: Bill King
|
|
|
|
|
|
| |
These two entries were not removed since the server was an OOP server
Reviewed-by: Prasanth
|
|
|
|
|
|
|
| |
This was basically a problem with shadow builds not being able to
access the pixmap.
Reviewed-by:eskil
|
|
|
|
|
|
|
|
| |
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
|