| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
[regression]
The problem was that we didn't update the new region when we paint the
rubber band and we scroll at the same time
BT:yes
Task-number: 245766
Reviewed-by: bnilsen
Reviewed-by: andreas
|
|
|
|
|
|
|
|
|
|
|
|
| |
QGLPixelBuffer::generateDynamicTexture() will bind the texture to the
pbuffer regardless. Why this works on Carbon is a mystery, but if we're
to follow our own docs, we should NOT bind the texture to the pbuffer
by default. An explicit call to ::bindToDynamicTexture() is required for
that.
Task-number: 250664
Reviewed-by: Samuel
BT: yes
|
|
|
|
| |
Reviewed-by: Norwegian Rock Cat
|
|
|
|
|
|
|
|
|
|
|
| |
This regression probably happened because of the fix to task 244485
(see 8d500381), which made QFile follow a rename. This means that
QTemporaryFile removes its target when it is deleted.
This fixes a number of caching autotests that are failing.
Reviewed-by: Markus Goetz
BT: yes
|
|
|
|
|
|
|
|
|
|
| |
Cocoa has a different way of dealing with cursors than our heavy handed
approach that we used in Carbon. We simply need to re-implement the
proper function in NSView and set up the rectangles for the cursor
correctly. We also need to expose an QCursor2NSCursor type functions
since the current QCursor::handle() is useless for doing this and we
shouldn't change that. With this change things seem to work much more
like the native stuff for both Carbon and Cocoa.
|
|
|
|
|
|
|
| |
Reviewed-by: Thomas Hartmann
need to check for valid menuBar, otherwise dereferencing will
horribly fail.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The way font propagation work has changed since 4.4: When there is a
stylesheet enabled, font does not propagate.
So when settings a font to the QAbstractItemView, the viewport font will
not change, and hence no QEvent::FontChange on it.
So catch the QEvent::FontChange in QAbstractItemView::event in addition
to QAbstractItemView::viewportEvent. (we seems to use the view's font
everywhere anyway)
Task-number: 250754
Reviewed-by: Jens Bache-Wiig
|
|
|
|
|
|
|
| |
Discovered in Kopete trunk
BT: yes
Reviewed-by: Thierry
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
with Cocoa support on Mac.
The Cocoa API doesn't have a concept of Z-ordering of widgets, and it's
implemented by reordering the widget hierarchy for normal widgets. This
does unfortunately not work for GL widgets, and it's not supported by
Apple. This apparently work with the Carbon AGL API though.
Task-number: 244890
Reviewed-by: Gunnar Sletta
BT: yes
|
|
|
|
|
|
|
| |
Setting properties on an invalid printer is not supported. Use isValid() to check if it valid.
Rev-by: Trond Kjernåsen
Rev-by: Geir Vattekar
|
|
|
|
|
|
|
|
| |
The pen width should not be scaled for cosmetic pens.
Task-number: 247083
Reviewed-by: Trond
BT: yes
|
|
|
|
|
|
|
|
|
|
| |
NSPanels are set to hide when the application becomes inactive by
default. This is not what we wan't for normal dialogs in Qt. This
patch makes this setting explicit, in case the window we're about
to create is a dialog.
Task-number: 250869
Reviewed-by: Trenton Schulz
|
| |
|
| |
|
|
|
|
|
|
| |
This was causing compile warnings.
Reviewed-by: nrc
|
|
|
|
|
|
|
|
| |
Also add support for setting the width and height of the primary surface
using display arguments (which can be good when debugging performace
issues).
Reviewed-by: Donald <qt-info@nokia.com>
|
|
|
|
|
|
|
|
|
|
| |
When this code was written there was never a case when we would not blit
our flips and hence the entire if (!(flipFlags & DSFLIP_BLIT)) business
seems not to have been tested anyway. Since I don't see the point of
this I am taking it out. Might enable us to actually create the primary
surface in video memory more often.
Reviewed-by: TrustMe
|
|
|
|
|
|
|
| |
If connect options are set to include videoonly and creating the primary
surface in video memory fails warn even in release mode.
Reviewed-by: TrustMe
|
|
|
|
|
|
|
|
|
| |
The QVarLengthArray approach makes no sense with DirectFB. Draw.*s is a
regular function call and the receiving function even memcpy's the data
on arrival anyway.
Just call the Draw.* functions one by one
Reviewed-by: TrustMe
|
|
|
|
|
|
|
|
| |
Opacity doesn't play well with PorterDuff so we need to disable the
porter duff when opacity is set. Also the DSBLIT_SRC_PREMULTCOLOR flag
is not the right thing for us.
Reviewed-by: TrustMe
|
|
|
|
| |
Reviewed-by: TrustMe
|
|
|
|
| |
Reviewed-by: TrustMe
|
|
|
|
|
|
|
|
|
| |
Try harder to prevent blends by explicitly checking for alpha pixels in
the source image (unless asked not to).
Can be defined out by #defining QT_NO_DIRECTFB_OPAQUE_DETECTION
Reviewed-by: Donald <qt-info@nokia.com>
|
|
|
|
|
|
|
| |
Make the paintOnScreen case paint directly on the primary surface if the
size of the window surface == size of primary surface.
Reviewed-by: Donald <qt-info@nokia.com>
|
|
|
|
|
|
|
| |
Only enabled in debug builds since it could something that should be
ignored.
Reviewed-by: Donald <qt-info@nokia.com>
|
|
|
|
|
|
|
|
|
|
| |
This was rather broken previously.
For example, porterduff mode does not play well with alpha values and
blends. Also, setting the flags to the existing value is a noop in
DirectFB (checked the code) so bool dirty approach buys us nothing.
Reviewed-by: Donald <qt-info@nokia.com>
|
|
|
|
|
|
|
| |
Fall back to raster engine for formats not supported by dfb rather than
converting the image to a supported format.
Reviewed-by: Donald <qt-info@nokia.com>
|
|
|
|
|
|
| |
RevBy: Mauricek
Details: functions needs to be declared outside of the namespace
|
|\ |
|
| |
| |
| |
| |
| |
| |
| | |
This improves the look of combo box with gtk style which is somewhat a
regression from 4.5.0 since we did not style this part before.
Reviewed-by: nrc
|
|/
|
|
|
|
| |
RevBy: Mauricek
AutoTest: tst_QMenuBar::check_altPress()
Details: We do not allow alt navigation with the windows mobile style
|
|
|
|
|
|
| |
It seems that Vim or Xcode or whatever I was using to paste these
in messed up and added an extra space. Now we should be consistent with
the .cpp files and I found a file that we missed too.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Zero timers on Windows would continue to fire even after being stopped
as long as a new timer was started that reused the pointer address of
the zero timer. Fix this by only re-firing zero timers if the zero
timer hadn't been stopped (we can check this by looking at the
inTimerEvent flag, which is set to false by registerTimer()).
Task-number: 247401
Reviewed-by: Denis Dzyubenko
Reviewed-by: Prasanth Ullattil
|
|
|
|
|
|
|
|
| |
It seems there is a potential for recursion because calling keyDown:
can bubble up to the window which will start the process all over again.
keyDown: will actually call qt_dispatchKeyEvent(), we may as well short
it out here. All the previous cases I tried continue to work and we
don't crash Creator if you are really impatient hitting keys.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 35c26d696cbff269d551c012a212c09692dd6f6b.
The change to QComboBox introduces a behavior change; whereas before
the view container would always get its palette set as a response
to QEvent::PaletteChange, it would now miss this event and rely on
regular palette propagation to get the right contens. The difference
in behavior is that QWidget::setPalette() also resolves the palette
mask, and after 35c26d69 this would no longer happen.
The bug in the embedded dialogs demo is caused by the embedded
dialogs demo. See upcoming commit.
Reviewed-by: Alexis
Reviewed-by: Jens Bache-Wiig <jbache@trolltech.com>
|
|
|
|
|
|
|
|
|
| |
The high precision code path was getting an empty string on the second
call to getstringdata, which was causing it to return empty for the
field. Really only needed to call it once anyway, so use the original
call.
Reviewed-by: Justin McPherson
|
|
|
|
| |
Last of the changes to include behaviour from QPtrVector
|
|
|
|
|
|
|
| |
Looks like they were using the old QPtrVector in qt3, and didn't quite
handle the porting correctly.
Reviewed-by: Lincoln Ramsay
|
|
|
|
|
|
|
|
|
| |
Drawing operations with DirectFB in RGB32 changes the alpha byte to 0.
This doesn't play well with QRasterEngine.
See 5fb7752ff93b31635e64fa321917749744cc9db6 and
34059fba55816496d2570b3306ac2b631b12a5c6
Reviewed-by: TrustMe
|
|
|
|
|
|
|
|
| |
Make it more flexible. This patch allows people to use DFB without
DSFLIP_BLIT. Also, before this patch the flip= options weren't really
used for anything.
Reviewed-by: TrustMe
|
|
|
|
|
|
|
| |
It seems DirectFB doesn't preserve alpha value of a blit unless BLEND is
specified and if it is we need to Clear to transparent first.
Reviewed-by: TrustMe
|
|
|
|
|
|
|
|
|
| |
Using #ifndef QT_NO_OPENSSL without first #include'ing something will
never work. Which means we always include qsslsocket.h. The problem
is: if OpenSSL isn't enabled, then that file is a no-op and we never
include qabstractsocket.h.
Reviewed-by: Markus Goetz
|
|
|
|
|
|
|
|
|
|
| |
We had to revert an earlier fix since it obviously did
not work correctly. However since we do not really need to propagate the
palette on the viewContainer _before_ it is created, we can simply avoid
the issue alltogether as it would happen because we implicitly added
a child widget during the polish of the combo box.
Reviewed-by: nrc
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Gah, my original change (f5ef0eb1a6543abdd29e07c23de7fa1128f6d623) had
its heart in the right place, but it seems that it can cause crashes
on closing where we refuse to give up the first responder and we end up
with a dangling pointer. This lets that case happen (when we have no
focus widget and are setting a nil first responder, there's no reason to
stop that, but it refuses to do that when we do have a focus widget.
Hopefully we don't get in a situation where our focus widget gets out of
sync.
Reviewed-by: Prasanth Ullattil
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Symptom: checkboxes didn't get checked if you press, hold for some
seconds and then release the mouse or stylus.
In QAbstractButton we reacted on the contextMenuEvent that gets sent if
the system recognizes the context menu gesture (tap and hold) and did
call setDown(false).
This change has been done because buttons in tool bars stayed in the
down state when displaying the context menu with this gesture.
I've now moved the handling of this to qtoolbar.cpp.
Task-number: 246619
Reviewed-by: thartman
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
the Cocoa Builds.
The drag move events were compressed based only on the position of the
cursor. It has to be based on both position and the "drag operation" in
native event.
Reviewed-by: nrc
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Mac OS X - cocoa
The filename as NSString that we get from Cocoa does not have
the correct file system encoding. This means that certain characters are
implemented differently than what e.g. QFile::encoded returns. This fix
normalizes the string from cocoa before using it.
Task-number: 249928
Reviewed-by: Trenton Schulz
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In our Cocoa menu we check if we need to send the key event to the
qwidget before the menu has a chance at it, because logically in Qt, the
key event should go to the widget and not the menubar first (a bit
different than what happens on the mac). The way to determine this is to
send a shortcut override event and see if it accepts it. If it does,
that means we should just send it the key event. Previously we were
sending the shortcut override, but not following through on the key
event because we thought (however foolishly). That returning "YES" but
not setting an action would somehow forward the event (it doesn't).
There still seems to be some problems if you have a Dvorak-QWERTY+CWD
layout, but this probably needs to be dealt with at the key mapper
level.
Reviewed-by: Prasanth Ullattil
|
| |
| |
| |
| | |
Someone messed up the whitespace on this comment.
|