summaryrefslogtreecommitdiffstats
path: root/src/gui/kernel
Commit message (Collapse)AuthorAgeFilesLines
* Doc: fix links between QGraphicsItem and QTouchEventVolker Hilsheimer2009-07-201-4/+4
|
* Doc: clarify relevance for QGraphicsItem and add a few \saVolker Hilsheimer2009-07-201-26/+84
|
* Doc: Make QAction::priority/Priority documentation clearerVolker Hilsheimer2009-07-201-9/+9
|
* Fixed includes in the gestures public headers.Denis Dzyubenko2009-07-202-10/+9
| | | | Reviewed-by: trustme
* compile against the Windows 7 SDK RCBradley T. Hughes2009-07-201-15/+16
|
* Merge commit 'origin/4.5'Oswald Buddenhagen2009-07-202-6/+14
|\ | | | | | | | | | | | | | | | | | | | | | | | | 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
| * Fix crash when native socket notifiers would send a notification after being ↵Norwegian Rock Cat2009-07-201-4/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| * Fix deadlock in the QWS server when destroying lots of windowsTom Cooksey2009-07-171-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | Doc: Document QAction::Priority and Qt::ToolButtonFollowStyle.Volker Hilsheimer2009-07-181-4/+25
| |
* | Fix compilation on Mac.Volker Hilsheimer2009-07-171-1/+1
| |
* | Implement QDesktopWidget::screenCount as a property, and add Q_PROPERTYVolker Hilsheimer2009-07-171-0/+4
| | | | | | | | for other attributes as well.
* | Merge branch 'screencountchanged'Volker Hilsheimer2009-07-176-47/+80
|\ \ | | | | | | | | | | | | Reviewed-by: denis Reviewed-by: Prasanth
| * | Implement QDesktopWidget::screenCountChanged signal on desktop platforms,Volker Hilsheimer2009-07-176-47/+80
| | | | | | | | | | | | | | | | | | | | | and add manual testcase. Provide replacement "screenCount" for numScreens and document numScreens as obsolete to be more consistent with other APIs.
* | | Add priority property to QActionJens Bache-Wiig2009-07-173-1/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | | Add reading of kde colors Link and LinkVisited colors from qt apps in ↵Jeremy Whiting2009-07-171-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | Move QMacStyle icon handling down to the common style.Norwegian Rock Cat2009-07-172-0/+49
|/ / | | | | | | | | | | | | | | | | | | | | | | | | 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
* | Fix MinGW (g++ 3.4.5) compilation.Friedemann Kleint2009-07-171-3/+4
| | | | | | | | | | ...to be reverted once it is deprecated. Reviewed-by: Thierry Bastian <thierry.bastian@nokia.com>
* | Wrapped the XInput include with an ifdef.Denis Dzyubenko2009-07-161-0/+4
| | | | | | | | | | | | | | That should fix compilation on platforms that do not have xinput headers installed. Reviewed-by: Thiago Macieira
* | fix warnings with mingwThierry Bastian2009-07-152-1/+3
| |
* | Fix warnings for mingwThierry Bastian2009-07-153-24/+28
| | | | | | | | | | did a small refactor and used QStyleHelper::uniqueName in plastique and windows styles
* | Compile after a72c30020bdadbe0d82e583e17acd25715604f7bBjørn Erik Nilsen2009-07-151-1/+1
| | | | | | | | | | 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.
* | repair the mouse cursor on Windows CEJoerg Bornemann2009-07-151-0/+4
| | | | | | | | | | | | | | | | 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
* | Bad drawing of styled viewports within QAbstractScrollAreaOlivier Goffart2009-07-154-46/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | Make the window title set by setWindowFilePath() match our docs.Norwegian Rock Cat2009-07-142-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | use qt_mac_QStringToNString & qt_mac_NSStringToQStringNorwegian Rock Cat2009-07-141-4/+2
| | | | | | | | | | | | 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.
* | Build fix for mingwThierry Bastian2009-07-143-11/+10
| | | | | | | | | | we should include qt_windows.h and not windows.h because we have to define WINVER to 0x500.
* | Compile without qt3supportOlivier Goffart2009-07-131-1/+1
| |
* | QToolTip: Uses QPalette::ToolTipText default text color for rich text.Thomas Sondergaard2009-07-131-0/+1
| | | | | | | | | | | | Task-number: 248429 Merge-request: 786 Reviewed-by: Olivier Goffart <ogoffart@trolltech.com>
* | Merge commit 'origin/4.5'Bill King2009-07-132-6/+3
|\ \ | |/ | | | | | | | | | | | | Conflicts: src/plugins/kbddrivers/usb/main.cpp tests/auto/qnetworkreply/tst_qnetworkreply.cpp tests/auto/qwidget/tst_qwidget.cpp
| * Fixed a crash with input methodsPierre Rossi2009-07-102-6/+3
| | | | | | | | | | | | | | | | | | The inputContext's focusWidget was not reset when disabling input methods. Thanks to Benjamin P. Task-number: 257832 Reviewed-by: Denis
* | Fix compilation on SnowLeopardNorwegian Rock Cat2009-07-102-5/+5
| | | | | | | | | | | | 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.
* | Tablet events get delivered to the widget where the tablet down happend.Luc Devallonne2009-07-101-2/+27
| | | | | | | | | | | | | | | | 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>
* | Support Tablet coordinate on Windows with non-zero physical originLuc Devallonne2009-07-102-13/+17
| | | | | | | | | | | | | | | | | | | | 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>
* | Ensure that when we hide QToolBar in unified, unified follows.Norwegian Rock Cat2009-07-095-18/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | Merge commit 'origin/4.5'Bill King2009-07-087-75/+82
|\ \ | |/ | | | | | | | | | | | | | | | | 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
| * Document limitation in Cocoa cursor handling.Norwegian Rock Cat2009-07-071-0/+5
| | | | | | | | | | | | | | | | | | | | 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.
| * Fix typo in color calculation.Norwegian Rock Cat2009-07-071-3/+3
| | | | | | | | | | | | | | | | | | 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
| * Fix issue where a mainwindow would show two size grips in Cocoa.Norwegian Rock Cat2009-07-061-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| * Implement QApplication::setOverrideCursor to use pure Cocoa callsNorwegian Rock Cat2009-07-061-1/+11
| | | | | | | | | | | | | | | | | | | | | | 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
| * Remove unused function viewUnderTransparentForMouseView in QCocoaView.Prasanth Ullattil2009-07-022-57/+0
| | | | | | | | | | | | | | After we implemented hitTest for QCocoaView, this function is no longer used. Reviewed-by: Norwegian Rock Cat
| * Drag and drop events are not delivered correctly in CocoaPrasanth Ullattil2009-07-022-8/+43
| | | | | | | | | | | | | | | | | | | | | | 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
| * Implement hitTestNorwegian Rock Cat2009-07-022-54/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * Fix a regression where dynamic tooltips wouldn't show up in Cocoa.Norwegian Rock Cat2009-07-022-4/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | Cocoa: Plain text from clipboard use '\r' as newline instead of '\n'Prasanth Ullattil2009-07-083-2/+25
| | | | | | | | | | | | | | | | | | 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
* | The offset of cropRect should not depend on the position of the windowBenjamin Poulain2009-07-081-1/+1
| | | | | | | | | | The rect cropRect should be positioned with the offset to the top-level window, not the screen position.
* | On Mac OS X, translate the wrect to the coordinates on screenBenjamin Poulain2009-07-071-7/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the following configuration, wrect was off-screen and the widget was not painted: -scroll area "A" -contains another scrollarea "B" with 2*WRECT_MAX < size < XCOORD_MAX -the widget contained in B has size > XCOORD_MAX -A is scrolled to the the bottom To fix the issue, wrect is moved to the area where the top level window is in the widget coordinate. Task-number: 144779 Reviewed-by: nrc
* | Fixes a crash when scrolling a scrollarea with a mouse wheel.Denis Dzyubenko2009-07-071-0/+1
| | | | | | | | | | | | | | | | | | This fixes a crashed introduced in 60e965fd35037f4a27816d2aeccafdff0d6ae9d6 - those lines were removed by accident. Reviewed-by: João Abecasis Author: João Abecasis
* | Getting rid of compiler warnings on windowsThierry Bastian2009-07-072-7/+3
| |
* | doc: Included note about the effect of WA_NoMousePropagation.Martin Smith2009-07-061-0/+4
| | | | | | | | Task-number: 162945
* | Fix to paint big widgets in a scroll areaBenjamin Poulain2009-07-061-5/+3
| | | | | | | | | | | | | | | | | | | | | | If a big widget is inside a scroll area, and this widget is in the limits of XCOORD_MAX, its child might not be inside the limits. The child is then limited to wrect, but wrect might not be on the screen because the parent is scrolled. To avoid this problem, the widgets position should not influence whether wrect is used or not. Task-number: 144779 Reviewed-by: nrc
generated by cgit v0.12 at 2024-11-15 15:26:42 (GMT)