Add a -D command line option which skips auto-detection of devices upon
startup. This can speedup program startup for setups with known devices,
and allows to skip the scan for troubled drivers which might break the
startup phase.
This -D option can be combined with -d specs, either presence or absence
of -d is acceptable when -D is specified. Users still can interactively
scan for and use devices after program startup.
This resolves bug #1116.
The previous implementation had support to auto-detect devices and to
connect to and pick devices by filling in dialogs, optionally providing
scan options that did not apply to auto-detection. This commit extends
the existing support by introducing a -d command line option similar to
sigrok-cli.
In the absence of the -d command line option, behaviour is identical to
the previous implementation. When -d is provided, the specified driver
is excluded from the auto-detection phase, and another scan is executed
afterwards where the user specified scan options take effect. This shall
result in least interaction and highest reliability of device detection,
while flexibility is increased.
Here are examples of what the -d command line option can do:
$ pulseview -d ols:conn=/dev/ttyACM0
$ pulseview -d fx2lafw
$ pulseview -d demo:logic_channels=32:analog_channels=8
This fixes bug #953.
I don't know any cli tool that shows a description text
on the same line as the usage and sigrok-cli doesn't do it
either, so it shouldn't be there.
As I don't see any other place where it would make sense,
I remove it completely.
This can have various types (e.g. a file or a registry entry) and it can
be in various locations on different OSes, so having this as part of the
log output is pretty useful.
Use "using std::foo" to make the actual code itself a lot more readable.
There are some exceptions where we usually cannot do this, e.g. std::thread
often conflicts with "thread" from Qt or Boost.
We currently need to (ab)use pkg-config to get all the required
Qt5 static linking dependencies right, since this doesn't yet
work properly in MXE's cmake.
We use ${PKGDEPS_STATIC_LDFLAGS} instead of ${PKGDEPS_STATIC_LIBRARIES}
to avoid some linker issues related to libbz2.
We need to add Qt5::QSvgPlugin, Qt5::QWindowsIntegrationPlugin,
Qt5PlatformSupport and all the Qt5 libs and their dependencies to
the link libraries list (for both PulseView and the unit tests).
In one of the source code files we need to explicitly list all
static Qt plugins via Q_IMPORT_PLUGIN to make static builds work,
which is currently QWindowsIntegrationPlugin and QSvgPlugin.
We're only focusing on having a working Qt5 build for Windows,
as we no longer need to or want to support Qt4 there.
Details:
https://github.com/mxe/mxe/issues/1642
Thanks to Tony Theodore for the help!
This should also fix bug #871, since we're now building with Qt >= 5.6
which has high-DPI support in general.
Tested via manual specification (might need further changes, though):
set QT_SCALE_FACTOR=2
pulseview.exe
This used to work in e.g. the 0.2.0 release and is much more convenient
than having to supply "-i" for every file. It also allows for (easier, at
least) association of the .sr extension with PulseView on most OSes.
On Windows (where we use a static Qt) we need to include plugins
(in this case "qsvg" a.k.a. libqsvg.a from plugins/imageformats/),
otherwise SVGs (such as various icons in PulseView) cannot be displayed.
For this we need to use Q_IMPORT_PLUGIN(qsvg) in the code, pass the
QT_STATICPLUGIN flag to the compiler, and link against "-lqsvg".
This, in turn, requires that we also link against the similarly named QtSvg
component/lib (${QT_QTSVG_LIBRARY} a.k.a libQtSvg.a).
See also: https://qt-project.org/doc/qt-4.8/plugins-howto.html#static-plugins
This fixes bug #239.
pulseview/main.cpp: In function ‘int main(int, char**)’:
pulseview/main.cpp:91:13: error: comparison is always false due to limited range of data type [-Werror=type-limits]
Signed-off-by: Matt Ranostay <mranostay@gmail.com>
System headers, glib headers, and libsigrok/libsigrokdecode headers all
use 'extern "C"' already, so there's no need to explicitly add these
in PulseView (for these cases).
Thanks R. Diez <rdiezmail-comparevcd@yahoo.de> for the patch!
Thanks R. Diez <rdiezmail-comparevcd@yahoo.de> for the patch!
This is not a feasible practice for CLI tools where the output might
be piped into other tools (and you don't want to pipe help messages or
other non-data). However, for the PulseView GUI this is acceptable since
it's not meant to be used that way.