summaryrefslogtreecommitdiffstats
path: root/src/gui
Commit message (Collapse)AuthorAgeFilesLines
* Fix QCombobox popup flicker on OSMorten Sørvig2009-08-241-0/+12
| | | | | | | | Don't disable updates when showing the popup. This was introduced by commit 5516c2165, the original bug in task 152840 is not reproducible on OS X. Task-number: Reviewed-by: Richard Moe Gustavsen
* Mac: Fix crash in QCoreTextFontEngineMulti when disabling font kerning.Morten Sørvig2009-07-301-1/+1
| | | | | | CFDictionaryAddValue expects a CFNumberRef, not a pointer-to-CFNumberRef. Reviewed-by: TrustMe
* Unable to change focus between two line edits on macRichard Moe Gustavsen2009-07-301-37/+12
| | | | | | | | | | | | | | | | | | | | 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
* Doc - Renamed the cursor's images to illustrate splitV and splitH properlyKavindra Devi Palaraja2009-07-291-2/+2
| | | | | | Task: 258895 Reviewed-By: Jens Bache-Wiig
* Comment one of my changes from yesterdayRichard Moe Gustavsen2009-07-291-4/+7
| | | | Task-number: 258445
* Regression: QColorDialog crash on Mac when accepting with keyboardRichard Moe Gustavsen2009-07-283-119/+134
| | | | | | | | | | | | | | 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
* Fixed drawImage() so that it doesn't sample outside the source image.Kim Motoyoshi Kalland2009-07-281-4/+4
| | | | | | | | | | | | | | | | 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
* Don't use layered windows for non-translucent windowsGunnar Sletta2009-07-281-2/+2
| | | | Reviewed-by: Samuel
* Roll back the fancy updating of translucent windows.Gunnar Sletta2009-07-271-4/+1
| | | | | | | | | | 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
* Fix crash when printing to PDF on Qt/MacMorten Sørvig2009-07-271-2/+5
| | | | | | | | | | 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 causes problemsRichard Moe Gustavsen2009-07-242-21/+34
| | | | | | | | | | | | | | 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
* Fixed crash when vectorpath was polygonal only in raster::stroke()Gunnar Sletta2009-07-241-9/+16
| | | | | | | Polygonal vector paths may have types==null, in which case this would have crashed. Reviewed-by: Eskil
* QPainter::stroke() on raster engine would draw moveto's as linesGunnar Sletta2009-07-231-5/+17
| | | | | | | | | 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
* Diagonal dashes are moving when touching the clip boundary.Gunnar Sletta2009-07-231-1/+4
| | | | | | | | | 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
* Implement clipping in the QPaintEngineEx::stroke() function.Gunnar Sletta2009-07-233-6/+11
| | | | | | | This is a huge impact on performance whenever this path is taken. Reviewed-By: Tom Cooksey
* Revert "Added a check that X11 timestamp goes forward only."Denis Dzyubenko2009-07-221-20/+15
| | | | | | | | | | | | | | | 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
* Fix table borders in multiline tables when printing to PostScript.Gunnar Sletta2009-07-221-2/+7
| | | | | | | | | | | | | 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
* Fix memory leak.Olivier Goffart2009-07-221-0/+2
| | | | | | | | The signal could be connected a huge number of times This is already fixed in master with Qt:UniqueConnection Task-number: 258381
* Update documentation for QMessageBox::open().Norwegian Rock Cat2009-07-221-2/+4
| | | | | | I had missed this one in my rounds of updates. Bad me. Reviewed-by: Thorbjorn
* Fix a potential crash due to the fact that _q_UpdateIndex() is reenteredAndy Shaw2009-07-221-1/+1
| | | | | | | | | 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
* Another fix needed to build in a namespace on Mac with -arch ppcAndy Shaw2009-07-211-1/+2
| | | | | | | | Don't know how this got lost in the original submit since I had added both. Task-number: 257080 Reviewed-by: nrc
* Fix the hand scrolling in QGraphicsView that will stop unexpectedly.Alexis Menard2009-07-201-1/+1
| | | | | | | | | | 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
* 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-172-3/+8
| | | | | | | | | | | | | | | | | | | 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
* Fix accidental selection of popup items under the mouse in QComboBoxmae2009-07-171-0/+2
| | | | | | | | | | 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
* Enhanced QDirModel documentationMarkus Goetz2009-07-171-1/+4
| | | | Reviewed-by: Volker Hilsheimer
* Better caching of file system icon providers.Norwegian Rock Cat2009-07-161-1/+36
| | | | | | | | | | | | 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
* QFileDialog static functions doesn't honor the DontUseNativeDialog flag.Alexis Menard2009-07-151-3/+3
| | | | | | | Just add a check before calling hooks. Task-number:258084 Reviewed-by:jbache
* Revert "QFileDialog: When passing an invalid path in static functions the ↵Alexis Menard2009-07-141-18/+3
| | | | | | native" This reverts commit a4c4f994fa51ff216f0d43098824617e14b8a284.
* Fixed a potential memory leak on XPJens Bache-Wiig2009-07-131-2/+4
| | | | | | | | | Calling OpenThemeData directly causes a leak when changing the style as we do not call the corresponding CloseThemeData. Task-number:257916 Reviewed-by:prasanth
* 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
* Update QGroupBox on focusBenjamin Poulain2009-07-081-5/+1
| | | | | | | | We cannot assume the position of the decorations when a QGroupBox get the focus. Task-number: 257660 Reviewed-by: Thierry
* 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
* Doc: clearifying docs - QProgressDialogMorten Engvoldsen2009-07-011-1/+1
| | | | | | Clearifying details on a warning about a function call (setValue()) Task-number: qtp 4.5Workarea
* Doc: correcting typoMorten Engvoldsen2009-07-012-2/+2
| | | | | | Correcting typos Task-number: 257225
* Document unified toolbar change with regard to full screen change.Norwegian Rock Cat2009-07-011-3/+4
|
* Fix Toolbars in unified toolbar looking bad Carbon w/Fullscreen changesNorwegian Rock Cat2009-06-301-2/+17
| | | | | | | | | | | | | | | There was a bug in the Carbon code when an item went in full-screen, than out with a unified toolbar. In those cases the toolbars would end up getting but into the mainwindow area. The reason this was happening was that we were calling transferChildren() after we had set up our toolbar. This cause problems because we end up pulling the QToolbars right out of the unified toolbar. The easiest way to solve this is to just update the status on it again. This should solve any issues. I also added some logic to avoid calling this too many times in that one case. Luckily, this seems to only affect Carbon. Task-number: 254462 Reviewed-by: Jens Bache-Wiig
* Doc: Fixed a doc bug in QPlainTextEdit class description.Geir Vattekar2009-06-301-7/+7
| | | | | Task-number: 256762 Reviewed-by: TrustMe
* Doc: About menu on the Mac gets the application name from Info.plist.Geir Vattekar2009-06-302-3/+6
| | | | | Task-number: 256818 Reviewed-by: Trenton Schulz
* QWidget::adjustSize() sends a spontaneous event - Mac OS X CocoaPrasanth Ullattil2009-06-302-2/+12
| | | | | | | | The windowDidResize notification now differentiates an internally triggered resize from a user triggered resize. Task-number: 256269 Reviewed-by: Norwegian Rock Cat
* Remove unused variablesAnders Bakken2009-06-291-2/+0
| | | | | | These variables are never used. Reviewed-by: TrustMe
* Always turn on shadows for Cocoa.Norwegian Rock Cat2009-06-291-2/+1
| | | | | | | | | | | | Frameless windows wouldn't get shadows in Cocoa, which they do in Carbon. You can argue over who is more correct, but the fact is they can't be inconsistent. Since Cocoa is the newcomer, I'm bending that. Though it would seem useful to have an ability to provide some developer control over the shadow. At the moment, the only thing we have to ensure is that we always turn on the shadow. Task-number: 254725 Reviewed-by: Denis
* Fix crash/artifacts on SuperHTom Cooksey2009-06-291-3/+3
| | | | | | | | | | | Add SuperH to the ever growing list of architectures which can't correctly dereference a short* which is not 16-bit aligned. Turning this into a white-list rather than a black list might make sense at some point, but as QT_ARCH_I386 isn't defined on windows, the white list looks even uglier at the moment. :-) Task-number: 257077 Reviewed-by: TrustMe
generated by cgit v0.12 at 2024-11-25 02:07:08 (GMT)