Sparse documentation

[GoogleCodeExporter]

The documentation for this project in terms of which signals are available
are very sparse. The code is also written such that it is hard to find what
you're looking for: the signals are not all listed in the header files but
emitted dynamically in the system-specific .cpp files as an example.

It would be nice if the documentation touched on the following in a clear
manner:
 - Signals and ports used
 - How threading is utilized by async I/O (do we need to create a separate
thread or is that handled automatically?)

I will try to attach a patch once I figure out some more things. If someone
can chip in with more information here I can write up a patch for it as I
would like to contribute.

Original issue reported on code.google.com by bryant.m...@gmail.com on 23 Nov 2009 at 6:35

[GoogleCodeExporter]

Most of the signals are defined in the QIODevice interface which QextSerialPort 
inherits - it's not possible to 
dynamically emit signals.

For async IO, the user doesn't need to spawn any new threads - this is handled 
internally.

The code has been changing quite a bit, so there are some things that are a bit 
out of date.  I think a couple of 
examples would go a long way, and any help would be greatly appreciated.

Original comment by lst...@gmail.com on 23 Nov 2009 at 3:46

[GoogleCodeExporter]

Didn't think to check QIODevice for the interface, though I should've. I think 
the
documentation should be explicit about that and possibly run over it anyways.

As for the threading the reason I asked was because the event example explicitly
spawns a new thread. A "correct" version of this would not need this separate 
thread
or is it there for some other reason?

Original comment by bryant.m...@gmail.com on 23 Nov 2009 at 4:45

[GoogleCodeExporter]

Eh - I'm not sure anybody has touched those examples in a long time.  Would be 
good to fix them up before the 
next beta release.

Original comment by lst...@gmail.com on 23 Nov 2009 at 9:43

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

@bryant.mairs

Giving a closer look into the code you will see, that threads in the event 
example 
are not for the serial port, but to read from the console. The serial port does 
work 
event driven very well without creating any thread, even in linux.  

Original comment by rweick...@googlemail.com on 1 Dec 2009 at 1:43

[GoogleCodeExporter]

Original comment by dbzhang...@gmail.com on 21 Mar 2012 at 9:04

• Changed state: Invalid