| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
|
|
| |
This is a backport of commit 8ac7e81260
Reviewed-by: Peter Hartmann
|
|
|
|
|
|
|
|
| |
With line wrapping enabled and very large text blocks, painting errors
could occur.
Reviewed-by: hjk
(cherry picked from commit 82dba1d346a6f4a5d2602d930e0aed75c13bcafb)
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| | |
The magic number 22 was based on windows sized icons, a size of 16
should be correct for mac
Task-number: 259289
Reviewed-by: NRC
|
| |
| |
| |
| |
| |
| | |
This reverts commit 6844dea0cb583a86bc72e7f008720ab76deef040.
added to wrong branch. should be in 4.6 but this was added to 4.5
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
calendar popup
A frame was always drawn around the QDateTimeEdit editor if a popup
calendar had been set. QStyleOptionsComboBox options are being set in
paintEvent and initialised from the properties of QStyleOptionsSpinBox but
were missing the frame bool property. Now, if the user sets a frame on the
QDateTimeEdit, this property will be consistent with setFrame() property
of the QDateTimeEdit widget.
|
| |
| |
| |
| | |
Reviewed-by: Trust Me
|
| |
| |
| |
| | |
Reviewed-by: Trust Me
|
|/
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
The signal could be connected a huge number of times
This is already fixed in master with Qt:UniqueConnection
Task-number: 258381
|
|
|
|
|
|
|
|
| |
We cannot assume the position of the decorations when a QGroupBox get
the focus.
Task-number: 257660
Reviewed-by: Thierry
|
| |
|
|
|
|
|
| |
Task-number: 256762
Reviewed-by: TrustMe
|
|
|
|
|
| |
Task-number: 256818
Reviewed-by: Trenton Schulz
|
|
|
|
|
|
| |
These variables are never used.
Reviewed-by: TrustMe
|
|
|
|
|
|
|
|
|
|
| |
After discussing with some of the Objective-C
people I have finally got a fair number of the
warnings to disappear in both 10.5 and 10.6. I
also took the opportunity to remove a bunch of
other warnings.
Reviewed by: Morten Sørvig
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
|
|
|
|
| |
No progress bars on the mac show text and it would be bad if we allowed
it. There's nothing stopping people from connecting the valueChanged()
signal to a slot and have a real label layed out correctly that actually
updates with the amount of time it takes to complete, etc. This is more
what they do on Mac OS X if they decide to show a label.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was quite a bug and it showed to some issues that I hadn't taken
into account when doing the initial port to Cocoa. The issue was that we
weren't "merging" items into the application menu if an item had already
been associated with it. Which seems OK for applications that create one
window with one menubar, but breaks down horrible when you have multiple
windows with each having their own menubar. The result is that items in
the application menu potentially go to the wrong window (and the
potential crash). Since there can only ever be one "Quit", "About", or
"Preferences" menu item in Cocoa, we need to make sure that we keep
these items in sync whenever we switch the menubar or remove actions
that are being deleted. That's what we do here.
FWIW, QActions with "ApplicationSpecificRole" for their menu role have
potential to cause memory leaks or other bugs if abused. If you are a
happy open source hacker who wants a thankless job, solving them would
get you lots of goodwill in my book.
Task-number: 255038
Reviewed-by: Richard Moe Gustavsen
|
|
|
|
|
|
|
|
|
|
| |
On XP and Vista where tabs use taboverlap, the currently
dragged would loose the outline. We need to compensate for the
taboverlap when creating the draggable widget, otherwise the
outline will be clipped.
Task-number: 254453
Reviewed-by: nrc
|
|
|
|
|
|
|
|
|
| |
Regression from 4.4 introduced while fixing task 167106
Autotest: tst_QComboBox::task253944_itemDelegateIsReset()
Task-number: 253944
Reviewed-by: jbache
|
|
|
|
|
| |
Signed-off-by: Andre Haupt <andre@bitwigglers.org>
Reviewed-By: Thiago Macieira
|
|
|
|
|
|
| |
Usually, "the the" is not proper English
Reviewed-By: Thiago Macieira
|
|
|
|
|
|
|
|
|
| |
According to the documentation, QCalendarWidget::setDateTextFormat() should
reset the format if the date is not valid.
New tests included for the formating of this widget.
Task-number: 252943
Reviewed-by: Olivier
|
|\ |
|
| |
| |
| |
| |
| |
| |
| | |
The WinCE build was failing due to a spelling error in an #ifdef
directive.
Reviewed-by: Trust Me
|
| |
| |
| |
| | |
Reviewed-by: thartman
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We must tell the system that we want to intercept the back key on
Windows mobile. Each toplevel widget that needs correct back key
behaviour needs to have a menu bar. Why? Ask Microsoft...
Task-number: 248846
Reviewed-by: thartman
|
|/
|
|
|
|
|
| |
to include info on Cocoa.
Task-number: 252658
Reviewed-by: Trenton Schulz
|
|
|
|
|
|
|
|
| |
This fix ensures that the current tab is visible after calling
setTabButton() on a scrolled tab bar.
Reviewed-by: bnilsen
Task-number: 252472
|
|
|
|
|
|
|
| |
This is still not a perfect solution since it breaks 245347 again
Task-number: 252319
Reviewed-by: Maurice
|
|
|
|
|
|
|
| |
Due to a wrong lookup (confusing line and block number) the scroll
optimization was broken, causing the entire view to be updated.
Reviewed-by: Thorbjørn Lindeijer
|
|
|
|
|
|
|
|
|
| |
The problem is in QTabBar which emits the currentChanged signal
before accessing its own internal data. As we react to that signal by
possibly removing/adding tabs, it can cause a assertion failure.
Task-number: 251184
Reviewed-by: ogoffart
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes a few of the remaining glitches tabbar animations have:
* We no longer grab tabs but paint them through QStyle. This makes tabs
work and animate correctly when they are outside the visible region.
* Buttons now correctly follow tabs when dropped
* Gtkstyle recieved some polish to make it look more native.
Task-number: 247694, 251166
Reviewed-by: nrc
|
|
|
|
| |
It worked in 4.5.0, so it should work in 4.5.1 too.
|
|
|
|
|
|
|
|
| |
The submenu would always appear to the side of the menu instead of its
right.
Task-number: 250673
Reviewed-by: ogoffart
|
|
|
|
|
|
|
| |
Reviewed-by: Thomas Hartmann
need to check for valid menuBar, otherwise dereferencing will
horribly fail.
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
desktop environment.
Task-number: 250338
Reviewed-by: Jens Bache-Wiig <jbache@trolltech.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
This makes sure that style sheets set both ButtonText and WindowText roles
for all widgets. This fixes among other things the fact that you could not
configure text colors for combo box popups on Mac, Gtk and CleanLooks or
set the background for the whole scrollbar.
Task-number: 160713
Reviewed-by: ogoffart
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit 20864878d046b2ce6bf5fc54868be8df346ce0c8
Author: David Boddie <dboddie@trolltech.com>
Date: Thu Mar 26 18:30:32 2009 +0100
Doc: Fixed qdoc warning by adding more descriptive text.
Reviewed-by: TrustMe
commit 3b620a0a4d1b02105c9761384a5abc4ecf11e9d2
Author: David Boddie <dboddie@trolltech.com>
Date: Thu Mar 26 18:29:56 2009 +0100
Doc: Added macros for future use.
Reviewed-by: TrustMe
|
|
|
|
|
|
|
|
|
| |
QDockWidget's minimum title width was not computed correctly and was
thus provoking some strange layout issues. We need to ask for the
widget's sizeHint for the close and float buttons.
Task-number: 241577
Reviewed-by: ogoffart
|