| Commit message (Collapse) | Author | Age | Files | Lines |
|\ |
|
| |\ |
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
The old implementation caused:
qfiledialog_p.h:102: warning: garbage at end of `#ifdef' argument
|
| | |
| | |
| | |
| | |
| | | |
Qt 4.5 introduced a new network-settings.h file. Adapt all network
autotests to use that file and get rid of qtestnetworkservers.h
|
| |/
|/| |
|
| | |
|
| | |
|
| | |
|
| | |
|
|\ \
| |/ |
|
| |\ |
|
| | | |
|
| |/
| |
| |
| |
| |
| |
| |
| |
| | |
This change was needed since plain readfs/writefds select call to
Open C sometimes jammed. By adding expectfds to select call, the
select seems not to hang anymore but returns.
This workaround should be removed once Open C performs accorinding to
POSIX standard.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Since Open C does not support all pthread funtions, thread termination
in Symbian OS is implemented differently. Before this fix,
QThread::Terminate just terminated the native thread. Because
QThreadPrivate::finish was not called, the 'running', 'finished' etc
flags were not set and thread termination related signals were not
correctly emitted.
In UNIX finish is called by pthread_cancel since thread cancelation
points are set. In Symbian OS we need to call it manually since
pthread_cancel is not supported.
It was necessary to add a new parameter to QThreadPrivate::finish, which
tells whether the native thread handle can be closed or not. This was
required since 'symbian_thread_handle.Terminate' will not succeed if
thread handle is closed. On the other hand we cannot first terminate the
thread and then call QThreadPrivate::finish.
Autotest: qthread and qprocess passes in HW (5800) and Emulator
Review By: miikka.heikkinen@digia.com
|
| |\
| | |
| | |
| | |
| | | |
Conflicts:
src/gui/styles/qs60style_symbian.cpp
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The polish(QWidget*) function is called the first time a widget is
shown and therefore setting the widget's palette in this function will
overwrite the user set palette if one is specified before show() is
called. The solution is to break this into two parts, the first part
sets the global palette in polish(QApplication*) and this is the
part of the palette that is independent of widget. The second part
involves adding the widget specific palettes using the QApplication::
setPalette() function that takes a classname and this is done in the
polish(QWidget*) function.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When a window is hidden, it will call releaseBuffer() on the backing
store which in turn will resize the window surface to a null rect. In
this case, there is no need to update the QImage with the data pointer
since it will be updated on the subsequent beginPaint() when the image
is resized to a valid size again. This also avoids doing unnecessary
locking on the FBSERV heap which still involves a context switch on
older versions of Symbian.
|
| | |
| | |
| | |
| | |
| | | |
Change these lines of code to either make it more consistent or more
readable after review.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This function was implemented using API from Symbian that will be
deprecated. It was never actually suitable anyway since this function
cannot be called after the window has been shown and this needs to be a
runtime decision for Qt. The solution is to use
SetTransparencyAlphaChannel(), but that will come later.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Since Qt on Symbian now destroys the backing store when it gets hidden
or obscured we need to be careful not to use functions like moveRect()
when we don't have a backing store since this function is really a
backing store optimization and therefore assumes one exists.
|
| | |
| | |
| | |
| | |
| | |
| | | |
Its not enough to mask with Qt::Desktop because this enum value also
includes Qt::Window so masking would give us a non-zero result thus
causing the 'if' case to resolve to true which is not what we want.
|
| | |
| | |
| | |
| | |
| | |
| | | |
The previous commit on this file broke compilation. It should have
called setBrush() instead of setColor() to set the Window role of the
palette to use a texture brush.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is duplicated code from the raster paint engine's beginPaint()
function. For translucent windows the previous contents must be cleared
from the backing store before the new content is painted. This class
should probably be re-written as a subclass of the raster version. The
reason we cannot use that implementation directly is because we cannot
use QNativeImage because it doesn't provide anywhere we can do locking.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
One step closer to semi-transparent windows, but not there yet. This
gets the transparent contents into the window, but the previous
contents are not cleared so it keeps drawing the backing store on top
of itself each time a Draw() is done. SetBackgroundColor() indicates
to WSERV that our window is semi-transparent. We also make sure not to
use 'EDrawModeWriteAlpha' when the widget is non-opaque since this
actually changes the alpha channel on the frame buffer (not the
window) so the gives undesired results. It's a faster draw mode though
so we should use it where we can.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Warning, this is completely untested!
Details: This should (in theory) get translucent windows working
but this hasn't been tested yet. The emulator environment
seems to return only 16ColorMU display modes which implies
the window is opague so Qt ignores the translucent flag. HW
seems to create 16ColorMA windows, but it hasn't been tested
there yet either (no time).
|
| | |
| | |
| | |
| | |
| | |
| | | |
backing store with the ARGB32 format (which is slower to draw on), but
we actually want this in some cases so let's do this properly and move
the hacks somewhere else.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is a reverted patch that has been rebased on to another branch and
then caused conflicts so it might contain an error or two. Basically we
need to store the background texture from the style into the palette so
that it can be replaced by applications that don't want it.
|
| | |
| | |
| | |
| | | |
IDs that are available in 3.2RnD environment).
|
| |\ \ |
|
| | |\ \ |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The nativeInitFileName of file engine was not set in rename fallback
case. Now it is set by calling: fileEngine()->setFileName
This error was found with QNetworkDiskCache test case.
|
| | |/ /
| |/| |
| | | |
| | | | |
on top of each other.
|
| |/ /
| | |
| | |
| | | |
d333404c72aa6c707cf389899999f2247454b824
|
| |\ \ |
|
| | | | |
|
| | | | |
|
| | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
In Symbian OS temp file rename will always go to fallback solution
since close for temp file does not really close the handle. The fallback
implements rename by copy and remove. But in symbian OS also the remove
after copy failed since it was done through local 'in' object. However
the file was still open in object doing the remove.
The fix is to close the local 'in' object and use current 'this' object to
remove the file. This object points to QTemporaryFile and it will make sure
that temp file is first closed before trying to remove.
|
| | | |
|
| |/
|/| |
|
|\ \
| |/ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When a window becomes completely obscured either because it has been
hidden or another window is completely covering it, the backing store
should be deallocated to save memory and then re-allocated when the
window is later made visible again.
Reviewed-by: Iain <qt-info@nokia.com>
|
|/
|
|
|
|
|
| |
- Force static inline methods to be actually inline
- Force ARM code for strategic methods
RevBy: axis
|
|\ |
|
| |
| |
| |
| |
| |
| |
| | |
Moved ASSERT in QSelectThread::requestSocketEvents after mutex lock,
since select thread might still have the lock and that's why the
notifier might be in m_AOStatuses hash. After main thread has the
mutex lock, notifier should not be anymroe in hash.
|
|/ |
|
| |
|
|\ |
|
| |
| |
| |
| | |
components when working on Tube HW.
|
| | |
|