Instead of showing the last page this will always show the home
page when activating index or content from the help menu.
Task-number: QDS-6392
Change-Id: Ic158d22ba3739f5db513e04ebde00fdadc24a9d5
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Saves some code on the user side.
Change-Id: I32cd220b6e533f5497a1865f9c34ab9db4cfda79
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
If the scrollWheelZooming is enabled, this
setting will get updated when using scroll wheel.
It will also be used when zooming in/out
by using keyboard shortcuts.
Fixes: QTCREATORBUG-25109
Fixes: QTCREATORBUG-25230
Fixes: QTCREATORBUG-23731
Change-Id: I9d22632b4c034ce236fa39dba074df4a2746ff84
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
The coreplugin/id.h header is kept for downstream for now.
Change-Id: I8c44590f7b988b3770ecdc177c40783e12353e66
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
There are more, but we need to keep those because MSVC believes they are
required. This is the subset that satisifies both compilers.
Change-Id: I0b0a63d5496acc119a7f0513d3a1da0b76fa1fca
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: David Schulz <david.schulz@qt.io>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Adapt the code to deprecated usage of map as a multi map,
hence all cases replaced by QMultiMap.
Change-Id: I2d480467cd6e91d3e880555e6a21058dec056b3f
Reviewed-by: Karsten Heimrich <karsten.heimrich@qt.io>
It was invented as a "remote help" filter, but it actually doesn't have
anything to do with help or documentation.
Move it to more general place, also to enable future generalization to
another custom filter type.
Change-Id: Ib80eacd3c7cc33ae9f4d9353fa820272e3b0b25f
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Reviewed-by: David Schulz <david.schulz@qt.io>
Qt Creator was syncing the current page in Help mode to the page shown
in the side-by-side view in edit mode.
This doesn't really make sense because context is completely lost.
Instead provide the explicit option to open a help page in edit mode,
also from the external help window.
Fixes: QTCREATORBUG-19198
Change-Id: I00698bb431d5c116dd1e0e1cbdc5fbd7421ac267
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Reviewed-by: David Schulz <david.schulz@qt.io>
Which are relevant now that external windows support multiple pages.
Change-Id: Ibc748e9e0582c8d54264af535c32aa2702f91631
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
It's owned by the HelpWidget now, and should be accessed through that.
Task-number: QTCREATORBUG-20558
Change-Id: I99118bb966922e6b4d356cf892d7604365357785
Reviewed-by: hjk <hjk@qt.io>
For the help mode, the help viewer pages were managed both by the
OpenPagesModel and the HelpWidget, and needed manual keeping in sync.
Instead make the model just an aspect of the HelpWidget, manage
creation/deletion of pages via the HelpWidget, and use the model only
for the pure MVC API purposes.
Task-number: QTCREATORBUG-20558
Change-Id: Ib7d6f2561239b0d5f3328dfd30c84718f81af0a1
Reviewed-by: David Schulz <david.schulz@qt.io>
For CMake add litehtml installation path to CMAKE_PREFIX_PATH
For qmake pass litehtml installation path via LITEHTML_INSTALL_DIR qmake
variable
Release build of litehtml is recommended.
The litehtml backend is used by default when available, you can force
QTextBrowser again with the environment variable
"QTC_HELPVIEWER_BACKEND=textbrowser".
Some things are not implemented yet:
- Text search
- Context menu
- Shift-drag to extend existing selection
Change-Id: I79f989e5fe2063de2e9832abbed19b24d7a1a1fe
Reviewed-by: hjk <hjk@qt.io>
Deprecated in Qt 5.14, alternative has been around since Qt 4 at least.
Change-Id: I4e3a53c289088368609e0d0ce2405a832d311308
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
If help is only found by looking up in the index, show a selection
dialog to the user even if there is only one result. Otherwise we create
the impression that we really think that the help we find is the correct
one.
Also do not add the help text to the tool tip in this case.
Test case: struct Foo { static void objectCreated() {} };
Change-Id: I9579302843ea2923e06f56f4b646dd101f183b3f
Reviewed-by: David Schulz <david.schulz@qt.io>
And if multiple topics are found in the index, show the topic chooser
dialog that we already have for the help index.
Fixes: QTCREATORBUG-12704
Task-number: QTCREATORBUG-15959
Change-Id: I7afa6f44bbecc12f602aaaa4a11209ec72399689
Reviewed-by: David Schulz <david.schulz@qt.io>
Context help should take the HelpItem from the tool tip if it was set,
even if it isn't valid.
Similarly, if the help item was set on the text editor, it should not
ask the hover handlers (again), even if that is invalid
Change-Id: I481f8ad73c3cf8fdbb90f737ab36b4e380467026
Reviewed-by: David Schulz <david.schulz@qt.io>
No need for code duplication.
Change-Id: I3d2c795d072b8de5818e1844b8126e526339c0da
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: David Schulz <david.schulz@qt.io>
Save the HelpItem directly in the tooltip instead of the help ID which
would need to be looked up again.
Change-Id: I107e82e89d9ea26cad9d6532ad4c687d1ac8f1ec
Reviewed-by: David Schulz <david.schulz@qt.io>
Users know if they have a URL or not, we should not guess (and then even
guess differently at different places)
Change-Id: Iaaf69a94baadbee0ff427a2bc9065b714dcf8478
Reviewed-by: David Schulz <david.schulz@qt.io>
Context help would first query the database with potential IDs, and
afterwards the help plugin would look up the links for the resulting ID
again.
Pass the HelpItem (which potentially contains the cached links) directly
to context help.
Change-Id: I73bddcd3cd4eacaea412b98d53c5e5354a31f3d5
Reviewed-by: David Schulz <david.schulz@qt.io>
The help widget doesn't need to resolve the external help viewer
instance manually, we have an entrypoint for that already.
Change-Id: I6875c434428baac3f1883813207cf318d7d3dc09
Reviewed-by: David Schulz <david.schulz@qt.io>
Introduce a generic Utils::TouchBar that implements a touch bar for
macOS based on QAction. Touch bars can be nested, and one is set to be
the application's top level touch bar.
Also add an ActionContainer for the touch bar. That allows us to manage
the layout of the touch bar the same way we do with menus.
Since the touch bar is an input device with very limited space, a
command in the touch bar needs to be specifically styled for the touch
bar by setting either touchBarText or touchBarIcon (or both).
Touch bars can be nested by nesting the ActionContainers. A nested touch
bar ActionContainer needs to specify an icon and/or text to show in the
touch bar button that opens that sub-bar.
Commands are only shown in the touch bar if they are valid within the
current context.
Implementation-wise we cannot use the standard NSPopoverTouchBarItem for
nesting touch bar levels. We cannot hide items in the touch bar, because
hidden items still take up space in the touch bar. So we need to rebuild
the touch bar regularly. Since the items we show are very dynamic, every
time the items in the toplevel bar change because of a context change,
any opened sub-level touch bar closes. That is why we maintain a stack of
touch bar levels ourselves, replacing the main touch bar with the current
level, and managing opening and closing the levels manually.
This patch adds buttons for Help, Bookmarks, Header/Source, Follow
(Symbol), Decl/Def, and a sub-bar for the debugger actions.
Fixes: QTCREATORBUG-21263
Change-Id: Ib63e610f21a993f1d324fe23c83a7f2224f434ac
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Reviewed-by: Vikas Pachdha <vikas.pachdha@qt.io>
It is documentation related API, so it belongs there.
Change-Id: I5d1676f251e6deb92050ddedac19bf3c332aab54
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
We don't want various plugins to depend on the Help plugin,
but we also do not want Core to depend on QtHelp.
For example when turning the Help plugin off, documentation should
actually no longer be registered through QtHelp. So we need
parts of the interface in Core, which must then be delegated
to the actual implementation in Help.
As positive side-effects the interface in Core will be slimmer,
and the code in the Help plugin can later be simplified, too,
because then we don't have the "Core" and the "Gui" help engines
separated in different plugins anymore, which should remove the
need for some setup indirections.
Task-number: QTCREATORBUG-20381
Change-Id: I634c5811c45d6a3dfd6ddc682cae270e38384cbf
Reviewed-by: hjk <hjk@qt.io>
- In the main window, the locator input (actually the status bar)
visually feels like being part of the mode widget, so give
it its context.
- In extra editor windows, the whole editor window should have
"editor manager" context, so that is also active for the locator
input.
Task-number: QTCREATORBUG-20626
Task-number: QTCREATORBUG-20071
Change-Id: Ib68d6a8177446572ea59c3cc057eca0706173e11
Reviewed-by: Xing Xiong
Reviewed-by: David Schulz <david.schulz@qt.io>
Making it a QWindow meant that Alt-Tab will lead to the main window and
right back to "System Information" because this is modal. This
incovenience outweighs the convenience of having a "Maximize" button.
This reverts a part of 40d7399755
Task-number: QTCREATORBUG-20513
Change-Id: Idcea54ee2f60f9f7efde7d25ce0c305b87f445dd
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
