The width of the List view showing the
autocompleter proposals is now adjusted
when scrolling.
Task-number: QTCREATORBUG-7185
Change-Id: I5b26ef6195d389b30fdf0964bebd9c2f33056c66
Reviewed-by: Leandro Melo <leandro.melo@nokia.com>
this is the behaviour of many OS X widgets, e.g. in Spotlight
Change-Id: Idc769d45d53b332bafdfb8190fd3d14843347776
Reviewed-by: Eike Ziller <eike.ziller@nokia.com>
QT_MAC_USE_COCOA is not defined for Qt 5, which
caused GenericProposalWidget to use a carbon
workaround during key handling.
Add QT_VERSION check. These are the only instances
of QT_MAC_USE_COCOA usage in creator.
Change-Id: I71ee23e14d791166ccd5645c52b152489d7f8f72
Reviewed-by: Eike Ziller <eike.ziller@nokia.com>
Getting the #include directives ready for Qt5. This includes the
new-project wizards.
Change-Id: Ia9261f1e8faec06b9285b694d2b7e9a095978d2b
Reviewed-by: Eike Ziller <eike.ziller@nokia.com>
Now IGenericProposalModel::isSortable also takes the current prefix
as a parameter. This is particularly useful for cases like in the C++
completion: For global completions it will only sort if there's
already a content prefix - Notice, however, that the "sorting threshold"
for a maximum number of items is still kept in IGenericProposalModel::sort.
Task-number: QTCREATORBUG-6404
Change-Id: I3c2f282aa565287b8b4989930b6a27093862ef25
Reviewed-by: Roberto Raggi <roberto.raggi@nokia.com>
We want to carry over all mac-specific code paths
to Qt 5. WS_MAC is no longer set; OS_MAC is.
This change is compatible with Qt 4 builds since
OS_MAC is set whenever WS_MAC is. (OS_MAC would
also be set for the theoretical X11/Mac platform,
but that's anyway not a supported configuration
for Creator)
Change-Id: Ib25d8c4e83e7e27d911124cd48aa17fdb875923f
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@nokia.com>
Reviewed-by: Eike Ziller <eike.ziller@nokia.com>
In a relatively recent commit (99fee33fd1)
premature match was setup to work only on explicit invocations. However
this has shown to be too strict. Therefore, it's now a bit relaxed (not
as much as before): If the current item ends with the typed character we
assume this is intenional - general premature matches do not end with
identifier characters anyway.
Note: Leaving only the last character as the condition is not an option
since sometimes they are not shown in the proposal description.
This patch also lifts the text method to IAssistProposalItem since
it's reasonable the every proposal must have at least some description.
Change-Id: I2ef7de2b7f978ce7059cce50175137a03315f495
Reviewed-on: http://codereview.qt.nokia.com/675
Reviewed-by: Qt Sanity Bot <qt_sanity_bot@ovi.com>
Reviewed-by: Christian Kamm <christian.d.kamm@nokia.com>
Automatic prefix and implicit completion should only
happen when the setting allows, the popup is synchronized,
and the completion has just been invoked. This means that
if characters are typed afterwards they should not trigger
such behavior.
Change-Id: Iedfc4211d171a21ef0a2daaa475d291e756e7cc0
Reviewed-on: http://codereview.qt.nokia.com/570
Reviewed-by: Thorbjørn Lindeijer <thorbjorn@lindeijer.nl>
Keeping or not the completion popup upon a perfect match
is best identified by the model in question instead of simply
by the triggering reason. For instance, in QML we don't want
to preserve the popup if completion was triggered by an
activation sequence. On the other hand, this is ok for C++
since a semicolon or parenthesis will in general still be
typed (in some cases even with the intention to take advantage
of the automatic bracked insertion).
For more context see 271bd44d2c1daa43c125cc09e6af57bb756de857.
Change-Id: If9dbf33243b623c077ce027e7e46265d0fc4ba8b
Reviewed-on: http://codereview.qt.nokia.com/563
Reviewed-by: Thorbjørn Lindeijer <thorbjorn@lindeijer.nl>
This reverts commit 4959f53d2c.
It seems that usability is better when upon a perfect match the completion
popup stays when triggered either explicitly or by an activation character.
After all, in general one should need to type something else (semicolon,
parenthesis, etc.) anyway for the case of an activation character.
This is also consistent with the behavior from previous releases.
Change-Id: I1d50230affb1d0642f8f8bfd5cbac69dc52e44bd
Reviewed-on: http://codereview.qt.nokia.com/536
Reviewed-by: Thorbjørn Lindeijer <thorbjorn@lindeijer.nl>
This should not only be when the editor is idle but whenever the
completion was not invoked explicitly.
Change-Id: I0f3dbbe2f5db66ae3e1f57c7039a93f74f31e1dc
Reviewed-on: http://codereview.qt.nokia.com/130
Reviewed-by: Roberto Raggi <roberto.raggi@nokia.com>
Whith the out-of-GUI completion one can have undesired
effects when invoking the completion, continue typing,
getting automatic content added to the editor
asynchronously, and then noticing that the lastly
input characters were "shifted" to a different
position.
Now we only do partial completions or implicit completions
(when there's a single match) if the proposal widget is
still in synch with the editor. In other words, if the
editor has not received input from the moment the completion
was triggered until it was actually displayed.
Change-Id: I31683bd596c9f75b9a48bb79dafb48eec8f12a3e
Reviewed-on: http://codereview.qt.nokia.com/44
Reviewed-by: Roberto Raggi <roberto.raggi@nokia.com>
This is a re-work of our completion engine. Primary goals are:
- Allow the computation to run in a separate thread so the GUI is not locked.
- Support a model-based approach. QStrings are still needed (filtering, etc), but
internal structures are free to use more efficient representations.
- Unifiy all kinds of *assist* into a more reusable and extensible framework.
- Remove unnecessary dependencies on the text editor so we have more generic
and easily "plugable" components (still things to be resolved).
