| Commit message (Collapse) | Author | Age | Files | Lines |
|\ |
|
| |
| |
| |
| | |
Reviewed-by: denis
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
| |
If you passed in a QFont with a family name that did not resolve to
QFontDialog::getFont(), it would not select any font in the panel,
and it would always return the default font, regardless of what you
actually selected in the dialog. This was because it would try to
resolve the requested family name, rather than the actual family name
of the initial font. That in turn caused the NSFont* returned by the
system to be null, which, when set on the font manager, caused the
manager to always return 0 for selectedFont.
Task-number: QTBUG-6071
Reviewed-by: Trond
|
|
|
|
|
|
| |
The line removed in the patch is done so as a result of
change 639b9c0286f0f2d5e50121df8d4125f029074510. That change
made the interrupt do an extra round in the event dispatcher.
|
|
|
|
| |
Over src/ tools/ examples/ and demos/
|
|
|
|
| |
Reviewed-by: prasanth
|
|\ |
|
| |\ |
|
| |\ \
| | | |
| | | |
| | | |
| | | | |
Conflicts:
src/gui/painting/qblendfunctions.cpp
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Basically, QFileDialog on Desktop performs heavy event handling tweaks
on the lineedit and listview to make them ultra keyboard friendly.
We added many "anti"-hacks for Keypadnavigation to restore the native
behavior of the widgets. The result is pure unmaintainability.
(I admit that most of these "anti"-hacks were my fault, since I
participated in some and reviewed all of them)
This commit has results in the same native behavior for Keypad
navigation but without having the #ifdefs inside the event handling
switches.
Only one of these switch-#ifdefs was there before and still is.
embeddedlinux and wince should still be fine and without unintended
behavioural changes compared to Qt 4.5, since the
Qt::NavigationModeKeypadTabOrder case stays unchanged.
Reviewed-by: axis
Reviewed-by: Sami Merila
modified: src/gui/dialogs/qfiledialog.cpp
|
|\ \ \ \
| | |_|/
| |/| |
| | | |
| | | | |
Conflicts:
dist/changes-4.6.0
|
| | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | | |
QPrintPreviewWidget wasn't following the Qt API naming convention of
*Count()/set*Count(). Introduce proper function, and obsolete the old.
Removed all usage of the old function in Qt.
Reviewed-by: Andreas Aardal Hanssen
|
| |\ \
| | |/ |
|
| |\ \ |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The reason was that we did not handle the color space of the selected
color correctly. When selection from the system palette, the color
points to an index rather than e.g. RGB directly. This patch closes
the gap.
Another, a bit more evil, crash comes when trying to click on
'SelectedMenuItemColor' from the 'Developer' palette. The exact
same behaviour occurs when testing a native cocoa app in xcode
directly. So, to handle this as gracefully as possible, we sourround
the 'run modal' call with try-catch, and makes sure that we don't
quit the dialog until the user actually tells it to.
Bugreport to Apple created (bugreport.apple.com): 7364080
Task-number: QTBUG-4578
Reviewed-by: Prasanth
|
| |_|/
|/| |
| | |
| | |
| | | |
Task-number: QTBUG-5547
Reviewed-by: Kim
|
|\ \ \
| |_|/
|/| |
| | |
| | |
| | | |
Conflicts:
tests/auto/qsqlquery/tst_qsqlquery.cpp
tests/auto/qtextlayout/tst_qtextlayout.cpp
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Running an open file dialog, for example with QFileDialog::getOpenFileName() can lead to a freeze if the user selects a folder, then selects a file in the parent folder and finally confirms the open dialog.
Merge-request: 1327
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@nokia.com>
|
| | |
| | |
| | |
| | | |
Reviewed-by: Trust Me
|
|\ \ \
| | |/
| |/|
| | |
| | |
| | | |
Conflicts:
dist/changes-4.6.0
src/gui/kernel/qevent.h
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
For some reason, Cocoa tells us twize whenever a selection
change occurs in the native file dialog. This patch inserts
a check that the selection actually changed before emitting
any signals
Rev-By: Prasanth
|
|\ \ \ |
|
| |\ \ \
| | |/ / |
|
| | | |
| | | |
| | | |
| | | | |
Reviewed-by: tom
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Reviewed-by: tom
Squash me with Fix THREAD and TOOLBAR a6e785b4ff9ec9cd48
|
|\ \ \ \
| | |/ /
| |/| | |
|
| |/ /
| | |
| | |
| | | |
Reviewed-by: Trond
|
|/ /
| |
| |
| |
| |
| |
| |
| | |
Made it possible to navigate out of QFileDialog details view using
keypad navigation.
Task-number: QTBUG-4793
Reviewed-by: Alessandro Portale
|
| |
| |
| |
| | |
Reviewed-by: Denis Dzyubenko
|
| |
| |
| |
| | |
Amending the previous merge request
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
shouldShowFileName() can be called with an empty filename, but must not
create and use a QFileInfo("") since that has known undefined behavior.
So just return NO right away for empty filenames.
Merge-request: 1765
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@nokia.com>
|
| |
| |
| |
| |
| |
| |
| | |
This will result in a warning if the path entered doesn't exist,
which is the behavior of native applications.
Reviewed-by: Prasanth
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Softkeys have a QAction that is related to some action widget.
The initial state of the action was set according the state of action
widget (enabled/disabled). Now, if action widget's state changes,
the softkey's action remain in the initial state.
This was fixed by removing the enable/disable from the QAction and
instead use the real state of action widget when handling the
command of softkey.
Task-number: QTBUG-4619
Reviewed-by: Janne Anttila
|
| |
| |
| |
| | |
ifdef out QCocoaPrintPanelDelegate.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The native filedialog will not exit if it is told to
hide. To remedy this, we just add an extra interrupt call
so to inform the event dispatcher that it needs to return
the the event loop to check if it has been told to quit
Rev-By: olivier
|
| |
| |
| |
| | |
Rev-By: olivier
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When we select save as PDF in the print dialog, we get a new
PMPrintSession in the printInfo object, while our stored
one is deleted, so we update the pointer to be on the safe
side
Reviewed-by: msorvig
|
| |
| |
| |
| |
| |
| | |
Added the missing defines
Reviewed-by: Denis
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This code was kind of dead anyway because
- On X11 and Windows, most of the widgets have the StrongFocus FocusPolicy
- On Mac, e->modifiers always contains KeypadModifier for arrows, so the
code is never reached on mac with real applications
Morever, QAbstractButton already have a more complex handling of arrow keys.
And the code breaks the QButtonGroup arrowKeyNavigation test on Mac (as when
the test system simulates events, the KeyPadModifier is not set)
Reviewed-by: mbm
Reviewed-by: Paul
|
| |
| |
| |
| |
| |
| |
| |
| | |
The error was: "*** No rule to make target `\Qt\tests\auto\kernel\
qguiplatformplugin_p.h_, needed by ..." This happens since Symbian does
not use same include semantics.
Reviewed-by: Miikka Heikkinen
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is an internal interface for plugins that can be provided by
the platform to give platform-specific features by platforms built on
top of Qt.
We can easlily integrate Qt on Windows, Mac, Gnome, ... without any
plugin because we can link to their respective library (dynamically
if we don't want to depend on it). On Gnome, we can dynamically
resolve Gtk+ symbols.
This is however not possible for KDE or other platform built on top
of Qt: we can't link against their library because they depend on us
and we can't dynamically resolve the symbols because they are
mangled (C++)
So this plugin provides hooks inside Qt to be able to do things
like native File or Color dialog, native icons, accurate reading of
the config file, and so on.
This is currently private API.
Task-number: QT-406
Reviewed-by: Jens Bache-Wiig
Reviewed-by: Oswald Buddenhagen
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The font size was not respected because it is taken from the
request which could only contains the pixel size.
Reviewed-by: Richard
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
All key events were being explicitly ignored by the file dialog when key
navigation is enabled, and it doesn't have edit focus.
When a file is opened by pressing the OK key, there is no edit focus
after returning from accept() and the OK key can propagate outside the
modal dialog.
This causes the parent widget to receive and act upon the OK key as well
which makes problems - e.g. in QTBUG-4724, recursive menu activation
Task-number: QTBUG-4724
Reviewed-by: Alessandro Portale
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
QFileDialog contains own internal derived classes for line edit and
list view. Unfortunately, these classes do not handle keypad navigation
correctly - they just accept the navigation key events, causing the
navigation to halt.
Added support for QFileDialogListView, QFileDialogTreeView and
private filedialog class QFileDialogPrivate to handle and possibly ignore
keypad navigaion key events.
Additionally, added support to keypad navigation to ignore empty
widgets. This allows keypad navigation not to go invisible when empty
widgets are tried to be navigated into.
Task-number: QT-643
Reviewed-by: Alessandro Portale
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The protected constructor of QFileDialog call selectAll() on the
line edit. This constructor is only called by static methods. But the
regular constructor didn't behave the same. Now it does :D.
Task-number:QTBUG-4419
Reviewed-by:jasplin
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Some fonts contain only styles other than Normal (or Regualr). If we try
to retrive the font sizes for such fonts by passing an empty style
string, the QFontDatabase will return a null list. This was causing the
autotest to fail. This patch will make sure that a style is always
selected in the QFontDialog.
Reviewed-by: Olivier
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
PrintDlgEx requires an non-null owner handle, otherwise it will fail
with an "Invalid Handle" error. This caused code which popped up a
print dialog as the only window in the application to fail silently
and immediately return Rejected from the exec() function. To continue
support for this somewhat unusual use case, we fall back to using the
print dialog itself as the owner of the print dialog sheet if all else
fails.
Reviewed-by: Trond
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously there were many options here that were inherited from the
Qtopia implementation. It was not clear to developers which value
they actually should use. A good example was the 'Next' value. In
a typical wizard application, next would be on the right and
'Previous' would be on the left. However, it is also common to have
'Next' on the left and have 'Cancel' on the right.
Basically what people really wanted was a way to explicitly set the
right and left soft keys, but since this relies on form factor and
is wrong if the screen is rotated, we choose positive and negative
actions as the values for these such that they still make sense when
the screen is rotated. Also this helps people who don't know if a
particular action should be on the left or right, but they *do* know
if their action has destructive characterisitics (negative).
As a convenience for widgets in Qt that use softkeys, we create a
standard softkey enumeration. That maps the actions to the correct
role and has default text.
Reviewed-by: Alessandro Portale
|