The following changes enable the connection of qlocalsocket &
qabstractsocket by QIODevice::open(), making (a little) easier to mix
them.
https://codereview.qt-project.org/#change,39371
https://codereview.qt-project.org/#change,40592
The documentation certainly needs rework.
Hopefully, they will
On 11/8/12, Corentin Jabot wrote:
> so one could do
> QLocalSocket socket("foo_pipe"); // or QTcpSocket("localhost", 42)
> socket.open();
> ...
> socket.close();
>
I agree that the actual connectToHost() impl should live in open() so
we can control it additionally using a QList, but I think
we s
I agree with d3fault/oswald.
Adding some setters/properties for the connection parameters of
QLocalSocket/QAbstractSocket and a generic "connect" method would make
the api somehow more usable.
Maybe a connectToHost() method - connectToPeer may be a little less generic.
QLocalSocket and QAbstractS
On quinta-feira, 8 de novembro de 2012 15.48.29, shane.kea...@accenture.com
wrote:
> I think most of the issues can be solved by connecting the socket first,
> then using QIODevice as your base class pointer. When you call
> QIODevice::close() that will disconnect the socket.
QNAM proves that it
> There is a ton of overlap between QIODevice and QAbstractSocket, but
> don't think too hard about it or else you'll drive yourself mad.
QIODevice is actually a superclass of QAbstractSocket.
> The most common functionality that is shared between QAbstractSocket
> and QLocalSocket is just the co
There is a ton of overlap between QIODevice and QAbstractSocket, but
don't think too hard about it or else you'll drive yourself mad.
The most common functionality that is shared between QAbstractSocket
and QLocalSocket is just the connect/disconnect functionality. Aside
from that, yes they are bo
On Tue, Nov 06, 2012 at 04:47:58PM -0700, d3fault wrote:
> On 11/6/12, Corentin Jabot wrote:
> > I dont see how the connectTo* methods could be shared, and I don't
> > think it would be a good idea to try to do so.
> >
> I disagree. Having a QList and then being able to
> iterate over them and con
2012/11/7 Thiago Macieira :
> On quarta-feira, 7 de novembro de 2012 00.07.41, Corentin Jabot wrote:
>> The following seems like a good subset of the QAbstractSocket
>> interfaces that also makes sense for QLocalSocket
>
> I don't want you to list functions that are common. I can do that by myself.
On 11/6/12, Corentin Jabot wrote:
>
> I dont see how the connectTo* methods could be shared, and I don't
> think it would be a good idea to try to do so.
>
I disagree. Having a QList and then being able to
iterate over them and connectTo* and disconnectFrom* without knowing
their type is helpful.
On quarta-feira, 7 de novembro de 2012 00.07.41, Corentin Jabot wrote:
> The following seems like a good subset of the QAbstractSocket
> interfaces that also makes sense for QLocalSocket
I don't want you to list functions that are common. I can do that by myself.
I want you to explain *why* you n
The following seems like a good subset of the QAbstractSocket
interfaces that also makes sense for QLocalSocket
void abort ()
void disconnectFromHost ()
SocketError error () const
bool flush ()
bool isValid () const
qint64 readBufferSize () const
void setReadBufferSize ( qint64 size )
bool setSock
On terça-feira, 6 de novembro de 2012 11.49.40, Alfonso Chartier wrote:
> Someone below asked what the motivation is behind having a common abstract
> socket base class for all concrete socket types. The reason for this is it
> can significantly clean up client code. Currently if I want to handle
>
ed
> capacity
>we prepare for taking the repository branching in use after Qt5
> Beta 2
>
> 16. QtLocation and QtConnectivity CI is broken due to the fact that their
> dependencies were removed from Qt5.git
> -> CI uses init-repository script to fetch dependenci
On 11/6/2012 7:52 PM, d3fault wrote:
> You want to obey a randomly declared 'feature-freeze'
It wasn't randomly declared. :D It has been set in stone since around
May and is standard practice for open source projects near time for a
stable release usually starting at the first beta release. Other
You want to obey a randomly declared 'feature-freeze' and decline a
SUPERIOR re-design that can only take place during BC breakages? It's
not like it'd be that hard to implement. Sure, we're in a feature
freeze but that's nothing compared to a 'BC promise' that 5 will
set in stone.
<*insert ho
Op 6-11-2012 10:26, d3fault schreef:
> "a common base class is an interesting idea. But it’s a moot point
> since we have to maintain binary compatibility until Qt 5. So
> QAbstractSocket cannot change. We’ll revisit the issue when Qt 5
> development starts, but that’s a long way in the future". (
"a common base class is an interesting idea. But it’s a moot point
since we have to maintain binary compatibility until Qt 5. So
QAbstractSocket cannot change. We’ll revisit the issue when Qt 5
development starts, but that’s a long way in the future". (
http://blog.qt.digia.com/blog/2008/02/22/qloc
On segunda-feira, 5 de novembro de 2012 14.30.24, Alfonso Chartier wrote:
> Hello,
>
> What is the likelihood that QTBUG-27635 (
> https://bugreports.qt-project.org/browse/QTBUG-27635) will be fixed for Qt
> 5? The idea here is for all socket classes to inherit from a common base
> class (for inst
+1
It's now or never (well... 6... so like 2020 lol?)
A 'server' that can listen to clients that are both:
a) other processes on the same machine
b) other machines on the network
at the same time by working with a common abstract base type would be
very handy.
Unifying the connectTo* methods i
Hello,
What is the likelihood that QTBUG-27635 (
https://bugreports.qt-project.org/browse/QTBUG-27635) will be fixed for Qt
5? The idea here is for all socket classes to inherit from a common base
class (for instance, QAbstractSocket). The current design, where different
concrete socket classes de
20 matches
Mail list logo
