| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
I added the documentation to QWeakPointer::data, but I forgot to
declare the class in the qdoc stub.
Also, apparently I cannot link to a specific overload of a given
function.
Reviewed-by: Volker Hilsheimer
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With the previous commit, you could create a QWeakPointer from any
QObject-derived object. It's possible because QObject now has a
pointer to the QWeakPointer's d-pointer.
However, if you did:
QSharedPointer<QObject> obj(new QObject);
QWeakPointer<QObject> weak1(obj);
QWeakPointer<QObject> weak2(obj.data());
Then weak1 would shared d-pointers with QSharedPointer, but weak2
wouldn't. Also, weak1.toStrongRef() would work, but
weak2.toStrongRef() wouldn't.
This change makes QObject know where the d-pointer created by
QSharedPointer is, so weak2 would get the same d-pointer.
As a nice side-effect, you can check if a given QObject is shared by
trying to promote its QWeakPointer to QSharedPointer.
Reviewed-by: Bradley T. Hughes
|
|
|
|
| |
with d=value=0
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The problem with QPointer is that it's a simple QObject*. So the only
way for QPointer to do what it's supposed to do is if the object it's
pointing to clears all QPointers when getting deleted. That means the
QObject must know each and every QPointer pointing to it. To make
matters worse, QPointers can be deleted while the object they're
pointing to also gets deleted. So deleting QObjects must do locking.
The solution to the QPointer problem is that both QObject and the
"QPointer" reference something outside the QObject. This way,
QObject doesn't have to lock anything to destroy itself: it's simply
setting a volatile integer to zero when it gets deleted. Since the
integer is outside the QObject, the integer is also refcounted. It's also
O(1), so there's no problem having as many "QPointer".
The two-atomic-ints structure is exactly what QSharedPointer and
QWeakPointer use internally. We just abuse this structure for QObject
needs, setting the strong reference count to -1 to indicate that it's
a QObject that cannot be managed by a QSharedPointer. But QWeakPointer
can still work and replace QPointer neatly.
Reviewed-by: Bradley T. Hughes
Reviewed-by: Jarek Kobus
|
|
|
|
|
|
|
| |
GCC has template friends, so I wasn't seeing the error that d is
protected. Thanks to Robert for pointing out.
Reviewed-by: Robert Loehning <robert.loehning@nokia.com>
|
| |
|
|\
| |
| |
| |
| |
| | |
Conflicts:
src/gui/graphicsview/qgraphicsitem.cpp
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The problem was that our glib timers were given too high priority,
effectively starving the Gtk event loop. By assigning our timer source,
G_PRIORITY_DEFAULT_IDLE we ensure that all gtk+ events are handled first,
thus allowing the native dialogs to respond and repaint properly.
Task-number: 258433
Reviewed-by: bhughes
|
| |
| |
| |
| |
| |
| | |
Don't error out when building qmake, just let it build a 64-bit binary (even for carbon)
RebBy: Richard Moe Gustavsen
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If we're going to do changes to simplify some of the Declarative UI
enablers, let's do them all at once. That way, the adaptation
necessary happens only once, as opposed to every time we do the
changes.
I tried not to break by leaving a typedef, but obviously the
QObjectPrivate member isn't affected by the typedef...
Reviewed-by: Trust Me
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This reverts commit 128717b171f01c82e5f0fb83f5923d4f7b9cfc10.
The change broke Alien because QWidget no longer has the native window
handle in its own private. It needs to access the top-level window (or
the one with the native handle) in order to perform some operations.
The problem is that it needs to do that in the destructor. And we
cleared the parent before the destructor was run. Technically
speaking, reverting is the correct thing to do, since the parent
*still* exists when the child is deleted.
|
| |
| |
| |
| |
| |
| |
| |
| | |
This function allows one to retrieve the pointer out of a QWeakPointer
without promoting it to QSharedPointer first. That means there are no
guarantees that the object won't get deleted.
Reviewed-by: Bradley T. Hughes
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Also rename QDeclarativeData to QObjectDeletionNotification, since it
has no relation to declarative UI. It's just notification of the
object's deletion. Make the destructor non-inline and place it in
qobject.cpp, so that the virtual table is emitted there and exported
from QtCore.
Also move the QObjectData destructor to qobject.cpp. This means you
cannot create any class deriving directly from QObjectData outside
QtCore, which is the intention anyways (it's a private class and only
QObjectPrivate derives from it).
Reviewed-by: Bradley T. Hughes
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Accept that we cannot do everything, so users using outdated
toolchains may have threading problems (leaking file descriptors).
It's not like this is a recent problem anyway...
Reviewed-By: Bradley T. Hughes
|
| |
| |
| |
| |
| |
| |
| | |
It will also be used on Mac, so it doesn't make sense to keep it windows
specific.
Reviewed-by: trustme
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This patch allows for input hints to be set on a QGraphicsItem.
Input methods use such hints to define its appearance/behavior
(e.g. to allow for numerical input only).
Reviewed-by: ahanssen
Task-number: 254493
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If you resumed a parallel animation group, it would always restart
(ie. stop and start) the animation which would reset its current time
to 0 and trigger flickering.
autotest included.
Task-Number: 259102
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
It could be that if you start lots of animations, they would not be
started at the same time and even have their first tick to late.
So we needed to only transfer the started animation when receiving the
start/stop timer tick.
In addition, if the animation timer is already active we don't restart
it. This would cause no animation to receive ticks if lots of them are
started.
|
| |
| |
| |
| |
| | |
Also make the "usupported on > 10.6" error a warning. No need
to stop the build, the warning will be printed enough times.
|
| |
| |
| |
| |
| |
| | |
Don't error out when building qmake, just let it build a 64-bit binary (even for carbon)
RebBy: Richard Moe Gustavsen
|
| |
| |
| |
| | |
Reviewed-by: Trust Me
|
| |
| |
| |
| | |
Reviewed-by: Trust Me
|
| |
| |
| |
| | |
Reviewed-by: TrustMe
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
I was making an assumption that one could call CFRunLoopStop and expect
that the runloop would stop very soon afterwards. This is a bit naive
and can result in situations where we end up running past and entering
run again before everything is finished. We now make sure that we don't
leave stop() until the we really have stopped the other thread.
Reviewed-by: mbm
|
| |
| |
| |
| |
| |
| | |
Also add some thread stress tests to try and detect doing it wrong.
Reviewed-By: Bradley T. Hughes
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Currently, if you create a QSharedPointer in code with
pointer-tracking, you must ensure it gets deleted in code with
pointer-tracking, otherwise the internal safety tracker will be
"leaking" objects. The pointers would never get removed.
And if any new pointer happened to have the same pointer address
(which happens quite often), the tracker code would promptly abort the
application.
With this change, the untracking of the pointer is scheduled by the
same code that creates the tracking. This is done by "abusing" the
custom deleter code:
- for the QSharedPointer that used ExternalRefCountWithDestroyFn
already, we intercept the call to the destroy function and call the
untracking function
- for a normal QSharedPointer, we use the "normalDeleter" function as
custom deleter and chain up above
Note: the autotest only *really* works in release mode. Otherwise
functions don't get inlined and do get merged by the linker.
Reviewed-By: Bradley T. Hughes
|
| |
| |
| |
| |
| |
| | |
Destructors have to be run for the subobjects we initialise.
Reviewed-By: Bradley T. Hughes
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We don't support MSVC 6.0 or MSVC .NET 2002, so all compilers we
support can deal with member templates and partial template
specialisation. Remove the #ifdef protecting the code that needed it.
Also add some comments indicating the sizes of the structures. There
is no padding necessary in most cases.
Reviewed-By: Trust Me
|
| |
| |
| |
| |
| |
| |
| | |
That way, this code can be compiled with an earlier version of Qt and
should still work in new ones.
Reviewed-by: Trust Me
|
| |
| |
| |
| |
| | |
In the future, it would be nice to split the autotest in multiple
functions at every check().
|
|\ \
| |/
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/corelib/tools/qsharedpointer.cpp
src/corelib/tools/qsharedpointer_impl.h
src/gui/dialogs/qcolordialog.cpp
src/gui/painting/qwindowsurface_raster.cpp
src/network/access/qnetworkaccessmanager.cpp
tests/auto/qsharedpointer/externaltests.cpp
|
| |
| |
| |
| |
| |
| |
| |
| | |
The functionality is broken, since pointers can be released by a
QSharedPointer tracking a pointer of different type, which would leave
behind pointers in the hash.
The fix requires Qt 4.6 because of a new symbol being added.
|
| |
| |
| |
| |
| |
| | |
Windows Server 2008 R2 is based on kernel 6.1, the same as Windows 7.
Reviewed-by: TrustMe
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When a child is being deleted by its parent, the child should not
notify the parent (of that which it already knows anyway). We did that
by keeping a pointer to the child being deleted. Much simpler to
simply orphan the child.
Reviewed-by: Bradley T. Hughes
|
| |
| |
| |
| |
| | |
1) it's needed for the Declarative UI integration and
2) it hopefully fixes the build on Windows.
|
| |
| |
| |
| |
| |
| |
| | |
The constructors that take a list of target states produce
hard-to-read code, and they're rarely useful in practice since
99% of transitions take a single target state; so it's better
to enforce that setTarget{State,States}() be used instead.
|
| |
| |
| |
| | |
Reviewed-by: Kent Hansen
|
| | |
|
| |
| |
| |
| |
| | |
Broke on WinCE since QStateMachinePrivate is now using
Q_AUTOTEST_EXPORT.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
I'm not sure this is the proper fix, though. xlC 7 complains with:
"/usr/vacpp/include/new", line 97.10: 1540-1298 (I) "void *operator
new(size_t, void *) throw()" needs to be declared in the containing
scope to be found by name lookup.
Also add some calculations to the padding in the data structure.
Reviewed-by: Trust Me
|
| |
| |
| |
| | |
Needed for Declarative UI integration.
|
| |
| |
| |
| |
| | |
QObject::sender() does not return const QObject*, so neither should
this API; it just forces you to const_cast for no good reason.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
There is no monotonic clock support on HP-UXi at all, and the
_POSIX_MONOTONIC_CLOCK macro is not defined at all (not even to
-1). We handle this in the event dispatcher, but not in
qcore_unix.cpp. Since the monotonic clock time code has moved, the
define of _POSIX_MONOTONIC_CLOCK to -1 should also move.
Reviewed-by: thiago
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | | |
Explain the implications in the QWebHistoryItem documentation, and get rid
of the "group".
|
| | |
| | |
| | |
| | | |
Reviewed-by: mbm
|
| | |
| | |
| | |
| | | |
Reviewed-by: Roberto Raggi
|
| | |
| | |
| | |
| | | |
Reviewed-by: Roberto Raggi
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is an internal API used by declarative.
Authored-by: mae
Reviewed-by: Aaron Kennedy
|