Hi,
I just want to drop in with a little thank you and basically to share my
thoughts about QtSP. Last week I've built a project using QtSerialPort
(with Qt4) to communicate with an Arduino board, and tested it on Linux
(Ubuntu and Kubuntu) and Windows (7 and embedded), on numerous PCs (VM,
laptop
On 4.2.2013, at 12.42, Anttila Janne
mailto:janne.antt...@digia.com>>
wrote:
Simo can you add CI for QtSerialPort repository? I think it would be
beneficial have build-only CI already before virtual loopback serial
ports are enabled.
Yep, I will do that.
Simo
_
Laszlo Papp wrote:
> To summarize the automated testing topic.
>
> 1) QtMock will not reach a usable state any soon, unfortunately.
>
> 2) I am not sure which construction of the aforementioned ones would fit
> the operation of the CI machines. Could anyone please comment on that
> with the rel
To summarize the automated testing topic.
1) QtMock will not reach a usable state any soon, unfortunately.
2) I am not sure which construction of the aforementioned ones would fit
the operation of the CI machines. Could anyone please comment on that with
the relevant competence?
3) Is this a blo
On 2013/01/26 01:44 PM, Konrad
Rosenbaum wrote:
Windows: there are several projects on
Sourceforge that emulate serial interfaces. I've used com0com to
simulate loops.
+1 for com0com.
--
Regards
Alex
__
On Saturday 26 January 2013, Laszlo Papp wrote:
> On Fri, Jan 25, 2013 at 9:05 PM, Knoll Lars wrote:
> > And a question: There's no auto tests. I know that testing serial
> > ports
> > can't really be done in an automated fashion, but is there anything we
> > can do to cover the module?
> * The
On 26.01.2013 07:34, Laszlo Papp wrote:
>
> Good question; we discussed this issue before. This is unfortunately also a
> real problem for us to test the module with
> all the combinations for each factor. It requires (semi-)manual testing and
> hence a bit of effort. I see two ways to
> improve
On Fri, Jan 25, 2013 at 9:05 PM, Knoll Lars wrote:
> From an API perspective it looks pretty good. I'm not an expert on serial
> ports, but from what I recall from the time I dealt a little with them
> (must be 10 years ago or so…) it looks pretty complete as well. S o with
> the changes proposed
+1, that is good news.
Am 26.01.2013 um 01:06 schrieb "Knoll Lars "
:
> Hi Lazlo,
>
> sorry for the late answer.
>
> I went through the module now, and it looks like a good and solid
piece of work. Thanks to everybody who contributed :)
>
> From an API perspective it looks pretty good. I'm not
Hi Lazlo,
sorry for the late answer.
I went through the module now, and it looks like a good and solid piece of
work. Thanks to everybody who contributed :)
>From an API perspective it looks pretty good. I'm not an expert on serial
>ports, but from what I recall from the time I dealt a little
On Thu, Jan 24, 2013 at 7:20 AM, Denis Shienkov wrote:
>
> Who thinks that? Let's vote! :)
>
Submitted a change last night after our discussion:
https://codereview.qt-project.org/#change,45640
Laszlo
___
Development mailing list
Development@qt-project
About enumerating BaudRate, my opinion:
1. Enumeration should be kept, similar to other enums for another settings
(data bits, flow and etc.).
If we abandon the enums of baud rate - this will somehow ugly.
2. The names of the enums and their value should be changed.
3. Number of basic types of
On Wed, Jan 23, 2013 at 8:49 PM, Laszlo Papp wrote:
> On Wed, Jan 23, 2013 at 9:45 PM, Thiago A. Corrêa
> wrote:
>>
>> You mean filling the Combo Box with available rates right? (
>> ui->rateBox->addItem(QLatin1String("9600"), SerialPort::Rate9600); )
>> I would just fill in the numbers in the se
On Wed, Jan 23, 2013 at 9:45 PM, Thiago A. Corrêa
wrote:
> You mean filling the Combo Box with available rates right? (
> ui->rateBox->addItem(QLatin1String("9600"), SerialPort::Rate9600); )
> I would just fill in the numbers in the second argument of addItem.
> Other than maybe getting a compiler
On Wed, Jan 23, 2013 at 6:57 PM, Laszlo Papp wrote:
> On Wed, Jan 23, 2013 at 8:27 PM, Thiago A. Corrêa
> wrote:
>>
>> IMHO we could drop the enumeration from the public API.
>
>
> What would you use for setting a conrete value for your serialport like the
> terminal example demonstrates that use
On Wed, Jan 23, 2013 at 8:27 PM, Thiago A. Corrêa
wrote:
> IMHO we could drop the enumeration from the public API.
What would you use for setting a conrete value for your serialport like the
terminal example demonstrates that use case?
> I'm not native english
> speaker but I think writting it
On Wed, Jan 23, 2013 at 5:50 PM, Laszlo Papp wrote:
> On Wed, Jan 23, 2013 at 6:37 PM, Thiago A. Corrêa
> wrote:
>>
>> Oh, I thought it was discussed previously, but since you mentioned,
>> baudRate would be nicer.
>
>
> Yes, I had proposed it back then to Denis iirc, so we did discuss it. Cannot
On Wed, Jan 23, 2013 at 6:37 PM, Thiago A. Corrêa
wrote:
> Oh, I thought it was discussed previously, but since you mentioned,
> baudRate would be nicer.
Yes, I had proposed it back then to Denis iirc, so we did discuss it.
Cannot recall whether Denis did not like the idea or we were lazy bugger
> > Where is the read only cts property with a ctsChanged signal to
> monitor the input pin?
>
> Nowhere. Again, there is a impossible have a cross-platform
> capabilities to notify about change of CTS pins.
> In principle, this feature is available only for Windows, but POSIX
> does not provide t
Hi,
On Wed, Jan 23, 2013 at 4:17 PM, wrote:
>
> Let me put it another way:
> Where is the read only cts property with a ctsChanged signal to monitor the
> input pin?
> I expect rts() to return the value we are currently sending on the RTS
> output, and cts() to return the value we are currentl
> Where is the read only cts property with a ctsChanged signal to
monitor the input pin?
Nowhere. Again, there is a impossible have a cross-platform capabilities
to notify about change of CTS pins.
In principle, this feature is available only for Windows, but POSIX does
not provide this.
To o
>As I repeated the above, it can not be done, at least cross-platform.
>On Windows there is a possibility, but not the fact that it is implemented
>correctly.
OK, that is a good reason to not include it.
>>The UART has four control lines: RTS/CTS and DTR/DSR, two inputs and two
>>outputs.
>>
>
*Cc:* development@qt-project.org
*Subject:* Re: [Development] Proposal - QtSerialPort graduation from
the Playground
API headers:
http://qt.gitorious.org/qtplayground/qtserialport/blobs/master/src/serialport/serialport.h
http://qt.gitorious.org/qtplayground/qtserialport/blobs/master/src/s
t.org
[mailto:development-bounces+shane.kearns=accenture@qt-project.org] On
Behalf Of Laszlo Papp
Sent: 10 January 2013 19:47
To: Thiago Macieira
Cc: development@qt-project.org
Subject: Re: [Development] Proposal - QtSerialPort graduation from the
Playground
API headers:
http://qt.gitoriou
Hi,
Even though I haven't accumulated many merit points in the dev list
yet, I would like to make a very short review.
On Thu, Jan 10, 2013 at 5:47 PM, Laszlo Papp wrote:
> API headers:
>
> http://qt.gitorious.org/qtplayground/qtserialport/blobs/master/src/serialport/serialport.h
> http://qt.git
On Sat, Jan 12, 2013 at 2:13 PM, Uwe Rathmann wrote:
> Hi Denis + Laszlo,
>
> > IMHO, this for QextSerialPort: do not see any features.
>
> QextSerialPort is pretty old ( from the 90s ) and the fact that it isn't
> really a Qt library is probably the reason why it has survived all the
> developmen
Hi Denis + Laszlo,
> IMHO, this for QextSerialPort: do not see any features.
QextSerialPort is pretty old ( from the 90s ) and the fact that it isn't
really a Qt library is probably the reason why it has survived all the
development of Qt without being actively maintained.
But I don't vote for
On Sat, Jan 12, 2013 at 11:45 AM, Laszlo Papp wrote:
> 2) Implementation
>
> * We use Q_ENUMS, Q_DECLARE_FLAGS, Q_DECLARE_OPERATORS_FOR_FLAGS and so
> forth for the serial port related enumerations like baudrate, databits,
> parity, stop bits, flow control, and so forth.
>
> * We use windows spec
Hi Uwe,
First, QtSerialPort closely linked to the Qt event-loop subsystem with using
fully async signal/slots concept.
This allows you to not use a separate thread to monitor I/O events.
> By the way: what are the major differences between QtSerialPort and the
> qextserialport project ?
IMHO, t
On Sat, Jan 12, 2013 at 10:32 AM, Uwe Rathmann wrote:
> In general I see 2 reasons why a lib should be using Qt:
>
> 1) The implementation has a significant benefit from using Qt
> 2) The API needs to use Qt classes to be "usable in a comfortable way" in
> a Qt application
>
As far as I can brief
On Sat, 12 Jan 2013 11:22:31 +0400, Denis Shienkov wrote:
>>A cross platform compatible API for the serial port is a useful thing,
>>but is there a good reason for limiting it to Qt applications ?
>
> Why do you think that this is a limitation?
Well, an application using wxWidgets probably would
>A cross platform compatible API for the serial port is a useful thing,
>but is there a good reason for limiting it to Qt applications ?
Why do you think that this is a limitation?
This is just a separate, cross-platform implementation of the serial port,
taking into account the Qt-specific,
an
On Wed, 09 Jan 2013 21:18:40 +0100, Laszlo Papp wrote:
> Another try: can we reiterate this question for 5.1?
Several years ago I was asked if I would accept the ( at that time
orphaned ) qextserialport project as module of Qwt.
I decided not to do so because its code was more or less unrelated
API headers:
http://qt.gitorious.org/qtplayground/qtserialport/blobs/master/src/serialport/serialport.h
http://qt.gitorious.org/qtplayground/qtserialport/blobs/master/src/serialport/serialportinfo.h
Docs:
http://qt.gitorious.org/qtplayground/qtserialport/blobs/master/src/serialport/serialport.cp
On quarta-feira, 9 de janeiro de 2013 21.18.40, Laszlo Papp wrote:
> Another try: can we reiterate this question for 5.1?
Can you post the API headers and a link to the docs and examples, so we can do
an API review?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel
Another try: can we reiterate this question for 5.1?
On Fri, Sep 14, 2012 at 1:11 PM, Laszlo Papp wrote:
> Hi Lars,
>
> with everyting that has been happening recently around Qt I have not had a
> chance to follow up on the QtSerialPort integration. Is there still a
> chance that this could make
Hi Lars,
with everyting that has been happening recently around Qt I have not had a
chance to follow up on the QtSerialPort integration. Is there still a
chance that this could make it into Qt5?
Laszlo
http://qt.gitorious.org/qtplayground/qtserialport
http://lists.qt-project.org/pipermail/develo
> Great to hear you think it's ready as an add-on. The list of things you've
> achieved above sounds pretty good and complete. So IMO the main thing that
> still should happen is a review of the APIs and docs. I'm willing to go
> through it, once we have the Qt 5 beta out, and proceed from there.
>
Hi,
On Jul 23, 2012, at 7:15 PM, ext Laszlo Papp wrote:
> The QtSerialPort project was established a little over than half a
> year ago [1] in Playground. The project had already been useful (at
> least to me) at the time, but it has gone through a lot of bug fixes.
> Furthermore, there were API
Hi all.
Yes, it would be very nice to include it as an add-on to Qt. We spent a
lot of time improving this module, tried to meet the differing opinions.
We need help and advice from more people who are interested in the
development of this addon. In principle, the bulk of the work has been
don
Hi,
The QtSerialPort project was established a little over than half a
year ago [1] in Playground. The project had already been useful (at
least to me) at the time, but it has gone through a lot of bug fixes.
Furthermore, there were API modifications, and also a few new features
implemented and in
41 matches
Mail list logo
