On 14/03/2019 16:41, Matthew Woehlke wrote:
On 13/03/2019 18.41, Sérgio Martins via Interest wrote:
Do you have:
QApplication::setAttribute(Qt::AA_EnableHighDpiScaling);
Uh... *why* is that not the default? Without that, I still get a scaled
UI, but it is an ugly mix of stuff that's
On Thursday, 14 March 2019 07:31:45 PDT René J. V. Bertin wrote:
> Thiago Macieira wrote:
> > more likely, a *library* difference: something may be calling
> > QCoreApplication::setLibraryPaths(). instead of
> > QCoreApplication::addLibraryPath().
>
> I thought about that too, but can now say
On Thursday, 14 March 2019 09:59:33 PDT Jason H wrote:
> At a minimum the docs should elaborate that finished() only happens after
> started, and started only happens if the... process is scheduled?
Not exactly. The problem is the asynchronous nature of fork()+exec() on Unix
systems. On Windows,
> > > perhaps adding a QProcess::notRunning signal is in order? Or at least some
> > > clarification in the docs?
> >
> > Sorry, no. Just the name of the signal you proposed shows it's a bad idea.
> > Signals are always named after verbs in the past tense, indicating
> > something
> > that
On Thu, Mar 14, 2019 at 08:14:38AM -0700, Thiago Macieira wrote:
> On Thursday, 14 March 2019 07:04:53 PDT Jason H wrote:
> > perhaps adding a QProcess::notRunning signal is in order? Or at least some
> > clarification in the docs?
>
> Sorry, no. Just the name of the signal you proposed shows
On Thursday, 14 March 2019 07:04:53 PDT Jason H wrote:
> perhaps adding a QProcess::notRunning signal is in order? Or at least some
> clarification in the docs?
Sorry, no. Just the name of the signal you proposed shows it's a bad idea.
Signals are always named after verbs in the past tense,
On 13/03/2019 18.41, Sérgio Martins via Interest wrote:
> Do you have:
>
> QApplication::setAttribute(Qt::AA_EnableHighDpiScaling);
Uh... *why* is that not the default? Without that, I still get a scaled
UI, but it is an ugly mix of stuff that's *properly* scaled (and making
use of the higher
Thiago Macieira wrote:
Hi,
1
> more likely, a *library* difference: something may be calling
> QCoreApplication::setLibraryPaths(). instead of
> QCoreApplication::addLibraryPath().
I thought about that too, but can now say that I can indeed switch between the
2
behaviours simply by including
> > Because the NotRunning will occur always, and immediately, and finished
> > won't. Failed command:
> > stateCanged QProcess::Starting
> > stateCanged QProcess::NotRunning
> > // no finished!
>
> Good catch. A process that didn't start can't finish.
>
> Another way would be to
sorry - I'm not using BLE advertising or Beacons yet
I'm connecting BLE devices to my mobile apps (Android, iOS,
Windows10-Touch-Devices):
* GeneralScan BLE Barcode Readers
* NFC Reader (to enable reading UUID from NFC Tags on iOS via BLE)
* Addimat Waiterlock to Login/Logout users with magnetix
Now that's a good news! I'm looking forward to use 5.13 just for this, we will
finally be able to test our BLE application under Windows. Do you know if the
BLE advertising can be seen in raw byte? or only iBeacon/eddy stone.../pregen
format is supported under Windows?
I did iOS and Android
I have a QTableView.
I use a QStyledItemDelegate on each cell.
The delegate opens a custom, modal editor on double click.
The editor is based on a QDialog and contains a number of widgets,
one of which is a QComboBox.
When I press in the text entry area of the QComboBox,
the whole edit window
thanks making this possible :)
tested with Qt 5.13.0 Alpha, Windows 10 pro and MSVC2017-64 binary
now BT LE devices are detected without pairing :)
can explore all services and characteristics
connect is working
read from / write to works well
notify: on some devices not working
disconnect:
13 matches
Mail list logo
