| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
| |
| |
| | |
Reviewed-by: Norwegian Rock Cat
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |
| |
| |
| |
| |
| |
| | |
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
|
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |/
| |
| |
| |
| |
| | |
RevBy: mauricek
Details: using prefix qt_ instead of ::global namespace
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We did not enable hover on list view item views. This is
inconsistent with how QTreeView works as well as different
from how native icon views behave.
Reviewed-by: Prasanth Ullattil
Task number: 242519
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This happens only on keyboard layouts like French. The is mainly due to
the key event processing done by the Input manager. In carbon, the key
down event has to be replayed after the input manager finishes his
processing. In Cocoa, while unmarking we have to accept the current text.
Task-number: 123740
Reviewed-by: nrc
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We can save on some creation and only show the container when we really
need to. It does mean that we need to ensure that everything is correct
on construction as well. It's now factored into another file.
Reviewed-by: Jens Bache-Wiig
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The function was added in fde7f3d03782c801901f511131458d6fcb1021a5
and we believe qFuzzyIsNull is a better naming and more in line
with qFuzzyCompare.
Reviewed-by: Lars Knoll
Reviewed-by: nrc
Reviewed-by: Samuel
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
See also fde7f3d03782c801901f511131458d6fcb1021a5
Reviewed-by: Olivier
Reviewed-by: Samuel
|
| |\ \ |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The main use case for fixed-point support is to build large
arrays of vertices. This can be handled using qvertextype or
something similar at higher levels. So it isn't worth risking
numerical instability in the core classes.
Reviewed-by: trustme
|
|/ / /
| | |
| | |
| | |
| | | |
QTextEdit fakes an infinite width, while QPlainTextEdit defaulted to 0.
This was discovered in creator's auto tests.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We don't need mouse tracking unless there are items in the
scene that either accept hover events or have a cursor set.
This cut-off is extremely efficient in the common case since
all items ignore hover events and use the standard cursor
by default.
We no longer dig for items and do lots of intersection and
calculating just for fun :-) We even get rid of the overhead
of 2 x QCoreApplication::sendEvent!
The next step is to optimize the items(*) functions to
simply check for hasCursor()/acceptsHoverEvents() before
we do complex checks like intersects/collidesWithPath() etc.
Auto test included.
Reviewed-by: Andreas
|
| | |
| | |
| | |
| | |
| | | |
qIsFuzzyNull is much cheaper than qFuzzyCompare, and
in this case qIsFuzzyNull will do the trick.
|
| | |
| | |
| | |
| | |
| | |
| | | |
Add some private inline constructors and do inlining
other places.
All test still pass.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Now that we have QPainterPath::translate, we can use
that instead of itemTransform()/map(To|From)Scene, which
lowers the number of QTransform operations involved.
Reviewd-by: Andreas
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Also removed the old obsolete qkbpc101_qws files. Somehow this removal got
lost in the rebase before the keyboard handler refactoring commit.
Reviewed-by: TrustMe
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Do not update the cache's exposed list if the entire cache
is already exposed.
Makes tst_QGraphicsItem::cacheMode pass again.
Reviewed-by: Andreas
|
|\ \ \
| |/ /
|/| /
| |/
| |
| |
| |
| | |
Conflicts:
src/gui/graphicsview/qgraphicsitem.cpp
src/gui/graphicsview/qgraphicsitem_p.h
src/gui/graphicsview/qgraphicsscene.cpp
src/gui/painting/qtransform.cpp
|
| |
| |
| |
| | |
Reviewed-by: ogoffart
|
| |
| |
| |
| |
| |
| | |
Looks like a typo.
Reviewed-by: Bradley T. Hughes
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
QWidget::childAt() makes some assumptions about its children (they are
all contained in its geometry). This does not hold up when using the
unified toolbar because the toolbar ends up in the "non-client" area.
So, when dispatching an enter/leave event in tooltip show, we end up
dispatching to the wrong widgets and that results in the tooltip
cleverly thinking that it needs to hide itself because we've left the
widget that needs the tooltip. I've special cased this by just having a
"native" mapFromParent() that is only called for on the mac, though
there is nothing that is limiting this from being called on other
platfroms.
Also QWidget::mapFromParent() probably needs to be looked at at some
point.
Task-number: 248048
Reviewed-by: Richard Moe Gustavsen
|
| |
| |
| |
| | |
Reviewed-by: Trond
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
RevBy: bnilsen
Task: 249394
Details: When going through the backingstore a repaint in a
toplevel resize should just discard the repaint() as
it will repaint shortly after anyway. This is in line
with the implementation of update().
|
| |
| |
| |
| |
| |
| | |
RevBy: Samuel
Details: The IMAGE_FROM_PIXMAP has to be doing a local copy or
something, because it is sure not fast...
|