| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
| |
environment
|
|\
| |
| |
| | |
softkeys_without_stack
|
| |\
| | |
| | |
| | | |
softkeys
|
| | |\
| | | |
| | | |
| | | |
| | | | |
Conflicts:
tests/auto/qlocalsocket/tst_qlocalsocket.cpp
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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
|
| | | |
| | | |
| | | |
| | | | |
This enables the softkeys to actually be visible on the screen
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
of QSoftKeyStack broke compilation on clean environment...
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
new improved softkey interface in QWidget
|
| | | |
| | | |
| | | |
| | | |
| | | | |
failure. Context menu will be enabled again once the QAction SoftKeyRole
implementation is in state where context menu can be properly supported
|
| | | | |
|
| | | | |
|
|/ / /
| | |
| | |
| | | |
softkeystack but instead softkeys are stored in QWidgets.
|
|\ \ \
| |/ /
| | |
| | | |
softkeys
|
| | |
| | |
| | |
| | |
| | | |
We need to check for replacementLength as well. Otherwise there will
be no undo information if text is deleted using input methods.
|
| | | |
|
|\ \ \
| |/ / |
|
| |\ \ |
|
| | | |
| | | |
| | | |
| | | |
| | | | |
RevBy: Trust me
AutoTest: Will add in later commit
|
| | | |
| | | |
| | | |
| | | |
| | | | |
RevBy: Simon Hausmann
AutoTest: Will add in later commit
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This reverts commit ce02d0e9e0ad8d8ac47e4f3ee95bac5cb74ed184.
This turned out not to be enough for proper selection support
together with S60 FEP. Instead we will revert the behavior and add
new API.
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
inside QtGui, we do not need to export those QMenu[Bar]::symbianCommands
through our public API, anymore.
This commit moved the code of QMenuBar::symbianCommands to
QMenuBarPrivate::symbianCommands and made that one static.
QMenu[Private]::symbianCommands was apparently unused -> deleted.
RevBy: Jason Barron
RevvBy: Markku Luukkainen
|
| |\ \ \
| | |/ /
| |/| /
| | |/
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
configure.exe
examples/itemviews/puzzle/puzzle.pro
examples/qtconcurrent/imagescaling/imagescaling.pro
examples/widgets/movie/movie.pro
tools/configure/configureapp.cpp
Will rebuild configure.exe in next commit.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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
|
| | |
| | |
| | |
| | |
| | | |
This circumvents the need to go and change every example to explicitly
start using softkeystack
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | | |
gets deleted.
|
| | | |
|
| | |
| | |
| | |
| | | |
QAbstractItemView::keyPressEvent to remove the "Back" key.
|
| | | |
|
| | |
| | |
| | |
| | | |
It is also needed in other places.
|
| | | |
|
|\ \ \
| | | |
| | | |
| | | | |
softkeys
|
| | | |
| | | |
| | | |
| | | | |
a menu button to softkeys
|
|\ \ \ \
| |/ / /
|/| / /
| |/ / |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | | |
QSoftKeyStackPrivate. Removed QSoftKeyStack::handleSoftKeyPress
and made QSoftKeyStackPrivate::handleSoftKeyPress static, so that
it can be called from QApplication.
|
| | |
| | |
| | |
| | | |
No implicit creation happens.
|
|\ \ \
| |/ / |
|
| | | |
|
| |\ \ |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
is instantiated better
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
QMainWindow has a softkeystack or not.
Making method QSoftKeyStack *softKeyStack() const return 0 when
there is no softkeystack was also evaluated. Returning 0 was discarded
as it would make softKeyStack() behave differently than statusBar() and
menuBar() methods. It would be bad API design to have methods
in same class behave differently.
|