| Commit message (Collapse) | Author | Age | Files | Lines |
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In some cases we might get an invalid timestamp that is far away in
the future, so remembering it will break all consequent X calls that
require a timestamp because it just contains junk (for example
clipboard will stop working). This happens with XIM+SCIM pair -
whenever we start input method and type something to the widget, we
get a XKeyPress event with a commited string, however the 'serial' and
'time' members of the XEvent structure are not initialized (according
to valgrind) and contain junk.
This reverts commit 2ed015b8a0ffad63f0f59b0e2255057f416895fb.
Reviewed-By: Brad
|
|\ \
| |/
| |
| |
| |
| | |
Conflicts:
src/gui/graphicsview/qgraphicsscene.cpp
src/gui/kernel/qt_cocoa_helpers_mac_p.h
|
| |
| |
| |
| |
| |
| |
| |
| | |
Don't know how this got lost in the original submit since I had added
both.
Task-number: 257080
Reviewed-by: nrc
|
| |
| |
| |
| |
| | |
When an extern function is declared in the scope of another function,
MSVC sometimes ignores the enclosing namespace {}.
|
| |
| |
| |
| |
| | |
We don't use all of them. I also changed the typedefs for the touch
related functions to follow the same naming convention.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
Reviewed-by: trustme
|
| | |
|
|\ \
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/3rdparty/webkit/VERSION
src/3rdparty/webkit/WebCore/ChangeLog
src/3rdparty/webkit/WebCore/generated/JSDOMWindow.cpp
src/3rdparty/webkit/WebCore/page/DOMWindow.idl
src/corelib/io/qdiriterator.cpp
src/plugins/gfxdrivers/directfb/qdirectfbpaintengine.cpp
src/plugins/gfxdrivers/directfb/qdirectfbpixmap.h
tests/auto/qxmlquery/tst_qxmlquery.cpp
tools/linguist/lconvert/main.cpp
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
disabled.
Spend a lot of time looking at this and at the CoreFoundation source
code and it seems that we really do get a notification even after the
notifier is disabled. I suspect there's a race condition between when we
disable the socket notifier, but the kernel flags it as needing a read,
then CoreFoundation just sends the notification without checking if the
CFSocket has been disabled. No further notifications come of course.
Since this breaks the invariant that was set in the assert, I'm
replacing it with an if check.
Task-number: 258198
Reviewed-by: Bradley T. Hughes
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
First, don't call QWSWindowSurface::winId() in the destructor, as it
will actually request a new id if there isn't already one around - which
is a bit silly and highlighted the "real" bug.
Second, make sure QWSDisplay::Data::takeId() asks for 1 new id before
waiting for more ids to arrive. This is because waitForCreation() calls
QWSServer::processEventQueue(). If the events in the queue cause
takeId() to be called, QWSDisplay::Data::takeId() gets called
recursively. Even though there will be a create 15 ids command in the
queue, that will only allow 15 QWSDisplay::Data::takeId() calls to
return. The 16th call to QWSDisplay::Data::takeId() on the stack will
not be able to return because all the IDs have been taken and (because
it has been called recursively) no new create id commands have been
generated. So the 16th call to takeId() spins in waitForCreate().
Reviewed-by: Paul
|
| | |
|
| | |
|
| |
| |
| |
| | |
for other attributes as well.
|
|\ \
| | |
| | |
| | |
| | | |
Reviewed-by: denis
Reviewed-by: Prasanth
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
and add manual testcase.
Provide replacement "screenCount" for numScreens and document numScreens
as obsolete to be more consistent with other APIs.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We need this to support the behavior in Gtk+ where, when
Qt::ToolButtonTextBesideIcon is used, only text labels
for important actions are shown. It will also enable us to
prioritize actions in the future when for instance collapsing
a toolbar.
Task-number: 258290
Reviewed-by: thierry
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
qapplication_x11.cpp
so these two colors don't get overridden by the defaults when kde config is found.
Merge-request: 917
Reviewed-by: Olivier Goffart <ogoffart@trolltech.com>
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is more follow the cue of what is done on X11, mainly, if you are
creating things like messageboxes or file views, you want them to follow
the desktop (yes, you do). If you disable desktop settings aware, you
get the old look. This also meant shifting around some functions into
qt_cocoa_helpers_mac to make them more readily available instead of
living in differnt files. People who use standard pixmap get the old
values, but I think that's fine. If you haven't moved onto standardIcon
(introduced in 4.1), you don't get the latest bling.
Review-by: Jens Bache-Wiig
|
| |
| |
| |
| |
| | |
...to be reverted once it is deprecated.
Reviewed-by: Thierry Bastian <thierry.bastian@nokia.com>
|
| |
| |
| |
| |
| |
| |
| | |
That should fix compilation on platforms that do not have xinput
headers installed.
Reviewed-by: Thiago Macieira
|
| | |
|
| |
| |
| |
| |
| | |
did a small refactor and used QStyleHelper::uniqueName in plastique and
windows styles
|
| |
| |
| |
| |
| | |
We don't translate the painter anymore (we instead set the brush
origin), so we don't have to (and shouldn't) translate the rects here.
|
| |
| |
| |
| |
| |
| |
| |
| | |
The LoadImage function doesn't seem to work for loading cursors from
resources. Also, it isn't marked as deprecated for Windows CE like on
desktop Windows. So we'll just use it again.
Reviewed-by: thartman
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This patch includes lots of refactoring, but the real problem was that
in QWidgetPrivate::paintBackground we call drawPrimitive(PE_Widget) with
a potentialy translated painter, but the opt.rect is not translated.
When having a scroll area the calling function used to translated the
painter and then pass the offset around to rectify. but drawPrimitive
cannot rectify it.
The solution is not to translate the painter but use other way to
rectify the brush
Task-number: 257517
Reviewed-by: bnilsen
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
On the mac, we were setting the absolute path of the file passed in
while we document that we only set the filename. The filename is
actually what all the other Mac apps do, so we should really do it.
Unfortunately, this task laid around longer than it should, but the
description text was bad.
Additionally, fix a bug in the Cocoa version where we would set a proxy
icon for items that didn't exist, this is not a good idea.
Task-number: 220501
Reviewed-by: Trust Me
|
| |
| |
| |
| |
| |
| | |
These functions hide all this horrible casting and
we've had them for a while. When I see them, I try
to replace them as it keeps the code much more readable.
|
| |
| |
| |
| |
| | |
we should include qt_windows.h and not windows.h because we have to
define WINVER to 0x500.
|
| | |
|
| |
| |
| |
| |
| |
| | |
Task-number: 248429
Merge-request: 786
Reviewed-by: Olivier Goffart <ogoffart@trolltech.com>
|
|\ \
| |/
| |
| |
| |
| |
| |
| | |
Conflicts:
src/plugins/kbddrivers/usb/main.cpp
tests/auto/qnetworkreply/tst_qnetworkreply.cpp
tests/auto/qwidget/tst_qwidget.cpp
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The inputContext's focusWidget was not reset when disabling input
methods.
Thanks to Benjamin P.
Task-number: 257832
Reviewed-by: Denis
|
| |
| |
| |
| |
| |
| | |
On 64-bit an id (void *) is 64-bit also, so, it really should be a
pointer, but I'll make it a 64-bit int for the time being just so stuff
compiles.
|
| |
| |
| |
| |
| |
| |
| |
| | |
This is basically the Windows version of the bug fixed in change
82e825ed841bce324a6892fcbace03f9936d4f4f
Merge-request: 855
Reviewed-by: Norwegian Rock Cat <qt-info@nokia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Most Wacom tablet have a coordinate origin at 0 (Bamboo,Intous), but
some tablet (like DTF 720, which have an integrated screen) have a non
zero coordinate origin. Which lead to an errounous y/a tablet pos
reported by Qt tablet event.
Merge-request: 822
Reviewed-by: Norwegian Rock Cat <qt-info@nokia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Basically if you would hide a toolbar in the unified toolbar, you
would still see a little bit of area at the top instead of having
everything flush with the titlebar. This change basically unsures that
the unified toolbar makes a decision to hide itself if all the toolbars
inside it are hidden. It makes the behavior of clicking on the toolbar
button behave more or less correctly since we are going to show the
unified toolbar whether we want to or not.
This all will get the toolbar button switch event to be dispatched in
Cocoa as well.
Also add an optimization for checking if we need to change the geometry.
If we don't have any items the other toolbar areas, we can skip the set
geometry call, which wrecks havoc with things in Cocoa.
We still don't solve the case of someone who has hidden the items with
the toolbar button then goes full-screen, then goes back out. I'm not
motivated to solve it as is because we need to keep track of the
hides we do on the button press vs. other hides from the user and still
people can workaround it easy enough by handling window state change and
doing what is recommended in the docs.
Task-number: 208439
Rev-by: Denis
|
|\ \
| |/
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/sql/drivers/ibase/qsql_ibase.cpp
tests/auto/q3sqlcursor/tst_q3sqlcursor.cpp
tests/auto/qsqldatabase/tst_databases.h
tests/auto/qsqldatabase/tst_qsqldatabase.cpp
translations/qt_ru.ts
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Argh! It's divide by 256 not 265. The worst part was that I used the
same values in Cocoa as well, so they were both "damaged." It should be
good now.
Task-number: 257499
Reviewed-by: Prasanth Ullattil
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |
| |
| |
| |
| |
| |
| | |
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
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The 'public.utf16-plain-text' clipboard type maps newlines to '\r'
instead of '\n'. The NSStringPboardType from NSPasteboard does this
correctly, so first try to get data through this type.
Task-number: 257661
Reviewed-by: Norwegian Rock Cat
|