summaryrefslogtreecommitdiffstats
path: root/src/gui/kernel
Commit message (Collapse)AuthorAgeFilesLines
* Some code cleanups after review.Jason Barron2009-04-291-3/+3
| | | | | Change these lines of code to either make it more consistent or more readable after review.
* Undo implementation of setWindowOpacity_sys().Jason Barron2009-04-291-4/+2
| | | | | | | | This function was implemented using API from Symbian that will be deprecated. It was never actually suitable anyway since this function cannot be called after the window has been shown and this needs to be a runtime decision for Qt. The solution is to use SetTransparencyAlphaChannel(), but that will come later.
* Fixes crash when setting geometry on an obscured window.Jason Barron2009-04-291-1/+1
| | | | | | | Since Qt on Symbian now destroys the backing store when it gets hidden or obscured we need to be careful not to use functions like moveRect() when we don't have a backing store since this function is really a backing store optimization and therefore assumes one exists.
* More work on translucent windows.Jason Barron2009-04-282-3/+6
| | | | | | | | | | | | One step closer to semi-transparent windows, but not there yet. This gets the transparent contents into the window, but the previous contents are not cleared so it keeps drawing the backing store on top of itself each time a Draw() is done. SetBackgroundColor() indicates to WSERV that our window is semi-transparent. We also make sure not to use 'EDrawModeWriteAlpha' when the widget is non-opaque since this actually changes the alpha channel on the frame buffer (not the window) so the gives undesired results. It's a faster draw mode though so we should use it where we can.
* Fixes: Add support for translucent windows in Symbian.Jason Barron2009-04-285-2/+47
| | | | | | | | | | | Warning, this is completely untested! Details: This should (in theory) get translucent windows working but this hasn't been tested yet. The emulator environment seems to return only 16ColorMU display modes which implies the window is opague so Qt ignores the translucent flag. HW seems to create 16ColorMA windows, but it hasn't been tested there yet either (no time).
* We previously had some hacks in this function to avoid creating aJason Barron2009-04-281-2/+4
| | | | | | backing store with the ARGB32 format (which is slower to draw on), but we actually want this in some cases so let's do this properly and move the hacks somewhere else.
* Fix background painting.Jason Barron2009-04-281-7/+5
| | | | | | | This is a reverted patch that has been rebased on to another branch and then caused conflicts so it might contain an error or two. Basically we need to store the background texture from the style into the palette so that it can be replaced by applications that don't want it.
* Enable dynamic [de|con]struction of window surfaces based on visibilityJason Barron2009-04-282-13/+29
| | | | | | | | | When a window becomes completely obscured either because it has been hidden or another window is completely covering it, the backing store should be deallocated to save memory and then re-allocated when the window is later made visible again. Reviewed-by: Iain <qt-info@nokia.com>
* Merge branch '4.5' of git@scm.dev.nokia.troll.no:qt/qtaxis2009-04-2723-1200/+1538
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Configure.exe recompiled with MSVC6. Conflicts: configure.exe examples/network/network.pro src/gui/dialogs/qfiledialog_p.h src/gui/dialogs/qfilesystemmodel_p.h src/gui/kernel/qapplication.cpp tests/auto/_Categories/qmake.txt tests/auto/qfile/test/test.pro tests/auto/qfile/tst_qfile.cpp tests/auto/qlibrary/tst_qlibrary.cpp tests/auto/qline/tst_qline.cpp tests/auto/qstyle/tst_qstyle.cpp tests/auto/qtextstream/tst_qtextstream.cpp tests/auto/qtranslator/qtranslator.pro tests/auto/qwaitcondition/tst_qwaitcondition.cpp translations/qt_ja_JP.ts
| * Drag and drop examples not working correctly in CocoaPrasanth Ullattil2009-04-243-27/+62
| | | | | | | | | | | | | | | | | | | | | | In the updated examples, the drag operation is changed in the drop-event handler, which was not handled correctly in the Cocoa. This is now supported for drag and drop from same application. If the drop was to another application, the drag will return the result from the last drag-move event. Task-number: 252103 Reviewed-by: nrc
| * Revert "Removed dead code."jasplin2009-04-231-0/+2
| | | | | | | | | | This reverts commit 99d243860548d6be8a68dfd027c51530351d12cb. Needed because of commit b51dd5a7b328291c5dbda540ce228e7d867662cb.
| * Revert "Fixed key sequence eating behavior for QShortcut and QAction."jasplin2009-04-234-50/+27
| | | | | | | | | | | | | | | | | | | | | | This reverts commit 031adeaf42ddaef8d01338f6c59ba97170be5d53. The patch had some unforeseen side-effects for Creator. It may also affect other existing applications in a similar way. For now, this behavior (eating key sequences for disabled shortcuts) should be achieved using a local workaround in creator. Reviewed-by: mariusSO Task-number: 251246
| * Disable MIT-SHM usage on BGR server layouts under X11.Trond Kjernåsen2009-04-231-6/+12
| | | | | | | | | | | | | | | | Since the raster engine always assumes RGB layout in a QImage, we can't support this out of the box. Task-number: 248720 Reviewed-by: Samuel
| * Carbon/Cocoa: It is possible to resize a widget above its maximum sizeRichard Moe Gustavsen2009-04-232-39/+50
| | | | | | | | | | | | | | | | | | | | This is not strange since we never did anything to limit a resize within the max min boundries. This patch factores out the code that ensures this into a private function that is called both as a reaction to a resize event, but also if resize is done programatically. Task-number: 251893 Reviewed-by: Trenton Schulz
| * Removed dead code.jasplin2009-04-231-2/+0
| | | | | | | | Reviewed-by: TrustMe
| * Don't emit QApplication::focusChanged for no reasonThorbjørn Lindeijer2009-04-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Qt::NoFocusReason is used when Qt temporarily moves the focus to the QMenuBar while switching from one widget to another. While this did not result in a QFocusEvent, it did result in emitting the QApplication::focusChanged signal. This in turn caused a slowness in Qt Creator, since it wanted to update the current context and find filter. The fix here makes sure the focusChanged signal is not emitted when the focus reason is Qt::NoFocusReason, since these focus changes are not interesting for the application. Reviewed-by: mae
| * Doc fixesJoão Abecasis2009-04-221-2/+3
| | | | | | | | Reviewed-by: Thiago
| * BT: Make things work on 10.3Norwegian Rock Cat2009-04-211-1/+1
| | | | | | | | | | | | The #ifdef was typed wrong. Reviewed-by: Prasanth Ullattil
| * Fixed key sequence eating behavior for QShortcut and QAction.jasplin2009-04-204-27/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A disabled QShortcut should eat its key sequence even for complex sequences like "Ctrl-E 1". For example, a line edit with such a shortcut should not display 1 after typing "Ctrl-E" and then "1". The patch achieves this essentially by moving more of the decision making (of whether to eat the key secuence) from shortcutmap.cpp to qhortcut.cpp. Moreover, an invisible QAction should not eat any of its key sequences (primary nor alternates). In the example above, the line edit would display 1 when typing this sequence for an invisible action. The patch achieves this by temporarily unregistering all of the action's shortcuts while the action is invisible. Reviewed-by: mariusSO Task-number: 251246
| * Fixed incorrect documentation.axis2009-04-201-3/+4
| |
| * BT: Fix a crash when using Q(File)Dialog::open() in QCocoa.Norwegian Rock Cat2009-04-201-1/+4
| | | | | | | | | | | | | | | | If we don't have a sheet, we need to recreate it in Cocoa. Unfortunately, we neglected to reassign the NSWindow pointer in that case, so the program would crash. Reviewed-by: Richard Moe Gustavsen
| * Line edit displays garbage when pressing up or down arrow keys (Cocoa).Prasanth Ullattil2009-04-171-1/+4
| | | | | | | | | | | | | | | | | | The unicode characters between 0xF700 & 0xF8FF are special function-key code characters used by the NSEvent. These characters have to be ignored when converting to a QString. Task-number:244486 Reviewed-by:nrc
| * BT:Stop widgets disappearing in unified when clicking the toolbar buttonNorwegian Rock Cat2009-04-161-1/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The comment in the code pretty much says it all, so I'll repeat it: This is a workaround for NSToolbar. When a widget is hidden by clicking the toolbar button, Cocoa reparents the widgets to another window (but Qt doesn't know about it). When we start showing them, it reparents back, but at this point it's window is nil, but the window it's being brought into (the Qt one) is for sure created. This stops the hierarchy moving under our feet. Task-number: 251294 Reviewed-by: Prasanth Ullattil
| * Remove some warningsNorwegian Rock Cat2009-04-161-2/+2
| | | | | | | | These aren't used in Carbon, so don't reference them.
| * Fix a bug that made it hard to click the top items in a list widgetNorwegian Rock Cat2009-04-161-2/+2
| | | | | | | | | | | | | | | | | | | | Our "view under tranparent view" function was sound, but it didn't take into consideration that fact that views in the hierarchy could be hidden. This is most prominent when you have a QFocusFrame over a QAbstractScrollArea. Task-number: 251008 Reviewed-by: Morten Sørvig
| * Fixed titlebar on X11 for fixed size windows with Qt::CustomizeWindowHintDenis Dzyubenko2009-04-161-1/+3
| | | | | | | | | | Task-number: 250326 Reviewed-by: Brad
| * QX11Embed crashes on 64-bit SolarisBradley T. Hughes2009-04-161-4/+3
| | | | | | | | | | | | | | | | The data passed to XChangeProperty should be long arrays, as this is what Xlib expects. Task-number: 244062 Reviewed-by: Rhys Weatherley
| * BT: Namespace compile fixes for Cocoa.Norwegian Rock Cat2009-04-152-6/+9
| | | | | | | | It worked in 4.5.0, so it should work in 4.5.1 too.
| * BT: Fix Cocoa bug w/OpenGL widgets in dock widgets would disappear.Norwegian Rock Cat2009-04-151-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | The NSOpenGLContext seems to be tied to the window. So if the view changes from one window to another, the OpenGL context needs to be cleared. We can do this by hooking into the viewWillChangeWindow and viewDidChangeWindow events and clear and reset the drawable respectively. We also found out that QCocoaOpenGLView was not being used at all, so just remove it to get rid of any confusion. Task-number: 250066 Reviewed-by: Trond
| * Fix warning: "__LP64__" is not defined"Thiago Macieira2009-04-141-1/+1
| | | | | | | | Reviewed-by: Norwegian Rock Cat
| * Fix a bug where a widget would not always get the correct Cursor in CocoaNorwegian Rock Cat2009-04-144-0/+61
| | | | | | | | | | | | | | | | | | | | 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.
| * Cocoa: dialogs are sometimes not shown if triggered from outside the appRichard Moe Gustavsen2009-04-141-0/+3
| | | | | | | | | | | | | | | | | | | | 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
| * BT: Fix up comments in new Cocoa files.Norwegian Rock Cat2009-04-085-55/+55
| | | | | | | | | | | | 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.
| * BT: Prevent a crash in Designer when quiting when in the filter edit.Norwegian Rock Cat2009-04-072-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
| * Drag cursor is not updated when modifier keys are pressed/released inPrasanth Ullattil2009-04-072-2/+6
| | | | | | | | | | | | | | | | | | 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
| * BT: Fix regression when tooltips dissappear suddenly in Unified toolbarNorwegian Rock Cat2009-04-073-2/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| * Fixes: Calling repaint() during a top-level resizeGunnar Sletta2009-04-071-10/+14
| | | | | | | | | | | | | | | | | | 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().
| * BT: Fix combobox background color regressionJens Bache-Wiig2009-04-061-2/+4
| | | | | | | | | | | | | | | | | | There was a regression in the background color for QComboBox popups. This should resolve it. It essentially tells the system to stay off the system palette while QGtkStyle is used. We will introduce a cleaner style hint for this in 4.6. Reviewed-by: nrc
| * BT: Fix a crash when running a widget window modal when it has no parentNorwegian Rock Cat2009-04-061-7/+5
| | | | | | | | | | | | | | | | We changed the logic for determining sheets, but it seems we forgot to take the parentWidget() into account. It's required for WindowModality to make any sense. Reviewed-by: Richard Moe Gustavsen
| * Fix up color matching on 64-bit Cocoa.Norwegian Rock Cat2009-04-061-7/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It seems that GetThemeTextColor is not available at all for 64-bit versions of the operating system and there is no good equivalent. We were using a technique where we would create a small pixmap and then use HIThemeSetTextFillColor() with the proper enum. However, this function will silently set a black color if it doesn't know about the enum. So, we get black when we really shouldn't. It also seems to produce colors that are a bit different from the Carbon function. So, in the meantime, just hard code the values in. It might break if you are hacking the resources in Mac OS X, but we'll have to live with that until we get a real function. Task-number: 248918 Reviewed-by: Prasanth Ullattil
| * QGtkStyle: Fix styling and palette issues related to combo boxJens Bache-Wiig2009-04-031-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Well actually this change is a bit bigger than just that. *We no longer override the palette you provide in polish so it should be a bit more frienly toward custom application changes. * Another issue was that we would generate the palette information when we got the style callback from gtkButton but then the line edits might not yet have been polished. Hence we now return from the callback and instead post the update for later. * We had to modify the PE_Frame entry to draw a raised menu when the custom combo box delegate was used. * We now simply ignore custom qtconfig palette entries when using GtkStyle since they only cause trouble with it. Task-number: 250142 Reviewed-by: nrc
| * Do not loose WindowType flags when setting translucent background in X11Olivier Goffart2009-04-031-1/+1
| | | | | | | | | | | | | | | | This fixes KRunner on XMonad. The Qt::Dialog flag of the krunner dialog was lost when the Qt::WA_TranslucentBackground was set, leading to incorrect behaviour in some window manager (such as xmonad) Reviewed-by: Samuel
| * Only set system style when it actually changesJens Bache-Wiig2009-04-021-1/+5
| | | | | | | | | | | | | | | | | | | | | | This issue would cause Qt Creator and similar apps with proxy styles to loose their custom styling whenever any x11 system settings changed. This happened because we would re-read the settings and override the system style even if the system style did not actually change would be set on the application. We Task-number: 250199 Reviewed-by: ogoffart
| * Marked QWidget::resetInputContext() function as obsolete.Denis Dzyubenko2009-04-011-4/+8
| | | | | | | | | | | | | | | | | | Fixed the behavior of the function that was broken by me some time ago. But anyway this function is for convenience only since QInputContext that operates on the widget is available to the user directly. Reviewed-by: Prasanth Ullattil
| * Removed obsolete internal function that focuses input context.Denis Dzyubenko2009-04-013-25/+0
| | | | | | | | Reviewed-by: TrustMe
| * QComboBox with Qt::NoFocus triggers a crash.Prasanth Ullattil2009-04-011-3/+7
| | | | | | | | | | | | | | | | | | The showPopup() from a combobox triggers a crash. This happens only for a combobox which dosen't accept focus and it has been recreated. This is due to some invalid widget pointer stored in the input context. Task-number: 249576 Reviewed-by: ddenis
| * Don't send QFileOpenEvents for items on the command-lineNorwegian Rock Cat2009-03-302-4/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Cocoa actually has a nice feature that if you pass arguments on the command-line, Cocoa will pass those along as Open events later. This is probably how we should have handled things inside of Qt as it would have unified the file opening code. Unfortunately, we can't turn back time on this, so we need to prevent it because people probably aren't expecting it (i.e., they expect to do the parsing themselves, and not to get events later). This also means that we can send the event immediately instead of posting it, because the race that we had before no longer exists. We only do this check during launch time because that's the only time we may get bitten by it (people usually only parse the arguments once). Someday, people may actually WANT this functionality though. When that comes along, we should make it an application attribute. Task-number: 249553 Reviewed-by: Richard Moe Gustavsen
| * QDesktopWidget::resized wasn't emitted properly on X11.Denis Dzyubenko2009-03-271-6/+15
| | | | | | | | | | | | | | | | | | | | When the size of one of the screen changes but the geometry of the whole desktop hasn't been changed the resized() signal wasn't emitted. The patch by Lubos Lunak also adds emitting of a signal whenever the screen is turned on or off. Task-number: 226048 Reviewed-by: Brad
| * Creating a native window handle doesn't reset input context on X11.Denis Dzyubenko2009-03-271-1/+10
| | | | | | | | | | | | | | | | When the current focus widget enforces the creation of the native window handle we should reset the input context. Task-number: 249578 Reviewed-by: Brad
| * Creating an instance of the QDesktopWidget breaks clipboard on X11.Denis Dzyubenko2009-03-271-2/+9
| | | | | | | | | | | | | | | | | | | | | | On X11 when user manually creates a QDesktopWidget object it breaks notifications from the root window since we have several QDesktopWidgets that have the same native window id and the wid->qwidget mapper (QWidgetPrivate::mapper) goes crazy. So whenever we get x11 event from the root window we cannot find a qwidget that corresponds to the window id and discard these events. Reviewed-by: Brad
generated by cgit v0.12 at 2024-10-21 09:47:21 (GMT)