| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
into 4.7-integration
* 'qt-4.7-from-4.6' of scm.dev.nokia.troll.no:qt/qt-integration: (73 commits)
Apply Rhys's fix to qpaintengine_vg.cpp to make it compile
Attempt again at fixing the OpenVG paint engine build
Revert "Attempt at fixing compile failure introduced by 4.6 merge in qpaintengine_vg.cpp"
Attempt at fixing compile failure introduced by 4.6 merge in qpaintengine_vg.cpp
Fixing the wrong QUrl usage
When on Symbian use smaller files.
correctly position glyphs for complex languages
Removed inneccessary QGlyphLayout::offsets initialization.
Fix mirrored characters for RTL text in Symbian
QNAM: Add a code comment related to the cache
tst_QSystemSemaphore::processes fixed for WinCE
tst_qsystemsemaphore: fix deployment of lackey.exe for WinCE
tst_qsharedmemory: create multiple instances of lackey.exe on WinCE
tst_qsharedmemory: fix deployment of lackey.exe for WinCE
fix compilation of tst_sharedmemory on Windows CE
QtScript: regression with instanceof operator for QMetaObject wrappers
examples/widgets/stylesheet fix mainwindow.ui
QStyleSheetStyle: fix memory leak on base style change
QNAM HTTP: Fixed a bug when getting empty files with pipelining
Fix window transparency on Symbian.
...
|
| | |\
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
src/openvg/qpaintengine_vg.cpp
src/script/bridge/qscriptqobject_p.h
tests/auto/bic/tst_bic.cpp
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Problem was that we called processEvents() and excluded user input
events. The idea was to only process pending update
requests, but by doing that there's also a chance that user input events
will starve. Also, there's no gurantee that only update requests
will be processed by processEvents(), so a safer solution is to call
"HIViewRender" on Carbon and "displayIfNeeded" on Cocoa. This will for
sure dispatch pending update requests and nothing else (which is exactly
what we want).
No auto test regressions.
Fixes tst_qgraphicsproxywidget::updateAndDelete failure on Carbon.
Benchmarks indicate an increase in performance.
Task-number: QTBUG-7502
Reviewed-by: richard
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This feature was implemented in Carbon and was never ported to Cocoa.
The major problem is the fact that Cocoa draws a line under the titlebar,
regardless of what we say. The only way to avoid drawing that line is
by adding a native toolbar and ask it not to draw its baseline. If there
is not toolbar, as it happens in this case, there is no way to prevent
that line from being drawn. So instead we paint over that line and hope
for the best.
Task-number: QTBUG-8159
Reviewed-by: Richard Moe Gustavsen
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
If you release the mouse over a non-client area, the following
mouse up event contains the mouse button that was released in the
'buttons' state. This is wrong, according to the documentation
(and the native events auto test!)
Reviewed-by: msorvig
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When QCocoaView receives a keyDown or keyUp event, we translate it to QKeyEvent
and deliver it to qt widgets, propagating if necessary. However if none of Qt
widgets accepted the event we should propagate it back to cocoa - to get a beep
from it, or for example if Qt widget is embedded into a native widget.
Task-number: related to QTBUG-6444
Task-number: QTCREATORBUG-698
Reviewed-by: Richard Moe Gustavsen
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When appliction is started with a Japanese input method, the keyboard
layout data might not be avialble. In such cases use the unicode passed
with the NSEvent. Also add key mappping support for the unicode range
U+f700 to U+f747
Task-number: QTBUG-8647
Reviewed-by: Denis
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
4.7-integration
* '4.7' of scm.dev.nokia.troll.no:qt/oslo-staging-1: (53 commits)
remove non wifi interfaces from being handled.
Disable auto-uppercasing and predictive text for password line edits.
Avoid QString reallocation in QTextEngine::itemize()
Remove the Qt 4.7 #if guards that were needed for 4.6
Always redraw the complete control when an input event comes in.
Make sure not to crash if createStandardContextMenu() returns 0 (e.g. on Maemo5)
Fix compilation: include QString in order to use QString.
Fix compile
Block the Maemo5 window attribute values from being assigned to something else on other platforms.
be more verbose when warning about incompatible libraries
Introduce a setAttribute_internal helper
Do not reset state too early on RMB click
Fix for QRadioButtons and QCheckBoxes drawn incorrectly when a style sheet is set.
Speed up creation of the pixmap cache key
Optimize QGtkStyle
fix qmake -project mode
test qlist some more
fix include
Don't print a warning when passing an empty string to QColor
Stabilize QWidget
...
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The application menu is loaded from the qt_menu.nib which only has
English strings. These will now be translated using Qt's own translation
mechanism. Every time a new translator is installed, the menu will now
try to get the new string. Modification of qt_xx.ts files are done in a
different patch.
Task-number: QTBUG-4463
Reviewed-by: MortenS
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This commit makes alien widgets opt in on a
per-widget basis on Mac, set the Qt::WA_NativeWindow
flag when creating the widget to enable. Setting
this flag on widgets that have native child or sibling
NSViews is not supported.
The main use case for alien widgets on Mac is to
improve performance for applications that have complex
user interfaces. Qt can handle thousands of widgets
per window, while Cocoa is designed to use a smaller
number of NSViews in combination with NSCells and
custom control implementations. This commit moves
us in the direction of having a few main NSViews with
"leaf" qwidgets implemented as a custom control.
|
| |/ /
| |
| |
| | |
Reviewed-by: Rohan McGovern
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
QCocoaView has two "back" pointers ot its owning QWidget
and the corresponding QWidgetPrivate. The lifetime of the
QCocoaView might be longer and that of the QWidget if Cocoa
itself holds references to it. In addition accessing a
QWidget that is being destroyed is not safe.
Set both pack pointers to NULL in ~QWidget. This prevents
following stale pointers in the QCocoaView callbacks. This
also means that we'll see the NULL pointers, add gurads for
that.
|
| | |
| |
| |
| | |
Reviewed-by: MortenS
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If one create e.g. a modal dialog from a mouse up event handler, we
qt_button_down global variable was pointing to a widget before the
handler returned. This meant that you could not push another button
in the window, since the qt_button_down would grab the mouse. This
patch clears qt_button_down before sending mouse up events.
Reviewed-by: denis
|
| |\ \ |
|
| | | |
| | |
| | |
| | | |
NSInteger is int/long on 32/64 bit.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
On Mac, we never emit the activation signal of the tray icon with
other reasons than triggered. The reason; it was never implemented.
This patch connect the dots.
Task-number: QTBUG-5770
|
| |/ /
| |
| |
| |
| | |
A test is added when we double-click to verify that both pushed buttons
are the same.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
master-integration
* 'master' of scm.dev.nokia.troll.no:qt/oslo-staging-1:
Incorrect property setter generated by dumpcpp for Microsoft Word 2007.
Cocoa: Implement our own NSApplication subclass
Cocoa: Menu in menubar stays highlighted
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We have avoided doing so up till now, since we cannot always
know if we will be able to use it. If some 3rd-party application
creates NSApplication before Qt, our subclass will never be
used (because of the singleton pattern that NSApplication follows).
However, in most cases, Qt will be used in standalone applications,
or the 3rd-party application will not subclass NSApplication. And
in those cases, we can make certain functionallity more robust.
Rev-By:msorvig
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
If you use the menu bar for a window to open up
another window woth no menu bar, the first menu bar
stays highlighted once it is set as current again.
The reason is that we remove the first menu bar before
cocoa gets a chance to update it correctly. This patch
implements a system for us to post a message/call to
cocoa, so we delay removing the toolbar until after
cocoa has finished closing it properly.
NB: Rather than posting the call to a window on screen, it
would have been better and safer to post it no window, and
then receive the event in the event handler of NSApplication.
But for the moment, we have decided not to subclass NSApplication...
Rev-By:prasanth
|
| |\ \ \
| |/ /
|/| /
| |/
| |
| | |
Conflicts:
src/gui/kernel/qcocoapanel_mac.mm
src/gui/kernel/qcocoasharedwindowmethods_mac_p.h
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This fixes the qmlviewer "sluggish animations and lost
mouse events" issue by making sure we don't block and
wait for for the screen refresh when flushing the
backing store to the screen.
NB: This commit fixes build issues found in f5f62c0bed.
Review: msorvig
Details:
- Don't force repaints, flush the backingstore in response
to a Cocoa paint/display events only.
- Flush once per window.
- Get the CGContext from the window (don't create a new one)
- Don't call CGContextiFlush on the context.
|
| |\ \
| |/
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/gui/kernel/qeventdispatcher_mac.mm
src/gui/kernel/qt_cocoa_helpers_mac.mm
src/gui/widgets/qmenu_mac.mm
tests/auto/qgraphicswidget/tst_qgraphicswidget.cpp
tools/assistant/tools/assistant/centralwidget.cpp
tools/linguist/lupdate/main.cpp
|
| | |
| |
| |
| |
| | |
We need an auto release pool!
(cherry picked from commit 7ad08868de4b3e481a51a3431504fcf42a4bbf6d)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The reason was that QMacCocoaAutoReleasePool included a
a call to NSApplicationLoad(). This call should only be
made for carbon based application anyway, so we just ifdef
it out (event how clumsy the placing of the call is). The
CPU problem came because after the call, [NSApp isRunning]
would return true, an as such, confuse the event dispatcher
later on.
Reviewed-by: MortenS
|
| | |
| |
| |
| | |
We need an auto release pool!
|
| |\ \
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
bin/syncqt
doc/src/deployment/deployment.qdoc
src/corelib/io/qfsfileengine_win.cpp
src/corelib/xml/qxmlstream.cpp
src/opengl/gl2paintengineex/qpaintengineex_opengl2_p.h
tools/assistant/tools/assistant/centralwidget.cpp
tools/linguist/lupdate/main.cpp
|
| | |
| |
| |
| | |
Reviewed-by: Trust Me
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When creating a single dialog in the main function, and tell it
to exec, we run a modal dialog. But there is really no other
window on screen to be modal for. So in that case, since this is
a rather common pattern for Qt applications, we allow users to
quit the application from the dock. But this action is sendt as
an apple event. And and that point in time, cocoa has the the
apple event handler, and refuses to close down the application
because it detects a modal window.
Our solution is to install/overwrite the apple event handler for
kAEQuit _after_ cocoa has finished its own installation. But in
order to do this, we need to wait until [NSApplication run] has
started, otherwise it will not take effect. And that is what this
patch essentially does.
|
| |
|
|
|
|
|
|
| |
This improves 106121a74bca32a6411b9ca968ee415f8bdfbff1 which was incomplete and
didn't work properly for comboboxes (or in general - when a popup window opens
due to a mouse press).
Reviewed-by: Prasanth
|
| |
|
|
|
|
|
|
| |
When delivering mouse events in Qt/Cocoa set the implicit mouse grabber and
deliver the event to it and do not try to propagate the event to the parent
view.
Reviewed-by: Prasanth
|
| |
|
|
|
|
|
|
|
| |
While querying for the text in the pasteboard, it was looking in the
wrong place. The helper function qt_mac_get_pasteboardString() always
searched in generalPasteboard instead of the pasteboard referred by the
QMacPasteboard.
Reviewed-by: MortenS
|
| |
|
|
|
|
|
|
|
| |
Bauhaus uses grabMouse to implement their own Drag and Drop mechanism.
Cocoa port never considered the grabber widget. All the mouse events
will now be routed to the mouse grabber widget.
Task-number: 261245
Reviewed-by: MortenS
|
| |
|
|
| |
Reviewed-by: Trust Me
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
demos/boxes/glshaders.cpp
demos/boxes/vector.h
demos/embedded/fluidlauncher/pictureflow.cpp
demos/embedded/fluidlauncher/pictureflow.h
doc/src/desktop-integration.qdoc
doc/src/distributingqt.qdoc
doc/src/examples-overview.qdoc
doc/src/examples.qdoc
doc/src/frameworks-technologies/dbus-adaptors.qdoc
doc/src/geometry.qdoc
doc/src/groups.qdoc
doc/src/objecttrees.qdoc
doc/src/platform-notes.qdoc
doc/src/plugins-howto.qdoc
doc/src/qt3support.qdoc
doc/src/qtdbus.qdoc
doc/src/qtdesigner.qdoc
doc/src/qtgui.qdoc
doc/src/qtmain.qdoc
doc/src/qtopengl.qdoc
doc/src/qtsvg.qdoc
doc/src/qtuiloader.qdoc
doc/src/qundo.qdoc
doc/src/richtext.qdoc
doc/src/topics.qdoc
src/corelib/tools/qdumper.cpp
src/gui/embedded/qkbdpc101_qws.cpp
src/gui/embedded/qkbdsl5000_qws.cpp
src/gui/embedded/qkbdusb_qws.cpp
src/gui/embedded/qkbdvr41xx_qws.cpp
src/gui/embedded/qkbdyopy_qws.cpp
src/gui/embedded/qmousebus_qws.cpp
src/gui/embedded/qmousevr41xx_qws.cpp
src/gui/embedded/qmouseyopy_qws.cpp
src/gui/painting/qpaintengine_d3d.cpp
src/gui/painting/qwindowsurface_d3d.cpp
src/opengl/gl2paintengineex/glgc_shader_source.h
src/opengl/gl2paintengineex/qglpexshadermanager.cpp
src/opengl/gl2paintengineex/qglpexshadermanager_p.h
src/opengl/gl2paintengineex/qglshader.cpp
src/opengl/gl2paintengineex/qglshader_p.h
src/opengl/util/fragmentprograms_p.h
src/plugins/kbddrivers/linuxis/linuxiskbdhandler.cpp
src/plugins/mousedrivers/linuxis/linuxismousehandler.cpp
src/script/parser/qscript.g
src/script/qscriptarray_p.h
src/script/qscriptasm_p.h
src/script/qscriptbuffer_p.h
src/script/qscriptclass.cpp
src/script/qscriptclassdata_p.h
src/script/qscriptcompiler.cpp
src/script/qscriptcompiler_p.h
src/script/qscriptcontext.cpp
src/script/qscriptcontext_p.cpp
src/script/qscriptcontext_p.h
src/script/qscriptcontextfwd_p.h
src/script/qscriptecmaarray.cpp
src/script/qscriptecmaarray_p.h
src/script/qscriptecmaboolean.cpp
src/script/qscriptecmacore.cpp
src/script/qscriptecmadate.cpp
src/script/qscriptecmadate_p.h
src/script/qscriptecmaerror.cpp
src/script/qscriptecmaerror_p.h
src/script/qscriptecmafunction.cpp
src/script/qscriptecmafunction_p.h
src/script/qscriptecmaglobal.cpp
src/script/qscriptecmaglobal_p.h
src/script/qscriptecmamath.cpp
src/script/qscriptecmamath_p.h
src/script/qscriptecmanumber.cpp
src/script/qscriptecmanumber_p.h
src/script/qscriptecmaobject.cpp
src/script/qscriptecmaobject_p.h
src/script/qscriptecmaregexp.cpp
src/script/qscriptecmaregexp_p.h
src/script/qscriptecmastring.cpp
src/script/qscriptecmastring_p.h
src/script/qscriptengine.cpp
src/script/qscriptengine_p.cpp
src/script/qscriptengine_p.h
src/script/qscriptenginefwd_p.h
src/script/qscriptextenumeration.cpp
src/script/qscriptextenumeration_p.h
src/script/qscriptextqobject.cpp
src/script/qscriptextqobject_p.h
src/script/qscriptextvariant.cpp
src/script/qscriptfunction.cpp
src/script/qscriptfunction_p.h
src/script/qscriptgc_p.h
src/script/qscriptmember_p.h
src/script/qscriptobject_p.h
src/script/qscriptprettypretty.cpp
src/script/qscriptprettypretty_p.h
src/script/qscriptvalue.cpp
src/script/qscriptvalueimpl.cpp
src/script/qscriptvalueimpl_p.h
src/script/qscriptvalueimplfwd_p.h
src/script/qscriptvalueiteratorimpl.cpp
src/script/qscriptxmlgenerator.cpp
src/script/qscriptxmlgenerator_p.h
tests/auto/linguist/lupdate/testdata/recursivescan/project.ui
tests/auto/linguist/lupdate/testdata/recursivescan/sub/finddialog.cpp
tests/auto/qkeyevent/tst_qkeyevent.cpp
tools/linguist/shared/cpp.cpp
|
| | |
| |
| |
| | |
Reviewed-by: Trust Me
|
| | |
| |
| |
| | |
Reviewed-by: Trust Me
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Since mouse tracking is always enabled on all QCocoaView-s, we are
getting mouseMoved events for both parent and child (if mouse is over
the child). In such cases the mouseMoved events are ignored for the
parent view.
We are using the native NSCursor stack for setting the override cursor.
The current implementation for changeOverrideCursor is modified to keep
this stack in sync with Qt's internal list.
Task-number: 258173
Reviewed-by: Morten Sorvig
|
| | |
| |
| |
| | |
Reviewed-by: Trust Me
|
| | |
| |
| |
| | |
Remobe another instance of for ... in use.
|
| | |
| |
| |
| |
| | |
Don't use the "for ... in" syntax. This is Objective-C 2, which is
only supported on 10.5 and up.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Call [NSToolbar setShowsBaselineSeparator] on the (unified) toolbar
if the window contains tabs in document mode.
Task-number: 252660
Reviewed-by: Richard Moe Gustavsen
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
There was an attempt to do this earlier, but it was a bit more complex
than it needed to be. We now do the update on show in Cocoa. Carbon
actually does it all for us, we just need to flip the bit. We may do the
updates to often, but it's better than not enough.
Task-Id: 195445
Reviewed-by: Denis
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| |
| | |
Removed lots of places where we check for Tiger. Now we can assume it.
Reviewed-by: Morten Sørvig
|
