| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
|
|
|
| |
Task-number: 259143
Merge-request: 1119
Reviewed-by: Denis Dzyubenko <denis.dzyubenko@nokia.com>
|
|
|
|
|
|
|
|
|
|
| |
The HideNameFilterDetails was not taken in account for windows
file dialog. This patch fix that. For Windows Vista and later we use
now the new COMMON_ITEM_DIALOG API (in master) where it add always
the filter extension like *.txt so no point to take that flag in account.
Task-number: None, during testing
Reviewed-by: prasanth
|
|
|
|
|
|
|
|
|
| |
If there is severals matching items but all of them are disabled, it
would have produced an infinite loop.
Block the loop once we reach an already matched item.
Task-number: 258949
Reviewed-by: Thierry
|
|
|
|
|
|
|
|
|
|
| |
We never told Cocoa that it needed to redraw the window view
when a window was shown. This is implicit if the window is
shown for the first time, but needs to be done explicit
if you hide and show it again.
Task-number: 254672
Reviewed-by: bnilsen
|
|
|
|
|
|
|
|
|
|
|
| |
The Qt dialog treats extension filters as case insensitive where
the default behavior of the Gtk+ file dialog is to be case
sensitive. The GtkFileFilter allows only simple glob syntax to
be used so we basically rewrite the extension string from .xyz
to .[xX][yY][zZ].
Task-number: 259155
Reviewed-by: joao
|
|
|
|
| |
Reviewed-by:TrustMe
|
|
|
|
|
|
|
|
|
| |
updateAncestorFlags was not reseting the flags if you change the parent
that have for instance itemsClipChildrenToShape to a new one that
doesn't have that flag.
Task-number:258956
Reviewed-by:bnilsen
|
|
|
|
|
| |
Task-number: 254407
Reviewed-by: Gunnar
|
|
|
|
|
|
|
| |
Added the needed macros around the classnames the way it
should be done.
Reviewed-by: Prasanth
|
|
|
|
| |
Reviewed-by:TrustMe
|
|
|
|
|
|
|
|
|
| |
On Windows we will add maximize button to the titlebar even if the
window has a fixed size if the user explicitely asked for it by
setting Qt::CustomizeWindowHint | Qt::WindowMaximizeButtonHint.
Task-number: 250188
Reviewed-by: Leonardo Sobral Cunha
|
|
|
|
|
|
| |
Remove mem leak / warning in the cocoaport
Reviewed-by: msorvig
|
|
|
|
|
|
| |
CFDictionaryAddValue expects a CFNumberRef, not a pointer-to-CFNumberRef.
Reviewed-by: TrustMe
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is because we try to decide whether the window cocoa tells
us to be active should be active, and if we desagree, we do nothing.
The result is that Qt and Cocoa ends up in different states.
I decided to remove a lot of the logic that went on in this case, and
the resons is:
1. By checking the callplaces to
onApplicationWindowChangedActivation, we know that we always have a
valid widget pointer, and we know that the widget always is a window
(otherwise Cocoa would never tell us that the widget got active).
2. We can never end up doing nothing in this response. The best
we can do is to follow what Cocoa tells us. If this turns out to
break something, it would probably be better to check why we get an
activation call in the first place for a window that should not be
activated (e.g. is canBecomeKeyWindow set correctly?)
Task: 253610
RevBy: msorvig
|
|
|
|
|
|
| |
Task: 258895
Reviewed-By: Jens Bache-Wiig
|
|
|
|
| |
Task-number: 258445
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Basically, the crash happends because we release the dialog when
the ok button is clicked. But when the button is clicked with the
keyboard (actually cocoa emulates a click when pressing enter), it
also tries to do some focus handling on the button afterwards. But
at that point, the button is already freed up. With a crash as the
result. This patch goes through a lot of the code, and rewrites it
so we doesnt free up the cocoa objects before the destructor of
the QColorDialog is called.
Task-number: 258445
Reviewed-by: msorvig
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In qt_scale_image_16bit() and qt_scale_image_32bit(), when a sample
point was located on the border between two pixels in the source image,
the sample point was rounded up instead of down. If a sample point was
exactly on the bottom or right edge of the source image, the function
would therefore sample a pixel outside the image. Because of how the
target rectangle is rounded, a sample point will never be exactly on
the top or left edge of the source image, so we will not get a similar
problem there.
I extended the lance test pixmap_scaling.qps.
Task-number: 258533
Reviewed-by: Samuel
|
|
|
|
| |
Reviewed-by: Samuel
|
|
|
|
|
|
|
|
|
|
| |
The problem with the fix, though it produces less flicker when
resizing, is that it delays telling windows that the window has moved
until after the window has been completely repainted. Problem with
this is that functions that rely on windows to be up to date will fail
until the backbuffer is flushed. This was the case for mapTo/FromGlobal, and potentially other functions too.
Reviewed-By: Eskil
|
|
|
|
|
|
|
|
|
|
| |
Priting to PDF would crash for applications built on Leopard when running
on Tiger.
Add the standard runtime version check to QFontEngineMac::faceId().
Task-number: 251791
Reviewed-by: Richard Moe Gustavsen
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Prematurely creating a dialog as a sheet and then calling
exec() on it will show a window w/o decorations. The problem is
that first telling a window to be a sheet, and then tell it to
exec, is unambigious. Because doing the latter implies application
modality (when modality is not set), which again implies not
using a sheet. Calling exec (and setting modality) will win over
window flags, so in this case, we now recreate the window as a
normal app-modal dialog.
Task: 254524
Reviewed-by: Trenton Schulz
|
|
|
|
|
|
|
| |
Polygonal vector paths may have types==null, in which case this
would have crashed.
Reviewed-by: Eskil
|
|
|
|
|
|
|
|
|
| |
The reason being that there was an assumption that any non-curved path
was a continous polyline. For paths with multiple subpaths in it
we need to split this up into multiple strokePolygonCosmetic calls.
Task-number: 257621
Reviewed-by: Kim Motoyoshi Kalland
|
|
|
|
|
|
|
|
|
| |
We normally pad the clip rect with the size of the pen and miterlimit
to avoid this, but this didn't handle the case where there was a long
diagonal dash. We also need to multiply the padding with the longest
dash.
Reviewed-By: Tom Cooksey
|
|
|
|
|
|
|
| |
This is a huge impact on performance whenever this path is
taken.
Reviewed-By: Tom Cooksey
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I'm not all to happy with this fix, but its the best that one can
acheive given the current design. The problem is that QPdfBaseEngine
sets a number of states as part of updateState(), but only when we are
playing back through the alpha engine. These states are used in some
draw functions, also when we are recording in the alpha engine. This
leads to the states and their checks being out of sync. So to follow
the existing pattern in the code we need to not touch d-> vars prior
to a check to usesAlphaEngine.
Reviewed-By: Eskil
|
|
|
|
|
|
|
|
| |
The signal could be connected a huge number of times
This is already fixed in master with Qt:UniqueConnection
Task-number: 258381
|
|
|
|
|
|
| |
I had missed this one in my rounds of updates. Bad me.
Reviewed-by: Thorbjorn
|
|
|
|
|
|
|
|
|
| |
This is confirmed to resolve a number of problems from the original
reportee. It's already fixed in Qt 4.6 in a more wider fix, but this
one liner is a good to have in Qt 4.5.x anyway.
Task-number: 258194
Reviewed-by: alexis
|
|
|
|
|
|
|
|
| |
Don't know how this got lost in the original submit since I had added
both.
Task-number: 257080
Reviewed-by: nrc
|
|
|
|
|
|
|
|
|
|
| |
If you start a hand scrolling and during moving, you press another button
of the mouse than the left one, the scrolling suddently stop working.
In mouseReleaseEvent we just stop the hand scrolling if the button is
left.
Task:258356
Reviewed-by:janarve
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
If the widget under mouse is hidden, Qt can generate a synthetic mouse move
event which gets delivered to the already hidden widget. This can then result
in the wrong item being selected.
Workaround: in QListView, ignore mouse move events when the widget is hidden.
Reviewed-by: Denis
|
|
|
|
| |
Reviewed-by: Volker Hilsheimer
|
|
|
|
|
|
|
|
|
|
|
|
| |
It turns out that we weren't doing any caching of icons provided by the
file system. We now use the similar trick that's used on Windows which
does some caching on the file extension. We do fill up the cache
needlessly with extra information (16, 32, 64, and 128) icons. We
probably could be better with a iconRef engine that generates these
sizes on demand. Still performance is 100% better with this which means
using it in itemviews works.
Reviewed-by: Jens Bache-Wiig
|
|
|
|
|
|
|
| |
Just add a check before calling hooks.
Task-number:258084
Reviewed-by:jbache
|
|
|
|
|
|
| |
native"
This reverts commit a4c4f994fa51ff216f0d43098824617e14b8a284.
|
|
|
|
|
|
|
|
|
| |
Calling OpenThemeData directly causes a leak when
changing the style as we do not call the corresponding CloseThemeData.
Task-number:257916
Reviewed-by:prasanth
|
|
|
|
|
|
|
|
|
| |
The inputContext's focusWidget was not reset when disabling input
methods.
Thanks to Benjamin P.
Task-number: 257832
Reviewed-by: Denis
|
|
|
|
|
|
|
|
| |
We cannot assume the position of the decorations when a QGroupBox get
the focus.
Task-number: 257660
Reviewed-by: Thierry
|
|
|
|
|
|
|
|
|
|
| |
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
|