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
- Original Message -
> From: Alan Alpert <4163654...@gmail.com>
> On Thu, Nov 8, 2012 at 12:49 PM, BRM wrote:
>>> From: Alan Alpert <4163654...@gmail.com>
>>
>>> To: development
>>> Cc:
>>> Sent: Thursday, November 8, 2012 12:57 PM
>>> Subject: [Development] Another method of regis
On Thu, Nov 8, 2012 at 2:15 PM, Richard Moore wrote:
> On 8 November 2012 21:17, Alan Alpert <4163654...@gmail.com> wrote:
>> On Thu, Nov 8, 2012 at 12:49 PM, BRM wrote:
From: Alan Alpert <4163654...@gmail.com>
>> If you have a http://remote/Image.qml with code like Image { source:
>> "graph
On Thu, Nov 8, 2012 at 3:43 PM, Thiago Macieira
wrote:
> On quinta-feira, 8 de novembro de 2012 15.36.23, Alan Alpert wrote:
>> But I'm not sure what the usecase is for extending QtQuick1 in Qt5
>> only? Isn't the primary point of QtQuick 1 in Qt5 to provide a smooth
>> migration path? QtQuick 1 i
On Thu, Nov 8, 2012 at 2:19 PM, Thiago Macieira
wrote:
> On quinta-feira, 8 de novembro de 2012 09.57.05, Alan Alpert wrote:
>> qmlRegisterType(const char* url, const char *uri, int versionMajor,
>> int versionMinor, const char *qmlName).
> [...]
>
>> This would allow for a platform component impo
On quinta-feira, 8 de novembro de 2012 15.36.23, Alan Alpert wrote:
> But I'm not sure what the usecase is for extending QtQuick1 in Qt5
> only? Isn't the primary point of QtQuick 1 in Qt5 to provide a smooth
> migration path? QtQuick 1 in Qt5 is "Done" (unless this has changed),
> so if a feature
On Thu, Nov 8, 2012 at 2:16 PM, Thiago Macieira
wrote:
> On quinta-feira, 8 de novembro de 2012 11.02.23, Alan Alpert wrote:
>> I know commits go to Qt5 first, but with the issue of QtQuick there's
>> different implementations for QtQuick 1 and QtQuick 2. I don't think
>> it's a good idea for QtQu
Ossi's new version of the change fixes both issues now, it should land soon
hopefully. Thanks for reporting and helping identify the problem!
Regards,
Romain
On Nov 7, 2012 2:08 AM, "Thomas Senyk" wrote:
> On Tue, November 06, 2012 08:21:24 PM Oswald Buddenhagen wrote:
> > On Tue, Nov 06, 2012
On quinta-feira, 8 de novembro de 2012 09.57.05, Alan Alpert wrote:
> qmlRegisterType(const char* url, const char *uri, int versionMajor,
> int versionMinor, const char *qmlName).
[...]
> This would allow for a platform component import which looks like this:
> if(platform=="desktoplinux")
> q
On quinta-feira, 8 de novembro de 2012 11.02.23, Alan Alpert wrote:
> I know commits go to Qt5 first, but with the issue of QtQuick there's
> different implementations for QtQuick 1 and QtQuick 2. I don't think
> it's a good idea for QtQuick 1 (Qt 5) to gain new features that are
> withheld from Qt
On 8 November 2012 21:17, Alan Alpert <4163654...@gmail.com> wrote:
> On Thu, Nov 8, 2012 at 12:49 PM, BRM wrote:
>>> From: Alan Alpert <4163654...@gmail.com>
> If you have a http://remote/Image.qml with code like Image { source:
> "graphic.png" } the png will be fetched transparently.
>
>> [1] Ye
Hello,
I was wondering if some gestures, such as QTapGesture or QTapAndHoldGesture
should consume QEvent::TouchBegin || QEvent::TouchEnd. The reason I am asking
this is that, if these events are not consumed somewhere along the chain, Qt
assumes that the touch events haven't been handled at all, a
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 Thu, Nov 8, 2012 at 12:49 PM, BRM wrote:
>> From: Alan Alpert <4163654...@gmail.com>
>
>> To: development
>> Cc:
>> Sent: Thursday, November 8, 2012 12:57 PM
>> Subject: [Development] Another method of registering QML types
>>
>> Currently, there is no way to register QML files as types from C
> From: Alan Alpert <4163654...@gmail.com>
> To: development
> Cc:
> Sent: Thursday, November 8, 2012 12:57 PM
> Subject: [Development] Another method of registering QML types
>
> Currently, there is no way to register QML files as types from C++.
> This is the exact same functionality that qml
On 8 November 2012 09:37, Alberto Mardegan wrote:
> Hi all!
> At some point I might need to use XEmbed, so I'm interested in helping
> out the implementation of QX11EmbedWidget in Qt5, as time permits.
> Now I'm just studying the code to evaluate how much of an effort it
> would be.
>
> I've see
On Thu, Nov 8, 2012 at 11:14 AM, Oswald Buddenhagen
wrote:
> On Thu, Nov 08, 2012 at 09:57:05AM -0800, Alan Alpert wrote:
>> Any comments on this suggested addition to the QtDeclarative public API?
>>
> sounds like an utter nightmare for plugins.qmltypes files.
I think it's reasonable for Creator
On Thu, Nov 08, 2012 at 09:57:05AM -0800, Alan Alpert wrote:
> Any comments on this suggested addition to the QtDeclarative public API?
>
sounds like an utter nightmare for plugins.qmltypes files.
___
Development mailing list
Development@qt-project.org
h
On Thu, Nov 8, 2012 at 10:14 AM, Olivier Goffart wrote:
> On Thursday 08 November 2012 09:57:05 Alan Alpert wrote:
>> Currently, there is no way to register QML files as types from C++.
>> This is the exact same functionality that qmldir provides, but I think
>> there are situations where you'll w
On Thursday 08 November 2012 19:23:37 Shawn Rutledge wrote:
> On Thu, Nov 08, 2012 at 07:14:52PM +0100, Olivier Goffart wrote:
> > On Thursday 08 November 2012 09:57:05 Alan Alpert wrote:
> > > Currently, there is no way to register QML files as types from C++.
> > > This is the exact same function
On Thu, Nov 08, 2012 at 07:14:52PM +0100, Olivier Goffart wrote:
> On Thursday 08 November 2012 09:57:05 Alan Alpert wrote:
> > Currently, there is no way to register QML files as types from C++.
> > This is the exact same functionality that qmldir provides, but I think
> > there are situations whe
On Thursday 08 November 2012 09:57:05 Alan Alpert wrote:
> Currently, there is no way to register QML files as types from C++.
> This is the exact same functionality that qmldir provides, but I think
> there are situations where you'll want to do this progamatically
> instead of with a qmldir file.
Currently, there is no way to register QML files as types from C++.
This is the exact same functionality that qmldir provides, but I think
there are situations where you'll want to do this progamatically
instead of with a qmldir file. There is a very specific example I have
in mind: Platform Compon
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
Compared to previous successful build (Nov.05-322), following bugs have been
addressed for packages in
http://releases.qt-project.org/digia/5.0.0_beta2/backups/2012-11-08-328/
Issues addressed for qt-creator:
QTBUG-26869 $$QMAKESPEC is a path in the source dir, but should be in the
build di
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
Thank you all so very much.
Rafael
On Wed, Nov 07, 2012 at 08:50:37PM -0200, Rafael Roquetto wrote:
> Hello,
>
> Could anyone with knowledge take a look at
> https://codereview.qt-project.org/#change,38900 ?
> I know it hasn't been stale for long, but I would like to make sure it will
> not fall
On 11/08/2012 11:58 AM, Samuel Rødal wrote:
> It needs to be part of a separate library, as we don't want libQtGui or
> libQtWidgets to link to X11-specific libraries (the choice between the
> wayland, xcb, directfb, kms, etc platform plugins is made at run-time).
Sure, but it could still be im
Hi,
This is just a heads up that https://codereview.qt-project.org/#change,38451
has finally landed in qtbase/master. You can now pass -qt-xcb to configure to
minimize the dependencies to various xcb-* system libraries: I added the source
code for these to src/3rdparty/xcb, and using the switch
We are happy to announce Qt Creator 2.6.0.
Blog: http://blog.qt.digia.com/blog/2012/11/08/qt-creator-2-6-0-released/
Download: http://qt-project.org/downloads#qt-creator
Best regards from the Qt Creator crowd!
--
Eike Ziller
Senior Software Developer
Digia Germany GmbH
Rudower Chaussee 13, 1248
On 11/08/2012 10:37 AM, Alberto Mardegan wrote:
> Hi all!
>At some point I might need to use XEmbed, so I'm interested in helping
> out the implementation of QX11EmbedWidget in Qt5, as time permits.
> Now I'm just studying the code to evaluate how much of an effort it
> would be.
Excellent :)
On Thu, 08 Nov 2012 11:37:58 +0200, Alberto Mardegan
wrote:
> Hi all!
> At some point I might need to use XEmbed, so I'm interested in helping
> out the implementation of QX11EmbedWidget in Qt5, as time permits.
> Now I'm just studying the code to evaluate how much of an effort it
> would be.
I
Hi all!
At some point I might need to use XEmbed, so I'm interested in helping
out the implementation of QX11EmbedWidget in Qt5, as time permits.
Now I'm just studying the code to evaluate how much of an effort it
would be.
I've seen the merge request about QX11Info, which is somehow related:
ht
34 matches
Mail list logo
